Re: Questions about floating numbers, rethink and bug report

[Keith Wright]

The following brief exchange happened about a month ago.  After further
thought I must modifiy my answer a bit.  I took the question as a
bug report, and stepped to the defence of Guile, perhaps a bit brusquely.
Taken as a suggestion for a new feature there is a bit more to think
about.

Before getting into philosophy, I want to mention that while poking
around and rethinking I found the following Bug.

    guile> (version)
    "1.5.2"
    guile> #E3
    3
    guile> #e3
    ERROR: read:uniform-vector list not found
    ABORT: (misc-error)
    guile> 3

This violates both R5RS 7.1 ``Case is insignificant'' and 

> From: guile-1.5.2/doc/ref/guile.info-3 Line 568
>
>     The codes for indicating exactness (which can, incidentally, be
>  applied to all numerical values) are:
>
>   * `#e', `#E' -- the number is exact

--------- end bug report --------

> From: Keith Wright <address@hidden>
> 
> > From: Ying Luo <address@hidden>
> > 
> > I have some question about floating numbers in guile-1.4,
> > which has annoyed me for quite a few times :(
> > 
> > Below is listed two of  the commands I typed in and got incorrect
> > results:
> > guile> (truncate (* 2127.7 100))  ==>    212769.0
> > guile> (zero? (- 264 (* 2.64 100))) ==>  #f
> 
> This is how it is with binary floating point, it has
> nothing much to do with Guile.  If you want exact results,
> you don't use floating point.

Indeed, Guile is within its rights to represent 2127.7 as
floating point, Ying Luo expected that it would be, and
given that, the answer is justifiable...but is it the best?

I thought that an implementation might be allowed, to treat
2127.7 as an exact rational number and represent it as
21277/10.  In fact R5RS 6.2.4 says:

> If the written representation of a number has no exactness prefix,
> the constant may be either inexact or exact.  It is inexact if it
> contains a decimal point, ...

so I think Guile is forbidden to claim an exact answer,
unless the constant is written as #e2127.7 but it is certainly
allowed to compute   (* 2127.7 100) ==> 212770.0
(the truncate is irrelevant except that it can make a small
error into a huge one)

So Guile arithmetic _could_ act as Ying Luo expects by
representing a decimal constant as numerator and denominator,
(possibly requiring the denominator to be a power of ten)
preserving this representation through some arithmetic operators,
and bringing in floating point only if the denominator got out
of hand.  The question is how to decide when to switch to
traditional floating point?

While poking around to find how this idea fits with the
current state and direction of Guile, I found the following:

> From: guile-1.5.2/doc/ref/guile.info-3 Line 578
> A consequence of the limited precision is that all real numbers in
> Guile are also rational, since any number R with a limited number of
> decimal places, say N, can be made into an integer by multiplying
> by 10^N.

This has strange consequences:
guile> (rational? (sqrt 2))  ==>  #t
guile> (rational? (exp 1))   ==>  #t

I think that Rational? should be true only if you can _prove_
the number is rational.  This would not necessarily imply
an exact rational.  If you were to compute say (/ 1 39282389248)
you might go to floating point because the denominator is
too unwieldy, thus getting an inexact number, but still it
could be safely marked as rational.  Rationality is preserved
through all four arithmetic operators, even if exactness is
lost.  However, it seems very strange to claim that the natural
logarithm base and the square root of two are rational just
_because_ you can not compute them exactly.

If your only numeric representations are traditional fixed
point and floating point, with no extra bits to indicate
rationality or exactness, then Rational? should be the same
as Integer?, not Real?, because exact integers are the only
numbers that can be _proven_ to be rational.

-- 
     -- Keith Wright  <address@hidden>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---