Re: R5RS numbers

Marcin 'Qrczak' Kowalczyk wrote:

> Printing representation of infinities and nan is a separate issue
> discussed in that thread. I will tackle it later.

I think the current most widely-compatible printing representations
are +inf, -inf, and #nan .

> For anybody wanting to flame me: I did not invent -0.0 and nan, I only
> want to support them in the way IEEE and many languages and hardware
> processors do.

I don't think that going with IEEE instead of R5RS for floating-point
behavior is flameworthy. And mathematically, there are good reasos
for it.  Indeed, R5RS is probably in need of correction on this point.

I don't think that even the IEEE float behavior is fully correct
when exact numbers are distinguished from inexact numbers; the case
in point being that the "sign" of exact zero ought to be completely
insignificant.  IMO, if you're ever doing anything that gives
different results depending on the sign of zero, and it's an
*exact* zero, NaN, or an exact result, is probably a better
answer than going either way.  I'd regard the following as
correct behavior:

(/ 1 0.0) => +inf
(/ 1 -0.0) => -inf
(/ 1 #e0.0) => #nan

(sin 0.0) => 0.0
(sin -0.0) => -0.0
(sin #e0.0 => 0

(eqv? -0.0 +0.0) => #f
(eqv? #e-0.0 #e+0.0) => #t

But I'm sure not going to flame anyone for not implementing it;
it's above and beyond both IEEE and R5RS.

I will however, cheerfully continue flaming any implementation that
allows people to add or multiply two positive integers and get a
negative result.  I don't have a problem with bitstring-addition
and bitstring-multiplication, complete with overflow and wraparound,
having bindings, but pretending  that these are the mathematical
operations known as addition and multiplication is just wrong.  Even
if you don't have bignums, it is better to signal an error, get #nan,
or get an inexact floating-point answer, than to get a blatantly
wrong answer.

Bear