"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800) "alt-p" These are equal since both expressions end up answering a float with a special value indicating positive infinity. Positive infinities are always equal.
Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if finished correctly) is aFloat.
Correct. The problem occurs when the #= message is sent to the LargePositiveInteger with the argument a Float (+Infinity). This causes the LargePositiveInteger to be adapted to a Float (resulting in +Infinity, as well).
If aFloat turns out to be infinite, an error should be posted.
This would have to be tested in the Float primitives in the VM whenever an overflow (or NaN, I suppose) is generated. However, I *think* (VM experts correct me, here) that all they can do is fail rather than returning a succesful value, so all of the Float code that invokes primitives would have to be rewritten to test and reflect this overflow/exception failure.
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?
-- tim
At 13:20 -0500 2/17/98, Tim Olson wrote:
...SNIP... 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? -- tim
Tim:
The standard allows a trap handler to be specified which causes a trap when each of the various exceptions occur. With a trap handler in place in the VM, a floating point primitive failure can invoke another primitive to get the information on the most recent trap. Smalltalk can then take an appropriate action, like ignore the problem, take some standard system action, invoke a user supplied block, or whatever.
(There is the problem of two processes running floating point code and trapping at the same time; too bad that failed primitives can't answer values!)
I think, in order to follow the intent of the standard, that Squeak should take no action by default, but allow a global setting (say of a block) which will raise a Smalltalk exception. Individual operations could also specify blocks which apply just to that operation.
The standard suggests that trap handlers be a stack, so that a new one can be specified for a while, then the previous one restored.
Dave
_______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.
At 05:28 PM 2/17/98 -0500, David N. Smith wrote:
I think, in order to follow the intent of the standard, that Squeak should take no action by default, but allow a global setting (say of a block) which will raise a Smalltalk exception. Individual operations could also specify blocks which apply just to that operation.
The standard suggests that trap handlers be a stack, so that a new one can be specified for a while, then the previous one restored.
I suggest combining the establishment of an exception handler with the enabing of floating point exceptions
squeak-dev@lists.squeakfoundation.org
-
Allen Wirfs-Brock -
David N. Smith -
Tim Olson