> From: sqrmax at cvtci.com.ar


> Maybe it's already fixed, but I still use 1.23... so I still can't check 
> it. BTW, I couldn't figure out what NaN stands for. Could you please tell me?
> 
> Wild guess: Not a Normalized answer...

Not A Number

> >The IEEE "default" operation is to silently return the default values 
> >(Inf or NaN), rather than generating an exception.  What should the 
> >standard for Squeak be?
> 
> I think that the default operation should be adopted, and then that the 
> numbers in Squeak behave adequately with respect to those answers. For 
instance, 
> if aFloat turns out to be +inf, then it cannot be compared for equality to 
> anInteger (for instance), since:
> 
> (10 raisedToInteger: 1000) = (10.0 raisedToInteger: 1000)
> 
> should answer false, not true (no float exists for that integer). What I 
> don't like about this is the whole idea of using #= where it doesn't fit. It's 
> much more comfortable to let them be #=, only when it works as expected.

The trouble with IEEE is that overflow and infinity are different concepts.
Infinity is meaningful even in the context of exact arithmetic
(though it is meaningless to compare infinities of like signs).
 
> Leandro Caniglia had some trouble with floats when crunching money amounts 
> because of the error carried all over.

In any language that supports exact arithmetic, it is a *SIN* to use
floating point on currency!

> IMHO, using #= isn't correct when comparing floats with integers or 
> fractions. Mainly because, in this case, Floats belong to the 
> LimitedPrecisionArithmetic world, whereas IntegersAndFractions belong to the 
> ArbitraryPrecisionArithmetic universe. Both IntegersAndFractions are subsets 
of Rationals thought 
> up to represent any desired rational number. On the other hand, Floats are 
> thought up to lower the space used up to represent such numbers. John von 
> Neumann was really against them. When he died in 1956, people started to use 
floats 
> instead of bigIntegers. Ok, at that time big numbers could eat up all the 
> memory available. This is hardly the case today. Operation is also faster with 
> floats (for big numbers). I see it as a Speed vs. Accuracy choice... you can 
> have only one of those. I think that if you choose one, then you should stick 
> with it. Incidentally, transitions between those two only increase the error 
> already accumulated.
> 
> Andres.

I think that the concept of exactness from Scheme would be a usefull
and valuable thing to have in Squeak ( and all Smalltalks)
For details see:

	http://www-swiss.ai.mit.edu/~jaffer/r4rs_8.html#SEC52
	

A quote from the Scheme languare reference: (about =, <, >, etc.)

	Note: While it is not an error to compare inexact numbers using these
	predicates, the results may be unreliable because a small
	inaccuracy may affect the result;
	this is especially true of = and zero?.
	When in doubt, consult a numerical analyst. 



The important thing for Squeak is to implement the primitives in such
a way that overflows/underflows/divideByZeroes etc.... are all trapped
in a manner such that we can experiment with numeric implementations
without having to change the VM.  Part of this may be a mechanism for
primitive failures to return an indicator as to the manner of failure
(preferable in a local, not global, manner).  

Mike Klein


"The art of the wrap is the art of the trap"
	-- Alan Kay (A Brief history of Smalltalk)