Re: Serial, concurrent, parallel

I have had a similar scenario when cooking for two of us in my van for

Although cooking on a one-burner diesel stove in the back of the van is a serial affair, it mimics a parallel one when several different items have to be heated up or kept hot at once. I sometimes found I was literally operating my hands in parallel, getting ready to take something off the stove with one hand whilst preparing the next item to go on it with the other - then a quick swap-over.

Most people do think in a very linear fashion so I'm not too surprised at your finding. Good realtime programmers are as rare as hen's teeth.

There are major shrink wrap programs out there that have these bugs.

Excel 2007 as first released on a multi core machine and programmed via VBA the charting package would quite happily try to plot data points

It could be "solved" by the addition of suitable small delays here and there to prevent the race condition triggering. Heavy users went back to XL2003 which I recall was a particularly good vintage.

For things to get interesting you need at least 4 threads with some of them depending on synchronisation with the others. Building a house or putting up one of those insert tab A into slot B tents might do it.

A house without foundations will obviously fall down and putting the roof on before plastering and fitting out the interior is essential.

A variant of this cartoon might also get people's attention:

The problem was that the vegetables were there on the worktop when I started. -they just weren't there when I came to put them in the saucepan. A thorough search of the van failed to find them.

The next day I discovered that my frend had put them underneath the van instead of the milk, which was normally kept there because it stayed cooler.

As far as I can see, a databse is just a spreadsheet that has been crippled by having all the cells on each line tied together

In message <vm69a2$2h52d$ snipped-for-privacy@dont-email.me, Don Y snipped-for-privacy@foo.invalid writes

It's simple project engineering and resource management . PERT , Critical path analysis, lead times , Gantt charts, even Microsoft Project if you must. You must be talking to non-engineers.

Brian

Tricky in a 5ft x 8ft van conversion. <

All of those can be done on a spreadsheet. ...and similar checks can be done between cells in different rows. The check formula is written into a 'hidden' cell and the final result is displayed in a 'locked' cell. If someone puts in faulty data, the spreadsheet can't stop them but it can ensure that the dud data doesn't appear in the output.

I use spreadsheets for all sorts of things: calculating component values, customers and accounts, encoding sensitive information, addressing envelopes, uploading invoices to the Web ...etc.

I tried using a database to keep track of my Christmas Cards, but find it slow and restrictive compared with a spreadsheet.

The more such management tools that you use, the slower a project will go.

The key observation is that when things are serialized, they happen sequentially.

Real databases implement some form of content addressable storage.

An ISR is sufficiently small and so mission critical that if it doesn't save and restore the registers it affects properly the OS dies PDQ.

Most people can't imagine the various tasks running at different speeds either timesliced or by priority. There is always a tendency amongst programmer to think that their task is *the* most important one. The thing you learn quickly on truly massively parallel hardware is that the manager task that keeps all of the allocated workers busy is by far the highest priority.

I like spreadsheets for making test data. The sort of mistakes you can make in a spreadsheet implementation are almost entirely orthogonal to those you can make in a conventional programming language. As such it makes a great scratch pad for developing tricky algorithms with all of the internal workings clearly visible on the screen.

Sigh - yes I know they do :( Up to a couple of thousand lines it isn't *too* bad but after that it goes downhill very quickly. Doesn't stop people - typically middle managers with very limited skills having silly sized ones though.

...

Not sure what you're doing wrong but once I'd learned to use

The only time I make a spreadsheet is when I want to send data to someone else and they can't handle a database. I wouldn't put customers and accounts anywhere near a spreadsheet. I can remember using a spreadsheet to model an op amp circuit but that was many years before I had LTSpice.

Databases can also be backed up as human readable text files. Just export data as SQL. This gives me peace of mind that whatever software is or isn't available in the future I can always read my data.

AWESOMWE!! Ed

PERT and the like handles parallel processing paths , in fact it almost forces you do it . When things are concurrent they happen in parallel .

B .

More software management tools not only slow down a design project, you need people to drive the tools too.

In other words exporting a database as SQL is not in any way similar to exporting a spreadsheet as csv. You might be better off unzipping the xlsx and parsing the xml if you really want your spreadsheet elsewhere.

I frequently paste an entire SQL dump into the Query tab in HeidiSQL.

You appear to be conflating the actual storage systems with the ways of getting access to them. All the things that you like about databases could equally well be done with spreadsheets - it's just that database access software manufacturers have tailored their products to particular needs whereas spreadsheets haven't attracted the same attention.

Fundamentally, spreadsheets are just the same as databases but without the constraints of the cells on each line being tied together. To put it another way: a spreadsheet is a non-relational database. The software to manipulate them, which is what you have been describing, is a totally different matter.

Spreadsheets allow you to move columns and cells around individually - which is a very dangerous procedure if the spatial relationship between the cells is key to the information being stored. Databases are safer in this respect but less versatile if your data is the type which does not depend on cell position in a table.

You may as well ask what it looks like when a jpg is opened in a text editor.