Richard, these issues are important but mostly they are also answered in
the changeset I posted and in the update I mentioned possibly making.

Yes, if [Infinity] is not [Float infinity] then [Float infinity
printString] had better not be 'Infinity'.  But in my changeset they
were in fact the same thing, so why not use the nice printString?  If
and when the number hierarchy changes, then yes the printString's will
have to change as well.

You keep mentioning different kinds of floats, but there is only one
kind of float *object* in Squeak.  It's class Float, and it's what you
get when you type things like [1.6].  The mini-floats inside of a
FloatArray are never reified into full objects.  You can't send messages
to them, you can't test them for identity, and you can't even assign one
to a variable.  When you talk about different kind of float *objects*,
you are talking about some other language than Squeak of today.

I still do not see why it is a big deal that printing a NaN re-reads as
the same NaN that you started with.  You reiterated that this happens
with my changeset--and I believe you--but I do not see why it matters. 
It seems more important to have nice printString's in the inspectors and
workspaces.  Barring any serious practical reason, I would prefer if all
NaN's printed out as something pretty short, which would seem to bar
them from including all 53 bits you say are needed to distinguish them.

The example of code trying to re-evaluate printString's is not good code
to begin with.  It's certainly not portable--how many Smalltalks
actually have float printStrings being bit-for-bit re-readable?  On the
other hand, plenty of Squeakers, over the years, are going to look in an
inspector or print something out and see infinities and nans, and those
guys are who printString is designed for.

Finally, why are you mentioning ANSI?  You bring it up but do not seem
to mention any relevance it has here.  I actually took the time to look
this up because you mentioned it, and the spec seems to explicitly allow
float printString's to work however the implementation desires.


> I guess that people not only don't read the IEEE 754 standard, they don't
> read the ANSI Smalltalk standard either.  

This kind of comment is truly uncalled for. 


> 	It's interesting but it seems well engineered to me.  ShortFloatArray
> 	might be a better name... or it might be worse, because it sounds like
> 	the array is short, not the floats.
> 	
> Straw man.  Float32Array, ArrayOfShortFloat, anyone can make up better names
> than that straw man.  

Ah, good ones.  Especially "Float32Array" is nice, because it parallels
"IntegerArray".


Lex