Re: numeric tests

[Dirk Herrmann]

On 28 Jul 2001, Marius Vollmer wrote:

> > I have at first aimed at correctness and did not put a lot of effort
> > into performance.  Should I commit it to the CVS trunk anyway?
> 
> Yep, I'd say so.

OK, will do soon.

> > However, "#e9/10" _is_ accepted and gives 1, similarly "#e1.2" is
> > accepted as well and also gives 1 
> 
> I don't think they should be accepted.  If the user explcitely
> requests an exact number and we can't give it to him, we should not
> stealthily return an inexact number, or a number that is exact, but
> not the one the user has requested.

First, IMO, we should think about which numbers are considered OK by R5RS.
It is obvious that #e9/10 is allowed by R5RS, since 9/10 is an exact
number anyway - it is just guile's fault that we don't have exact
rationals.  #e1.2 should probably be allowed as well: 1.2 should be
considered implicitly inexact (according to R5RS), but this is just a
convention and for such situations R5RS allows to override the assumption
of inexactness with #e (see below).  But, what about #e1#?  1# is a number
with explicit inexactness.  Hmmm...

As soon as we are sure about this, we can think about how guile should
handle those.  Currently, we can't deliver #e9/10 as an exact number
without changing its value.  The same with #e1.2.  For #e1#, however, we
_can_ deliver an exact value, namely 10.

So, how should we handle the different cases in current guile?
#e1#   - don't accept
       - accept and return an exact number
#e9/10 - don't accept
       - accept and return an exact number
       - accept and return an inexact number
#e1.2  - don't accept
       - accept and return an exact number
       - accept and return an inexact number

R5RS does not state how implementations that don't have exact numbers
should handle #e.  However, it is stated that "an implementation in which 
all numbers are real may still be quite useful".  Hmmm....

> > I was not quite sure about the last two examples "#e9/10" and "#e1.2".  
> > R5RS does not state that the #e prefix in conjunction with an inexact
> > number should be disallowed.
> 
> Hmm, I don't understand.  What do you mean with "in conjunction with
> an inexact number"?  "1.2" is not inexact by itself, it is exactly
> 12/10.

According to R5RS, a number with a decimal point is implicitly considered
an inexact number.  Thus, 1.2 is inexact by definition, but #e1.2 is
12/10.

Best regards,
Dirk Herrmann