On 12/4/2012 1:14 PM, Raymond Toy wrote:
>>>>>> "Richard" == Richard Fateman <fateman at eecs.berkeley.edu> writes:
> Richard> I've been fiddling around with Allegro CL 9.0 and can't
> Richard> seem to produce a -0.0, so maybe I'm being overly
> Richard> optimistic about support for negative zero. It seems
> Richard> that CMU CL might provide support though.
>
> I know cmucl supports it, as does sbcl.
>
> A quick test with ccl and ecl shows that they also support signed
> zeroes.
>
> Of course, there's more to supporting signed zeroes than making (eql
> -0.0 0.0) return false. You should get all of the branch cuts for the
> special functions correct too. That's a much, much harder problem.
> I'm not sure cmucl has this all correct.
>
> The only time I've been bitten by signed zeroes is when dealing with
> branch cuts. And those are always hard, whether you have signed
> zeroes or not.
This might help
http://port70.net/~nsz/articles/float/kahan_branch_cuts_complex_elementary_functions_1987.pdf
but as I recall, the signed zero does not cure everything. For example
in the recent
discussion you might want to have
a signed pi -- for a number that is infinitesimally larger or smaller
than pi.
etc etc.
This does not fix the case when numbers that are supposed to be real but
end up with an infinitesimal imaginary
part . When you intend to return a sqrt(SmallPositiveReal) but because of
some glitch it comes out sqrt(SmallNegativeReal), and tada you are off
the real line.
I think it is important to keep in mind, with regard to computer algebra
systems, that
the IEEE standard is intended to be an engineering compromise between
the needs of
arithmetic and the constraints that floating point numbers must fit in a
finite space
such as 32, 64 or perhaps 128 bits, but fixed. And that overflow and
underflow
are eventualities that must be accommodated because the exponent fields
are fixed.
Computer algebra systems with software arbitrary-precision floats and
essentially
unlimited exponent range and precision do not have to abide by the same
compromises IF the application software is able to switch representation to
solve over/underflow or precision needs.
That's a big IF, but it vastly simplifies some software that would
otherwise have to
go through extreme contortions to get answers correct to a half ulp
(unit in the last place).
If you can just bump up precision by 5 bits, you can then round down.
This makes it
much more likely that you will be accurate enough for uses.
It also means that overflow/underflow checks are unnecessary.
RJF