Martin Rubey <[EMAIL PROTECTED]> writes:
> I just checked ecl:
>
> g(x:DFLOAT):DFLOAT == 10^155
> draw(g, -1..1)
>
> fails, while 10^154 seems to work.
The failing routine is norm in CLIP, being called by iClipParametric. I find
the following behaviour:
gcl:
(2) -> f := max()$DFLOAT
(2) 1.7976931348623157E308
Type: DoubleFloat
(3) -> f^2
(3) #<inf>
Type: DoubleFloat
sbcl:
(8) -> f := max()$DFLOAT
(8) 1.7976931348623157e308
Type: DoubleFloat
(9) -> f^2
>> System error:
arithmetic error FLOATING-POINT-OVERFLOW signalled
I'm not sure what to do about this. But I vaguely remember that Gaby
implemented something around "not a number", didn't you?
We could of course check in DoubleFloat itself whether we are going to
overflow, but that defeats the purpose of being efficient, doesn't it?
Oh, I found it:
)lisp (sb-ext::set-floating-point-modes :traps nil)
this should go into
(defun set-initial-parameters()
(setf *read-default-float-format* 'double-float))
shouldn't it?
Martin
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
