Re: How to develop a random number generation device

On Sep 18, 7:05 am, Martin Brown <|||newspam...@xxxxxxxxxxxxxxxxxx>
wrote:
On Sep 18, 2:30 pm, MooseFET <kensm...@xxxxxxxxx> wrote:

On Sep 17, 7:55 pm, John Larkin<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

[....]

Programmers have pretty much proven that they cannot write bug-free
large systems.

In every other area, humans make mistakes and yet we seem surprised
that programmers do too.

In most other areas of endeavour small tolerance errors do not so
often lead to disaster. Boolean logic is less forgiving. And fence
post errors which even the best of us are inclined to make are very
hard to spot. You see what you intended to write and not what is
actually there. Walkthroughs and static analysis tools can find these
latent faults if budget permits.

Static analysis tools can only find some bugs. Some code has to be
stepped through to see if it ever gets stuck or goes into a loop. I'm
thinking of things like:

while (X > 1) do
if (X is even) X = X/2;
else X = 3 * X + 1;


It is really hard to see whether for some values of X this sticks in a
loop or not.


Some practitioners, Donald Knuth for instance have managed to produce
virtually bug free non-trivial systems (TeX).

Given the right motivation, I suspect that quite a few programmers
could do it. The problem is partly the one you point out below and
partly that those guys already have jobs. There is a lot of quite
good code being written. It doesn't get noticed because of the
mountains of crap it is hiding in.

OTOH the current
business paradigm is ship it and be damned. You can always sell
upgrades later. Excel 2007 is a pretty good current example of a
product shipped way before it was ready. Even Excel MVPs won't defend
it.

I have always worked in an environment where bugs are not allowed. I
don't have a perfect record, but I'm sure that my rate of making bugs
is way lower than that of the average programmer in an environment
where bugs are allowed. Practice helps.


Software programming hasn't really had the true transition to a hard
engineering discipline yet. There hasn't been enough standardisation
of reliable component software parts for sale off the shelf equivalent
in complexity to electronic ICs that really do what they say on the
tin and do it well.

.... and further: In a lot of ways, we need better languages. Back in
the days of DOS I was helping someone fix a program that used a
library for working with the serial port, and by time we got done we
no longer used the library. I don't think there was really much
wrong with the library it was just that we couldn't figure out how to
make it do what was needed. It had a think book full of documentation
of the dozens of function it contained. Going cover to cover several
times we simply couldn't find the needed routines or how to call them.

We needed a "get the next character from COM1 or any change in the
modem status in the order they happened please" function.



By comparison thanks to Whitworth & Co mechanical engineering has
standardised nuts and bolts out of a huge arbitrary parameter space.
Nobody these days would make their own nuts and bolts from scratch
with randomly chosen pitch, depth and diameter.

Perhaps not today but back in 1998, someone in China was making his
own bolts etc. They were threaded with an odd pitch. They were
roughly the typical US sizes rounded off to the nearest metric thing
his lathe could do. He was threading into plastic, the standard
metric threads wouldn't hold and he could find the right sort of
insert.


This suggests a rephrasing of your point as "it is better to use
multiple simple systems" connected in some way rather than just
calling it multiple cores or CPUs.

How about calling them modules. Re-usable components with a clearly
defined and documented external interface that do a particular job
extremely well. NAGLIB, the IJG JPEG library or FFTW are good examples
although arguably in some cases the external user interface is more
than a bit opaque.

I like the idea of modules. Maybe we could have a programming system
that is more like designing analog hardware. You indicate where the
data goes, putting down the modules you need and wiring them up.

Have you ever played with "artsbuilder". It is sort of what I'm
thinking of.


Very complex hardware is likely to have the same problems as very
complex software. We need to link of ways to use many copies of a
much simpler hardware.

And the very complex hardware is invariably designed using software
tools. The problem is not that it is impossible to make reliable
software. The problem is that no-one wants to pay for it.

I suspect that we are paying for it many times over. It is just that
people can't see the money going out of their pocket.

In hardware chip design the cost of fabricating a batch of total junk
is sufficiently high and painful that the suits will usually allow
sufficient time for testing before putting a new design into full
production. Not so for software where upgrade CDs and internet
downloads are seen as dirt cheap.

Also: "software is magic. Hardware has all those transistor thingies
in it."


[...]
For N<=4 full multiprocessing is fairly tractable and after that it
suddenly gets a lot harder. And I have know one multiprocessing
mainframe box where N=3 was perfect and the advertised upgrade to N=4
was a dogs dinner. Worth pointing out here that very few software
programs these days are that heavily CPU bound.

Did you ever work on an Itell Series 4 development system. It was
multiprocessor and multiuser. In both cases "multi" meant 1.5. It
had an 8086 and an 8080 in it. If the user on the 8086 started a
compile, the 8080 froze up.


Most CPUs in PCs these days are vastly overpowered for the normal day
to day work. Only a few power users and gamers really push them hard.

You obviously have seen how fast I typed all this :)


I rarely need all of the power of my PC. Sometimes though a run on
LTSpice will take all night. I rarely press the gas all the way to
the floor on my car too.



.

Loading