[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: numeric tests
From: |
Dirk Herrmann |
Subject: |
Re: numeric tests |
Date: |
Sun, 29 Jul 2001 11:39:36 +0200 (MEST) |
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