Ok....that's to all the responses. The thread is now far away my knoweldege, so I will naively ask: is it worth creating a Pharo 1.1.1 one click with CogVM? Marcus released a PharoCore 1.1.1 with changes for CogVM and some important fixes. I took that core image and I created a new dev. But before releasing, I run the tests and I found them. Seems you all discussed about the Float problems...but what about the others? I remember them and I thing they were fixed in newest versions of VMMaker. So...the question is now....are the failure/error of those tests means that Pharo is "unreleasable" with CogVM? Should we wait for the fix or we should release anyway? Thanks in advance, Mariano On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <andreas.raab@gmx.de>wrote:
On 9/16/2010 2:44 PM, Eliot Miranda wrote:
I realise we need to be more precise. Are you talking about NaNs specifically or NaN and Inf?
NaN only. +-Inf are fine as they have a well-defined mathematical relationship over the set of numbers. NaN does not.
The Squeak VM happily answers Inf from its
float primitives. In fact the only guard against a NaN or Inf result being produced by the floating-point primitives is the guard against dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) isInfinite and there is no failure. So specifically failing for aFloat / 0.0 seems a bit of a fig leaf to me.
So what would your ideal semantics be? a) - fail whenever the result is Inf or NaN? b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf c) - fail whenever the result is NaN but fail aFloat / 0.0 d) - the Interpreter status quo, fail only for aFloat / 0.0 e) - never fail and answer Nan and Inf as specified in IEEE 754
The situation with VW before IEEE was that it did a) and we changed it so that the mode switch selected either a) or e), with, IIRC, the current default being e).
f) Fail whenever the result is NaN or when dividing by zero.
OK, to be pedantic that's c) above. But fine. This is a reasonable choice.
My preference for f) is that division by zero should be consistent between floating point numbers and integers. It would be strange if "1 / 0" => boom but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division by zero and may silently result in Inf. In other words:
self should:[1.0 / 0.0] raise: ZeroDivide.
but (#successor produces the smallest float larger than the receiver)
self shouldnt:[1.0 / 0.0 successor] raise: Error. self assert: (1.0 / 0.0 successor) = Float infinity.
Cheers, - Andreas