This:
In Trial ACL 6.1:
(defun thet (&rest yabba)
(/ pi (length yabba)))
...when called like this:
(thet)
1. returns #.EXCL::*INFINITY-DOUBLE* if reached mid-app -or- evaluated
interactively by pointing to source in an editor window and asking ACL
to evaluate it
2. signals div-by-zero error if entered in the debugger window.
I realize ACL uses an interpreter instead of compiling debugger forms,
hence no surprise that different results are obtained.
I guess I am surprised that evaluating a form interactively from the
editor works like the compiled code instead of the interpreter, but that
might be a question for Franz.
And the double-infinity... well, I was going to say something tolerant
about how this might make sense given casting to floating-point, but on
second thought zero converts to floating point cleanly, so...?
Bug report to Franz? or does the above make sense?
kenny
clinisys
Kenny Tilton wrote:
> (defun thet (&rest yabba)
> (/ pi (length yabba)))
>
> ...when called like this:
>
> (thet)
...
> I guess I am surprised that evaluating a form interactively from the
> editor works like the compiled code instead of the interpreter, but that
> might be a question for Franz.
RTFANS 12.2.27
···@agharta.de (Dr. Edmund Weitz) writes:
> "Steven M. Haflich" <···@franz.com> writes:
>
> > RTFANS 12.2.27
>
> ???
Read The Fine American National Standard.
"F" actually sometimes stands for a less friendly four-letter
word than "fine", but I'm _sure_ Steve would never use such
a word.
The canonical term in this acronym family is RTFM, where M
stands for "manual".
Kent M Pitman <······@world.std.com> writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
>
> > "Steven M. Haflich" <···@franz.com> writes:
> >
> > > RTFANS 12.2.27
> >
> > ???
>
> Read The Fine American National Standard.
>
> "F" actually sometimes stands for a less friendly four-letter
> word than "fine", but I'm _sure_ Steve would never use such
> a word.
>
> The canonical term in this acronym family is RTFM, where M
> stands for "manual".
Yep, I was aware of the RTFM acronym and thought that ANS was
referring to the ANSI standard. But I couldn't find 12.2.27 in the
CLHS. 12 is "Numbers", 12.2 is "The Numbers Dictionary", but no
12.2.27 in my copy...
Thanks,
Edi.
Don't know if this will work, but:
http://www.franz.com/support/documentation/6.1/ansicl/dictentr/unnamed4.htm
I was more interested in why a form evaluated in the editor behaved like
compiled code, but the above at least explains the infinity result
dividing by zero: results are unspecified.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Don't know if this will work, but:
>
>
> http://www.franz.com/support/documentation/6.1/ansicl/dictentr/unnamed4.htm
>
> I was more interested in why a form evaluated in the editor behaved like
> compiled code, but the above at least explains the infinity result
> dividing by zero: results are unspecified.
Thanks. Looks like in Franz' version the function entries (like "/")
are explicitely numbered while in the CLHS they're not.
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Don't know if this will work, but:
> >
> >
> > http://www.franz.com/support/documentation/6.1/ansicl/dictentr/unnamed4.htm
> >
> > I was more interested in why a form evaluated in the editor behaved like
> > compiled code, but the above at least explains the infinity result
> > dividing by zero: results are unspecified.
>
> Thanks. Looks like in Franz' version the function entries (like "/")
> are explicitely numbered while in the CLHS they're not.
Right. Nor are they numbered in the real ANS. But / is the 27th entry in
12.2 if you count by hand in CLHS. :)