Re: Tetrits and "stickiness"
> Date: Thu, 15 Apr 2010 16:32:47 -0400
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Re: Tetrits and "stickiness"
>
> > In that case, when the routine is repeated, can't the debugger just
> > manually reset the decoration of each input interval during the slow
> > but thoroughly-checked sequence?
>
> What debugger? I'm talking running program here, with alternate paths
> depending on whether funny things do or don't happen, as detected by
> the sticky decorations.
Yes. There is also the situation in which the program
is simply too expensive to run in a 'slow but thoroughly
checked sequence'.
I offer as an example the full 4-D simulations of nuclear
explosions that are being performed at the petaflops
machine in Los Alamos at the moment. Those simulations
are being used to design the next generation of nuclear
weapons without the benefit of underground tests. And
the machine is so fast & the simulation so expensive that
there is no other machine in the world capable of checking
its results. (Something I warned them about a few years
ago when I was invited to lecture there.)
However fast machines get & however long Moore's law
continues to hold there will always be problems we need
to solve on today's machines that are simply too expensive
to debug if debugging them means we most slow them down
by even moderately large factors.
The only hope we have of diagnosing such calculations is
if the diagnostic information is carried along with the
calculation itself as a side effect of the desired results.
And is no more expensive that the results themselves.
So part of what (IMHO) I think we should be shooting for
here is a decorations method which is so fast & simple
that no sane hardware designer would implement intervals
without them. And yet, sufficiently diagnostic that the
user (or, indeed, the program itself) has some chance of
figuring out some tricky problem using only those
decorations as a guide.
>
> If the sticky bits represent the same information as the detailed bits
> for a single operation, then yes, it would be sufficient to implement
> the sticky bits, and have the program clear the sticky bits before
> every operation. I was under the impression however that the detailed
> bits proposed by Dan Zuras carried more information than can be handled
> as a sticky bit.
It is true that the bits I proposed for the tetrit part
of the decorations together with any other sticky stuff
collected carries more information than Nate's approach
using only two bits.
But that observation does a disservice to his idea.
I would characterize Nate's idea as creating a 4-state
state machine for a decoration such that as soon as it
gets into a state worthy of 'sticking' it never gets
out of it again.
Now, part of my doubt about this is that I'm not sure
that the useful, collectable, diagnosable information
can be kept in only 4 states. But I'm not sure & I'm
hoping one of you will know from your greater experience
of interval algorithms whether or not this is true.
If it works I think we should go with it.
If not, bits are cheap & still getting cheaper every
day so adding another bit or two wouldn't kill us.
But that's part of what this discussion is about.
>
> There is also the issue of the cost of the explicit clearing, but that
> depends greatly on implementation choices, and might be negligible.
>
> Michel.
> ---Sent: 2010-04-15 20:40:14 UTC
I'm not quite sure what you mean by 'explicit clearing'
here. As a general policy, sticky diagnostic information
should never be cleared until the datum itself is discarded.
Things may be cleared on creation just as a start state
but I would let them gather their lint as they are used
& never clean it out at all.
BTW, as to whether we choose a representation which starts
with all zeros & gathers sticky ones over time or the
other way around, we need not be explicit about that as
a standards body. We can just call the abstractions the
'start state' & the 'sticky state' & leave it up to the
implementers to figure that out.
But, as a hardware guy, I find it cheap to initialize with
zeros & 'or' to ones. Its also cheap to test for. Any
non-zero or non-zero under mask will work.
But, again I digress.
To stick or not to stick, that is the question. Whether
tis nobler in the mind to suffer the slings & arrows of
outrageous representations or with an abstraction, end them.
Sorry, I get silly. :-)
Dan