floating-point-underflow
Sam Steingold
FLOATING-POINT-UNDERFLOW in this code:
(loop with x = 1 while (plusp x) do (setq x (/ x 100)))
is there any reason to signal that at all (as opposed to returning 0)?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://truepeace.org> <http://www.iris.org.il> <http://www.dhimmi.com/>
<http://www.savegushkatif.org> <http://www.openvotingconsortium.org/>
The world will end in 5 minutes. Please log out.
mmcconn...@yahoo.com
goes into an infinite loop.
Sam Steingold
>
> It appears that CLISP is the only CL that signals
> FLOATING-POINT-UNDERFLOW in this code:
>
> (loop with x = 1 while (plusp x) do (setq x (/ x 100)))
I meant, of course,
(loop with x = 1f0 while (plusp x) do (setq x (/ x 100f0)))
or
(loop with x = 1d0 while (plusp x) do (setq x (/ x 100d0)))
> is there any reason to signal that at all (as opposed to returning 0)?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.savegushkatif.org> <http://www.camera.org>
<http://pmw.org.il/> <http://www.iris.org.il> <http://www.dhimmi.com/>
Man has 2 states: hungry/angry and sate/sleepy. Catch him in transition.
Christophe Rhodes
>> * Sam Steingold <f...@tah.bet> [2005-08-09 11:44:13 -0400]:
>>
>> It appears that CLISP is the only CL that signals
>> FLOATING-POINT-UNDERFLOW in this code:
>>
>> (loop with x = 1 while (plusp x) do (setq x (/ x 100)))
>
> I meant, of course,
> (loop with x = 1f0 while (plusp x) do (setq x (/ x 100f0)))
> or
> (loop with x = 1d0 while (plusp x) do (setq x (/ x 100d0)))
>
>> is there any reason to signal that at all (as opposed to returning 0)?
I don't think that the default floating point mode is too worrisome
(though signalling on IEEE "inexact" by default would probably not win
you many friends :). On the other hand, it's important that users
should be able to change the trapped exceptions to suit their needs:
do you provide such customizeability?
(The mostly-dormant ieeefp-tests project on common-lisp.net, which
aims to test some kind adherence to the principles of IEEE floating
point, might be of interest.)
Christophe
Sam Steingold
>
> Sam Steingold <s...@gnu.org> writes:
>
>>> * Sam Steingold <f...@tah.bet> [2005-08-09 11:44:13 -0400]:
>>>
>>> It appears that CLISP is the only CL that signals
>>> FLOATING-POINT-UNDERFLOW in this code:
>>>
>>> (loop with x = 1 while (plusp x) do (setq x (/ x 100)))
>>
>> I meant, of course,
>> (loop with x = 1f0 while (plusp x) do (setq x (/ x 100f0)))
>> or
>> (loop with x = 1d0 while (plusp x) do (setq x (/ x 100d0)))
>>
>>> is there any reason to signal that at all (as opposed to returning 0)?
>
> I don't think that the default floating point mode is too worrisome
> (though signalling on IEEE "inexact" by default would probably not win
> you many friends :).
CLISP is the only CL I tested that signals a FLOATING-POINT-UNDERFLOW
error here.
ACL, LW, GCL, CMUCL all just return NIL.
You appear to imply that CLISP's behavior is not a very good idea.
(fwiw, I agree...)
Any other opinions?
> On the other hand, it's important that users should be able to change
> the trapped exceptions to suit their needs: do you provide such
> customizeability?
CLISP offers macro EXT:WITHOUT-FLOATING-POINT-UNDERFLOW
<http://clisp.cons.org/impnotes/num-dict.html#no-underflow>
obviously, one can also use HANDLER-BIND at al.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://www.iris.org.il>
<http://pmw.org.il/> <http://www.memri.org/> <http://www.dhimmi.com/>
The early worm gets caught by the bird.
Christophe Rhodes
>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:14:27 +0100]:
>>
>> I don't think that the default floating point mode is too worrisome
>> (though signalling on IEEE "inexact" by default would probably not win
>> you many friends :).
>
> CLISP is the only CL I tested that signals a FLOATING-POINT-UNDERFLOW
> error here.
> ACL, LW, GCL, CMUCL all just return NIL.
>
> You appear to imply that CLISP's behavior is not a very good idea.
> (fwiw, I agree...)
Sorry -- I meant that I didn't have too strong an opinion on
signalling underflow, though perhaps a slight preference for not
signalling; and I wanted to contrast that with inexact, which would be
odd to have signalling by default.
>> On the other hand, it's important that users should be able to change
>> the trapped exceptions to suit their needs: do you provide such
>> customizeability?
>
> CLISP offers macro EXT:WITHOUT-FLOATING-POINT-UNDERFLOW
> <http://clisp.cons.org/impnotes/num-dict.html#no-underflow>
>
> obviously, one can also use HANDLER-BIND at al.
Right. What about a pervasive setting (so that, for instance,
fork()ed processes inherit the underflow-error inhibition)? What
about the other IEEE-like exceptions -- overflow, invalid,
divide-by-zero, inexact? Do you provide for turning inexact traps
*on*, for instance? It's possible that there's an application out
there for that...
Christophe
Sam Steingold
>
> What about a pervasive setting (so that, for instance,
> fork()ed processes inherit the underflow-error inhibition)?
set SYS::*INHIBIT-FLOATING-POINT-UNDERFLOW* to T.
> What about the other IEEE-like exceptions -- overflow, invalid,
> divide-by-zero, inexact? Do you provide for turning inexact traps
> *on*, for instance? It's possible that there's an application out
> there for that...
CLISP never signals inexact or invalid.
overflow & divide-by-zero cannot be disabled.
(what would you return on divide-by-zero or overflow?!)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.memri.org/> <http://www.dhimmi.com/> <http://www.savegushkatif.org>
<http://www.openvotingconsortium.org/> <http://ffii.org/>
Which should be served first: the chicken salad or the egg salad?
Joe Marshall
>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:46:45 +0100]:
>>
>> What about a pervasive setting (so that, for instance,
>> fork()ed processes inherit the underflow-error inhibition)?
>
> set SYS::*INHIBIT-FLOATING-POINT-UNDERFLOW* to T.
>
>> What about the other IEEE-like exceptions -- overflow, invalid,
>> divide-by-zero, inexact? Do you provide for turning inexact traps
>> *on*, for instance? It's possible that there's an application out
>> there for that...
>
> CLISP never signals inexact or invalid.
> overflow & divide-by-zero cannot be disabled.
> (what would you return on divide-by-zero or overflow?!)
+ or - infinity, of course.
Thomas A. Russ
>
> It appears that CLISP is the only CL that signals
> FLOATING-POINT-UNDERFLOW in this code:
>
> (loop with x = 1 while (plusp x) do (setq x (/ x 100)))
>
> is there any reason to signal that at all (as opposed to returning 0)?
Well, conforming CL code should actually do neither, since there
shouldn't be any floating point numbers involved in this computation. X
will always be a rational number, and after the first iteration always a
ratio.
--
Thomas A. Russ, USC/Information Sciences Institute
Christophe Rhodes
>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:46:45 +0100]:
>> What about the other IEEE-like exceptions -- overflow, invalid,
>> divide-by-zero, inexact? Do you provide for turning inexact traps
>> *on*, for instance? It's possible that there's an application out
>> there for that...
>
> CLISP never signals inexact or invalid.
What do you do for (/ 0.0 0.0)?
> overflow & divide-by-zero cannot be disabled.
> (what would you return on divide-by-zero or overflow?!)
+Inf.0, -Inf.0? (In the IEEE world, these, and NaN which is the
result of a non-trapping inexact operation, have particular
well-defined properties on the basic arithmetic operations).
Christophe
Sam Steingold
these are not mathematical reals (as in "elements of R").
returning them might work for a couple of
operations, but eventually we will end up with a NaN.
if you want to see NaNs, just do
(or (ignore-errors (you-computations)) 'NaN)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.iris.org.il> <http://www.camera.org>
<http://www.honestreporting.com> <http://www.jihadwatch.org/>
Those who don't know lisp are destined to reinvent it, poorly.
Pascal Bourguignon
> Sam Steingold <s...@gnu.org> writes:
>
>>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:46:45 +0100]:
>>> What about the other IEEE-like exceptions -- overflow, invalid,
>>> divide-by-zero, inexact? Do you provide for turning inexact traps
>>> *on*, for instance? It's possible that there's an application out
>>> there for that...
>>
>> CLISP never signals inexact or invalid.
>
> What do you do for (/ 0.0 0.0)?
Well, it's obvious.
If it comes from (defun f (x) (/ (sin x) x)) then (/ 0.0 0.0) will return 1.
If it comes from (defun g (x) (/ 0 (abs x))) then (/ 0.0 0.0) will return +oo.
If it comes from (defun h (x) (/ 0 x)) then (/ 0.0 0.0) will return +oo or -oo
or :undetermined according to the caller.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Christophe Rhodes
> Christophe Rhodes <cs...@cam.ac.uk> writes:
>
>> Sam Steingold <s...@gnu.org> writes:
>>
>>> CLISP never signals inexact or invalid.
>>
>> What do you do for (/ 0.0 0.0)?
>
> Well, it's obvious.
>
> If it comes from (defun f (x) (/ (sin x) x)) then (/ 0.0 0.0) will return 1.
> If it comes from (defun g (x) (/ 0 (abs x))) then (/ 0.0 0.0) will return +oo.
> If it comes from (defun h (x) (/ 0 x)) then (/ 0.0 0.0) will return +oo or -oo
> or :undetermined according to the caller.
All of this is a very interesting fantasy, but fails either to address
my question or to be useful in any way. Thank you.
Christophe
Sam Steingold
>
> Sam Steingold <s...@gnu.org> writes:
>
>>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:46:45 +0100]:
>>> What about the other IEEE-like exceptions -- overflow, invalid,
>>> divide-by-zero, inexact? Do you provide for turning inexact traps
>>> *on*, for instance? It's possible that there's an application out
>>> there for that...
>>
>> CLISP never signals inexact or invalid.
>
> What do you do for (/ 0.0 0.0)?
divide-by-zero
>> overflow & divide-by-zero cannot be disabled.
>> (what would you return on divide-by-zero or overflow?!)
>
> +Inf.0, -Inf.0? (In the IEEE world, these, and NaN which is the
> result of a non-trapping inexact operation, have particular
> well-defined properties on the basic arithmetic operations).
__IMNSHO__:
these values have no mathematical use (if one doesn't know much math,
one might be tempted to think that +-Inf has some mathematical meaning,
and that would be wrong).
more precisely, Inf/NaN means that the coder is doing something wrong
and must fix his code (and errors are more useful for that).
OTOH, underflow does _not_ necessarily mean a code error,
thus returning 0 is a perfectly valid approach.
In short, Inf/NaN are no better than (or (ignore-errors ...) 'NaN)
The only reason they exist is that C does not have exceptions.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://truepeace.org>
<http://www.memri.org/> <http://www.jihadwatch.org/> <http://pmw.org.il/>
Programming is like sex: one mistake and you have to support it for a lifetime.
Christophe Rhodes
>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 20:41:17 +0100]:
>>
>> Sam Steingold <s...@gnu.org> writes:
>>
>>> CLISP never signals inexact or invalid.
>>
>> What do you do for (/ 0.0 0.0)?
>
> divide-by-zero
OK. [ I'm sure you know this, but IEEE prescribes that this should in
fact signal invalid (or set the invalid accrued flag). ]
>> +Inf.0, -Inf.0? (In the IEEE world, these, and NaN which is the
>> result of a non-trapping inexact operation, have particular
>> well-defined properties on the basic arithmetic operations).
>
> __IMNSHO__:
>
> these values have no mathematical use (if one doesn't know much math,
> one might be tempted to think that +-Inf has some mathematical meaning,
> and that would be wrong).
Possibly. I'm not actually well enough versed in numerical analysis
to argue this point with you, so suffice it to say that if that is
what you think, having read the literature to the contrary, so be it.
Christophe
Bradley J Lucier
>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 20:41:17 +0100]:
>>
>> Sam Steingold <s...@gnu.org> writes:
>>
>>>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 19:46:45 +0100]:
>>>> What about the other IEEE-like exceptions -- overflow, invalid,
>>>> divide-by-zero, inexact? Do you provide for turning inexact traps
>>>> *on*, for instance? It's possible that there's an application out
>>>> there for that...
>>>
>>> CLISP never signals inexact or invalid.
>>
>> What do you do for (/ 0.0 0.0)?
>
>divide-by-zero
>
>>> overflow & divide-by-zero cannot be disabled.
>>> (what would you return on divide-by-zero or overflow?!)
>>
>> +Inf.0, -Inf.0? (In the IEEE world, these, and NaN which is the
>> result of a non-trapping inexact operation, have particular
>> well-defined properties on the basic arithmetic operations).
>
>__IMNSHO__:
>
>these values have no mathematical use (if one doesn't know much math,
>one might be tempted to think that +-Inf has some mathematical meaning,
>and that would be wrong).
Not at all, there is a lot of useful mathematics that works with the
"extended real numbers", see the entries under $E^*$ in the index of
the online undergraduate textbook at
http://www.trillia.com/zakon-analysisI.html
And, no, that's not the only text to present these ideas.
>more precisely, Inf/NaN means that the coder is doing something wrong
>and must fix his code (and errors are more useful for that).
Again, not at all. There are several papers on Kahan's web site at Berkeley
that shows the use of Inf and -Inf.
Brad
Pascal Bourguignon
> OTOH, underflow does _not_ necessarily mean a code error,
> thus returning 0 is a perfectly valid approach.
I think returning the LEAST-*-*-FLOAT of the same sign and type would
be a better approach.
There's a qualitative difference between 1e-123456 and 0
but only a quantitative diference between 1e-123456 and and 1e-123456789.
In my small experience, clisp behavior in case of underflow is good.
It helped me to detect errors, and it still allows the programmer to
decide what to do in case of underflow.
--
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
Sam Steingold
>
>>these values have no mathematical use (if one doesn't know much math,
>>one might be tempted to think that +-Inf has some mathematical meaning,
>>and that would be wrong).
>
> Not at all, there is a lot of useful mathematics that works with the
> "extended real numbers", see the entries under $E^*$ in the index of
> the online undergraduate textbook at
>
> http://www.trillia.com/zakon-analysisI.html
>
> And, no, that's not the only text to present these ideas.
if you are talking about the ||.||_{\infty} norm, then it is, of course,
enormously useful, but it has nothing to do with the floating point +-Inf.
Let us not confuse it (fp +-Inf) with the many places +-oo appears in
math texts. every time you see the symbol there, it has a very
precisely defined context-specific meaning, and that meaning has nothing
to do with arithmetical operations.
>>more precisely, Inf/NaN means that the coder is doing something wrong
>>and must fix his code (and errors are more useful for that).
>
> Again, not at all. There are several papers on Kahan's web site at
> Berkeley that shows the use of Inf and -Inf.
can you please be more specific?
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.iris.org.il>
<http://ffii.org/> <http://www.dhimmi.com/> <http://www.savegushkatif.org>
Takeoffs are optional. Landings are mandatory.
Sam Steingold
>
> Sam Steingold <s...@gnu.org> writes:
>
>>> * Christophe Rhodes <pf...@pnz.np.hx> [2005-08-09 20:41:17 +0100]:
>>>
>>> Sam Steingold <s...@gnu.org> writes:
>>>
>>>> CLISP never signals inexact or invalid.
>>>
>>> What do you do for (/ 0.0 0.0)?
>>
>> divide-by-zero
>
> OK. [ I'm sure you know this, but IEEE prescribes that this should in
> fact signal invalid (or set the invalid accrued flag). ]
Actually, I did not know that (my feeble excuse is that I am a
mathematician, not a CS). Thanks for the clarification.
I observe that CMUCL signals FLOATING-POINT-INVALID-OPERATION while ACL
and LW signal DIVIDE-BY-ZERO for (/ 0.0 0.0).
Oh well, I guess they are just not compliant.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://pmw.org.il/> <http://www.jihadwatch.org/> <http://www.camera.org>
<http://www.openvotingconsortium.org/> <http://www.savegushkatif.org>
Two wrongs don't make a right, but three rights make a left.
Bradley J Lucier
>> * Bradley J Lucier <o...@pf.cheqhr.rqh> [2005-08-09 15:55:57 -0500]:
>>
>>>these values have no mathematical use (if one doesn't know much math,
>>>one might be tempted to think that +-Inf has some mathematical meaning,
>>>and that would be wrong).
>>
>> Not at all, there is a lot of useful mathematics that works with the
>> "extended real numbers", see the entries under $E^*$ in the index of
>> the online undergraduate textbook at
>>
>> http://www.trillia.com/zakon-analysisI.html
>>
>> And, no, that's not the only text to present these ideas.
>
>if you are talking about the ||.||_{\infty} norm,
No, I wasn't thinking of that.
>but it has nothing to do with the floating point +-Inf.
>Let us not confuse it (fp +-Inf) with the many places +-oo appears in
>math texts. every time you see the symbol there, it has a very
>precisely defined context-specific meaning, and that meaning has nothing
>to do with arithmetical operations.
The text I referred to does define arithmetic operations on +-Inf.
And they're useful.
>>>more precisely, Inf/NaN means that the coder is doing something wrong
>>>and must fix his code (and errors are more useful for that).
>>
>> Again, not at all. There are several papers on Kahan's web site at
>> Berkeley that shows the use of Inf and -Inf.
>
>can you please be more specific?
I don't have a whole lot of time to look through Kahan's web
site (on Saturyday I'm moving to the U. of Minnesota for the year),
but there are some examples on pages 10-13 of IEEE754.pdf at
http://www.cs.berkeley.edu/~wkahan/ieee754status/
I can't find the following paper online right now (I'm sure it was
online before), but I think it had several examples:
Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit
in The State of the Art in Numerical Analysis, (eds. Iserles and Powell), Clarendon Press, Oxford, 1987.
Brad
<blank lines to get around brain-dead posting program, sorry>
Sam Steingold
>
> The text I referred to does define arithmetic operations on +-Inf.
> And they're useful.
no doubt.
but they do not turn R\cup{+-Inf} into a field.
> I don't have a whole lot of time to look through Kahan's web
> site (on Saturyday I'm moving to the U. of Minnesota for the year),
> but there are some examples on pages 10-13 of IEEE754.pdf at
> http://www.cs.berkeley.edu/~wkahan/ieee754status/
cool, very interesting, thanks.
this example confirms my impression that Inf is useful for specialty
high performance algorithms that are probably coded in assembly anyway.
thanks for enlightening!
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.mideasttruth.com/> <http://www.jihadwatch.org/>
<http://ffii.org/> <http://truepeace.org>
Growing Old is Inevitable; Growing Up is Optional.
Bradley J Lucier
>> * Bradley J Lucier <o...@pf.cheqhr.rqh> [2005-08-09 16:58:40 -0500]:
>>
>> The text I referred to does define arithmetic operations on +-Inf.
>> And they're useful.
>
>no doubt.
>but they do not turn R\cup{+-Inf} into a field.
I never said it did. I just said they're defined and useful. Just as
in IEEE 754/854 arithmetic.
>
>> I don't have a whole lot of time to look through Kahan's web
>> site (on Saturyday I'm moving to the U. of Minnesota for the year),
>> but there are some examples on pages 10-13 of IEEE754.pdf at
>> http://www.cs.berkeley.edu/~wkahan/ieee754status/
>
>cool, very interesting, thanks.
>
>this example confirms my impression that Inf is useful for specialty
>high performance algorithms that are probably coded in assembly anyway.
I don't see how you can get this impression at all from Kahan's writings;
if you read his discussions about Java, for example, you see that he
intends all these applications to be programmed in a high-level language.
Brad
robert...@gmail.com
my comments are probably useless, but it will make
me feel better to get this off my chest...
Sam Steingold wrote:
> these values have no mathematical use (if one doesn't
> know much math, one might be tempted to think that +-Inf
> has some mathematical meaning, and that would be wrong).
>
> more precisely, Inf/NaN means that the coder is doing
> something wrong and must fix his code (and errors are
> more useful for that).
>
> OTOH, underflow does _not_ necessarily mean a code error,
> thus returning 0 is a perfectly valid approach.
>
> In short, Inf/NaN are no better than (or (ignore-errors
> ...) 'NaN) The only reason they exist is that C does not
> have exceptions.
Inf/NaN were invented by the IEEE 754 committee because
they are useful constructs. A result equal to Inf or NaN
might or might not be an error, and furthermore even if
it is an error, throwing an exception might be the less
desirable action.
I once had a job doing statistics. Inf and NaN had their
place there. NaN, especially, was quite useful:
real-world data sets always have some missing values.
Representing missing values with NaN was a simple way
keep track of them. Computations on missing values
would yield a missing value as the output; this is
much preferable to having a long computation on a
million records barf on item 137,452 in the middle
of the night, and it is also preferable to protecting
each of dozens of computations with an exception check.
Incidentally (or (ignore-errors ...) 'NaN) is not
equivalent to returning a floating point NaN,
since the symbol NaN does not have the same
properties as floating point NaN. (eq 'NaN 'NaN) => t
instead of nil, and anyway 'NaN is not a floating
point number, so if you store it in an array or a
file with some floats, it is not the case that all
the items have the same type.
Sam, in case you haven't made up your mind about
Inf/NaN and IEEE 754 conformance in general,
I urge you to allow Clisp to return special floating
point values on at the least the platforms with
conforming hardware, which covers Pentium, Sparc,
PowerPC, and other processors.
For what it's worth,
Robert Dodier
Robert Dodier
> I observe that CMUCL signals
> FLOATING-POINT-INVALID-OPERATION while ACL
> and LW signal DIVIDE-BY-ZERO for (/ 0.0 0.0).
> Oh well, I guess they are just not compliant.
It is possible to modify CMUCL's behavior via
(extensions::set-floating-point-modes :traps nil) .
(extensions::get-floating-point-modes)
shows current floating point flags.
GCL allows the computation of Inf and NaN,
but barfs on attempting to display them.
(setq a (* 1e300 1e300) b nil) succeeds
but then attempting to display a yields
"Can't print a non-number."
Kenny Tilton
robert...@gmail.com wrote:
> OK, given the direction this discussion is taking,
> my comments are probably useless, but it will make
> me feel better to get this off my chest...
>
> Sam Steingold wrote:
>
>
>>these values have no mathematical use (if one doesn't
>>know much math, one might be tempted to think that +-Inf
>>has some mathematical meaning, and that would be wrong).
>>
>>more precisely, Inf/NaN means that the coder is doing
>>something wrong and must fix his code (and errors are
>>more useful for that).
>>
>>OTOH, underflow does _not_ necessarily mean a code error,
>>thus returning 0 is a perfectly valid approach.
>>
>>In short, Inf/NaN are no better than (or (ignore-errors
>>...) 'NaN) The only reason they exist is that C does not
>>have exceptions.
>
>
> Inf/NaN were invented by the IEEE 754 committee because
> they are useful constructs.
to the committee.
A result equal to Inf or NaN
> might or might not be an error,
when would it not be an error?
and furthermore even if
> it is an error, throwing an exception might be the less
> desirable action.
>
> I once had a job doing statistics. Inf and NaN had their
> place there. NaN, especially, was quite useful:
> real-world data sets always have some missing values.
> Representing missing values with NaN was a simple way
> keep track of them.
sounds like a typical kludge, and those are always wrong and non-simple.
Computations on missing values
> would yield a missing value as the output;
nonsense. one should never compute on crap. one either traps crap before
computing or gets an exception. are you trying to make programming
harder than it is? then by all means have bullshit computations run as
long as possible and preferably to completion. I recommend substituting
42 for NAN, however.
this is
> much preferable to having a long computation on a
> million records barf on item 137,452 in the middle
> of the night,
ok, look, at this point it is clear that you hate programming and have
no interest in it or correctness.
and it is also preferable to protecting
> each of dozens of computations with an exception check.
jeez, have you ever heard of macros? no, it is easier to have dozens of
computations flailing away at NANs...
>
> Incidentally (or (ignore-errors ...) 'NaN) is not
> equivalent to returning a floating point NaN,
> since the symbol NaN does not have the same
> properties as floating point NaN. (eq 'NaN 'NaN) => t
> instead of nil, and anyway 'NaN is not a floating
> point number, so if you store it in an array or a
> file with some floats, it is not the case that all
> the items have the same type.
the only problem here is trying to take NAN seriously. I suggest you try
instead bursting out loud in laughter. this is lisp. we take computation
seriously. pwuuaahahahahahahah!
:)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Sam Steingold
>
>>this example confirms my impression that Inf is useful for specialty
>>high performance algorithms that are probably coded in assembly anyway.
>
> I don't see how you can get this impression at all from Kahan's
> writings; if you read his discussions about Java, for example, you see
> that he intends all these applications to be programmed in a
> high-level language.
then he is confused.
nan is not a number.
neither is inf.
making them representable as C float/double is _kludge_ to overcome the
static typing limitations.
I am not saying this is not a good idea - as Kahan shows,
it _can_ be very useful to speed up computations.
I am saying that Lisp has a better way to handle this problem.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://www.camera.org>
<http://www.dhimmi.com/> <http://pmw.org.il/> <http://truepeace.org>
Live free or die.
Robert Dodier
> ok, look, at this point it is clear that you hate
> programming and have no interest in it or correctness.
Please go outside, Kenny, the grownups are trying to talk.
Robert Dodier
Christophe Rhodes
>> * Bradley J Lucier <o...@pf.cheqhr.rqh> [2005-08-09 17:49:24 -0500]:
>>
>>>this example confirms my impression that Inf is useful for specialty
>>>high performance algorithms that are probably coded in assembly anyway.
>>
>> I don't see how you can get this impression at all from Kahan's
>> writings; if you read his discussions about Java, for example, you see
>> that he intends all these applications to be programmed in a
>> high-level language.
>
> then he is confused.
> nan is not a number.
> neither is inf.
> making them representable as C float/double is _kludge_ to overcome the
> static typing limitations.
>
> I am not saying this is not a good idea - as Kahan shows,
> it _can_ be very useful to speed up computations.
>
> I am saying that Lisp has a better way to handle this problem.
If you're saying that, why are you bothering to ask opinions? Just do
whatever it is you were going to do anyway.
Again, I don't _know_, but absent knowledge I am willing to take on
trust the opinion of certain smart people that it is desireable to
have the degree of control over the performance characterstics of
execution time that IEEE 754 encourages implementors to provide.
In particular, I can believe that for certain applications the cost of
trapping and handling hardware exceptions in software is completely
prohibitive, and that allowing the exceptional values to propagate
does not lead to incorrect results being generated; I have no formal
proof to the contrary, and I doubt that one exists.
Since floating point numbers don't form a directly-isomorphic-to-|R
field in any case, why should the "numberness" or otherwise of Inf and
NaN have anything to do with it?
Christophe
Duane Rettig
> > * Bradley J Lucier <o...@pf.cheqhr.rqh> [2005-08-09 17:49:24 -0500]:
> >
> >>this example confirms my impression that Inf is useful for specialty
> >>high performance algorithms that are probably coded in assembly anyway.
> >
> > I don't see how you can get this impression at all from Kahan's
> > writings; if you read his discussions about Java, for example, you see
> > that he intends all these applications to be programmed in a
> > high-level language.
>
> then he is confused.
Amazing. One of the primary consultants to the IEEE 754 standard is
confused?
> nan is not a number.
Absolutely. NaN stands for Not a Number.
> neither is inf.
Not true. It is an exceptional number, but a number just the same.
Otherwise it would be called a NaN.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duncan Harvey
> > It appears that CLISP is the only CL that signals
> > FLOATING-POINT-UNDERFLOW in this code:
> >
> > (loop with x = 1 while (plusp x) do (setq x (/ x 100)))
>
> I meant, of course,
> (loop with x = 1f0 while (plusp x) do (setq x (/ x 100f0)))
> or
> (loop with x = 1d0 while (plusp x) do (setq x (/ x 100d0)))
>
> > is there any reason to signal that at all (as opposed to returning 0)?
Isn't this signalling behaviour required (for safe code) by 12.1.4.3?
> An error of type floating-point-overflow or floating-point-underflow
> should be signaled if a floating-point computation causes exponent
> overflow or underflow, respectively.
1.4.2 defines what "an error should be signaled" means.
--
Duncan Harvey
Robert Dodier
> making them representable as C float/double is _kludge_ to
> overcome the static typing limitations.
>
> I am not saying this is not a good idea - as Kahan shows,
> it _can_ be very useful to speed up computations.
Computation speed is not the primary motivation behind
the invention of special floating point values.
The motivation is that Inf, NaN, and signed zero are
useful concepts quite independently of how long it takes
to compute them.
Bradley J Lucier
>> * Bradley J Lucier <o...@pf.cheqhr.rqh> [2005-08-09 17:49:24 -0500]:
>>
>>>this example confirms my impression that Inf is useful for specialty
>>>high performance algorithms that are probably coded in assembly anyway.
>>
>> I don't see how you can get this impression at all from Kahan's
>> writings; if you read his discussions about Java, for example, you see
>> that he intends all these applications to be programmed in a
>> high-level language.
>
>then he is confused.
William Kahan, who is a member of the American Academy of Arts and Sciences,
an ACM Turing Award winner, and a Foreign Associate of the National Academy
of Engineering (like a regular member, only for non-US citizens [he's
Canadian]), is widely recognized as the world's foremost authority on
floating-point arithmetic, its hardware and software implementation, and
the design of floating-point operations and library functions in programming
languages. Kahan has a web page at
http://www.cs.berkeley.edu/~wkahan/
where he has some documents discussing the issues of floating-point
arithmetic implementation in programming languages.
If you go through the X3J13 "Number Issues" of the Common Lisp HyperSpec at
http://www.lispworks.com/documentation/HyperSpec/Issues/IC_NUM.htm
you'll see several places where Guy Steele says that he will consult with
Kahan about the issues.
I think people implementing floating-point arithmetic should take Kahan's
opinions into account.
But, of course, you can do as you like with CLISP.
Brad
Sam Steingold
>
> I think people implementing floating-point arithmetic should take
> Kahan's opinions into account.
no doubt.
> But, of course, you can do as you like with CLISP.
CLISP floating-point arithmetic has been implemented over a decade ago
by Bruno Haible and Michael Stoll.
~7 years ago I had to fight to have ANSI floating-point contagion added.
(the summary of the argument is in the CLISP implementation notes).
If you or anyone else wants to add NaN or +-Inf or +-0 or gradual
underflow &c to CLISP, you are welcome to work on that.
SHTDI (http://cygwin.com/acronyms/#SHTDI)
PTC (http://cygwin.com/acronyms/#PTC).
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.jihadwatch.org/>
<http://www.honestreporting.com> <http://pmw.org.il/>
Lisp: Serious empowerment.
Fred Gilham
Kenny Tilton writes:
> when would it not be an error?
Hi, Kenny,
Here's a justification for continuing computations in such a
situation. This is from the paper, "What Every Computer Scientist
Should Know About Floating Point Arithmetic" by David Goldberg.
----
Traditionally the computation of 0/0 or sqrt(-1) has been treated as
an unrecoverable error which causes a computation to halt. However,
there are examples where it makes sense for a computation to continue
in such a situation. Consider a subroutine that finds the zeros of a
function f, say zero(f). Traditionally, zero finders require the user
to input an interval [a, b] on which the function is defined and over
which the zero finder will search. That is, the subroutine is called
as zero(f, a, b). A more useful zero finder would not require the
user to input this extra information. This more general zero finder
is especially appropriate for calculators, where it is natural to
simply key in a function, and awkward to then have to specify a
domain. However, it is easy to see why most zero finders require a
domain. The zero finder does its work by probing the function f at
various values. If it probed for a value outside the domain of f, the
code for f might well compute 0/0 or sqrt(-1), and the computation
would halt, unnecessarily aborting the zero finding process.
The problem can be avoided by introducing a special value called NaN,
and specifying that the computation of expressions like 0/0 and
sqrt(-1) produce NaN rather than halting....
----
--
Fred Gilham gil...@csl.sri.com
When trying to reach the lowest common denominator, you have to be
prepared for the occasional division by zero.
M Jared Finder
That seems to me to be an argument for making the result of calculating
0/0 raise a condition. For the extent of the zero finding function, 0/0
should return some nonsense value, like :not-a-number, but in other
code, where continuing when calculating 0/0 is not desirable, you get
thrown into the debugger.
I'm going to have to agree with Kenny that both 0/0 and 1/0 should raise
a condition and not return some value that's not a number.
-- MJF
Christophe Rhodes
> I'm going to have to agree with Kenny that both 0/0 and 1/0 should
> raise a condition and not return some value that's not a number.
In all circumstances?
Ironically, of course, raising a condition is exactly what the
hardware is doing for floating point versions of those computations,
unless you ask it not to, at which point the hardware will run a
USE-VALUE restart and continue with values that numerical analysts
have taken time to ensure that they make the most sense possible under
the circumstances. The urge to make all of this happen in software,
orders of magnitude slower, is bizarre to say the least.
I don't claim to be the most informed about hardware implementations
of floating point arithmetic, nor of algorithms using the exotic
numbers, but I'm happy to entertain the notion that there are uses for
these "wrong answers" at hardware speeds. So, I don't care what the
default is, but please don't tie peoples' hands.
Christophe
rif
Without direct IEEE handling of Inf, what's the easiest way to handle
computing something like
f(x) = sum_i exp(-1/(x - a_i)^2)
where x may be very close to (but not equal to) one of the a_i?
rif
M Jared Finder
> M Jared Finder <ja...@hpalace.com> writes:
>
>>I'm going to have to agree with Kenny that both 0/0 and 1/0 should
>>raise a condition and not return some value that's not a number.
>
> In all circumstances?
>
> Ironically, of course, raising a condition is exactly what the
> hardware is doing for floating point versions of those computations,
> unless you ask it not to, at which point the hardware will run a
> USE-VALUE restart and continue with values that numerical analysts
> have taken time to ensure that they make the most sense possible under
> the circumstances. The urge to make all of this happen in software,
> orders of magnitude slower, is bizarre to say the least.
My experience is the reverse. The hardware restart is invoked unless I
explicitly ask to disable it. For my sanity, please make the default to
error loudly, and not use some other value. Most of the time I want
that extra debugging information; I'll ask to throw it away when I need
the extra speed.
-- MJF
rif
> My experience is the reverse. The hardware restart is invoked unless
> I explicitly ask to disable it. For my sanity, please make the
> default to error loudly, and not use some other value. Most of the
> time I want that extra debugging information; I'll ask to throw it
> away when I need the extra speed.
I don't really care whether the error is signalled by default, or
whether an Inf or Nan is generated silently by default, as long as I
have the ability to get the latter behavior. Without that ability (my
understanding is that CLISP does not have it), a lot of computations
become much more difficult.
For instance, suppose I want to calculate
f(x) = sum_i exp(-1/(x - a_i)^2)
where I don't know how close the x will be to one of the a_i's (assume
it's not quite equal to them). In standard IEEE, if x is very close
to a_i, -1/(x - a_i)^2 generates a -Inf (in default CMUCL or CLISP, a
division by zero error), but the exp will generate 0, so it gets added
up correctly and I'm done. If CL is erroring loudly and I have to
catch it every time this happens, what do I do? I either go through a
ton of pain each time I want to write a function like this (catching
all the possible problems individually), or I reimplement a version of
IEEE that includes Inf and NaN on top of the one that doesn't, by
making each "number" an object that holds either a number, or
information indicating that the computation gave me an Inf (or NaN).
Probably I do the latter, but then I've got something that's no more
useful than original IEEE, and vastly slower.
For a lot of numerical work, it's very important to expose the ability
to quietly get Inf's at least (NaN's I'm not as sure about). The
ability to manipulate Inf's directly means that a lot of computations
will do the right thing. Instead of arguing whether Inf is a number
or not, can we instead treat Inf as an IEEE abstraction for "a number
bigger than any number I can represent explicitly", with the
understanding that under this abstraction, IEEE rounding rules still
hold? For instance, whatever number generated the Inf, the closest
floating-point number to 1/Inf will be 0.
rif
lin8080
Sam Steingold schrieb:
> CLISP is the only CL I tested that signals a FLOATING-POINT-UNDERFLOW
> error here.
> ACL, LW, GCL, CMUCL all just return NIL.
> Any other opinions?
NIL is everything, FLOATING-POINT-UNDERFLOW is exactly this.
stefan