[ENH] floatGlobals-ls

lex at cc.gatech.edu lex at cc.gatech.edu
Mon Sep 20 20:05:17 UTC 2004


Guys, I did not do it that way just because it was easier.  If people
really prefer "Float infinity", "Float nan", and "Number infinity", I
can certainly switch it all around  -- it's actually slightly easier
that way.

Before doing so, though, please consider that Infinity, at the least, is
a fundamental value and seems worth having right at ones fingers.  It
almost as basic as 0 and 1 and -1.

NaN and NegativeInfinity I am less attached to.  I still added them,
though, because:

	1. It is consistent with Infinity.
	2. They are quite fundamental themselves.

But they are less important than Infinity, so it's fine if they are a
touch harder to access.

I see no reason to absolutely minimize the number of globals.  Having few globals is just one design guideline, but we still want to have a usable and *consistent* language.  Thus far, Smalltalk has leaned towards having a rich syntax for number literals, despite having a tiny grammer.  [Infinity] is consistent with this strategy, while [Float infinity] is not.

To make an analogy, we do not need 0, 1 and -1 either.  We could have [Integer zero], [Integer zero plusOne], and [Integer zero plusOne negated].  Arguably some of these are okay, but they break with tradition.  If we are going to switch floats to having minimal support as literal expressions, then for consistency we ought to do so for other numeric literals, too.  To begin with, things like 12rABAB should surely go away.


On individual queries:


> Of course, I have to point out that NEITHER the change set in question
> NOR my proposed revision succeeds in the aim of making all floats print
> out as something that evaluates to a number with the same bit pattern,
> because there are 2*(2**53-1) NaN values.  For that we'd need
> (Float nan: 'hex string') or something like that.

True.  This seems very unimportant, though.  NaN's all operate the same
(don't they?)  And even if you create a NaN with the same bit pattern as
another, they will be neither #= nor #== to each other.  In fact, the
only way to compare two NaN's, unless they happen to be #==, would seem
to be using #hex and the like to peek at the bits.

Anyway, this seems like a separate matter.


> I'm especially unhappy about this because ANSI Smalltalk mandates
> *three* floating-point classes (FloatE, FloatD, and FloatQ) and
> *each* of them would want its own three global variables, because
> FloatE infinity (if ANSI had it) could not be the same object as
> FloatD infinity.

There's no problem here.  [Infinity] can refer to one of them, and the
other classes will have to do something more specialized like [EFloat
infinity]. 
 
It is exactly the same as with 1.52.  [1.52] can only evaluate to one
kind of float.  If there is more than one kind of float, the other
1.52's will have to be printed something like [1.52d] or [1.52ieee96]. 
That doesn't mean we should give up on using [1.52] for the most common
type.

Also, I actually meant the Infinity global to be a placeholder for a
good infinity object, and not necessarily for [Float infinity].  It just
happens that we have no other contenders right now, so [Float infinity]
is winning by default.  And as long as it is winning, we may as well use
short printStrings when possible.  Especially if someone types
"Infinity" to get this value, it is nice if "Infinity" is how the value
prints back out.


> This is of particular interest because it's clear that Squeak _does_
> have two floating-point types.  There's "Float" and there's "element
> of a FloatArray".  (Anyone else find it confusing that the elements
> of FloatArrays are not really Floats?)  

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.

Overall, it would be nice to have a fuller range of float classes, but
as long as no one is volunteering, we seem to be in good shape right
now.  If we only get to have one float class, then 64-bit seems fine. 
If we only get to have one float array class, then 32-bit seems fine.


So my current thoughts are to kill NegativeInfinity and NaN, just to please
the puritans, to update the printString's appropriately, and to leave the
global Infinity around.  But I'll wait a little while to see how the
discussion goes.



-Lex



More information about the Squeak-dev mailing list