bug#13905: (max inexact exact) => always inexact?

bug#13905: (max inexact exact) => always inexact?

[Daniel Llorens]

Not necessarily a bug, but I'd like to hear some thoughts on this.

In current Guile

(max -inf.0 9) => 9.0

The manual says

> R5RS requires that, with few exceptions, a calculation involving inexact numbers always produces an inexact result [...] The only exception to the above requirement is when the values of the inexact numbers do not affect the result. For example (expt n 0) is ‘1’ for any value of n, therefore (expt 5.0 0) is permitted to return an exact ‘1’.

In fact, in current Guile

(expt 5.0 0) => 1

although (!)

(* -1.0 0) => 0.0

Anyway.

R5RS says specifically for max / min

> If any argument is inexact, then the result will also be inexact (unless the procedure can prove that the inaccuracy is not large enough to affect the result, which is possible only in unusual implementations).

Certainly, there are calculations that return -inf.0 when done with inexact arithmetic that would have returned {hugely negative exact number} if done with exact arithmetic. In this sense, the condition above doesn't hold. That doesn't justify (max -inf.0 9) => 9.0 either, of course.

My interest in this is that I don't want

(fold max -inf.0 exact-number-list)

to return an inexact number. I also find inconvenient that max doesn't return one of its arguments even though there's no NaN involved.

I've checked mzscheme and it does as Guile here.

Regards

	Daniel

bug#13905: (max inexact exact) => always inexact?

[Mark H Weaver]

tags 13905 notabug
close 13905
thanks

Daniel Llorens <daniel.llorens@bluewin.ch> writes:

> Not necessarily a bug, but I'd like to hear some thoughts on this.
>
> In current Guile
>
> (max -inf.0 9) => 9.0

Yes, and this is correct.  In general, the error of an inexact number is
unbounded.  Consider the inexact infinities (which really just mean some
number larger than the largest representable inexact number).  An
inexact infinity might be the result of taking the reciprocal of an
inexact number (let's call it 'X') that's very close to zero.  If 'X'
was slightly different, (/ X) might be anywhere from -inf.0 to +inf.0 or
anywhere in between.

A proper Scheme system must not produce an exact result unless that
result is *provably* the right answer, without any error whatsoever.  In
the case of (max -inf.0 9), we cannot say for sure that 9 is the right
answer, because the true value of the first argument could be anything.

> The manual says
>
>> R5RS requires that, with few exceptions, a calculation involving
>> inexact numbers always produces an inexact result [...] The only
>> exception to the above requirement is when the values of the inexact
>> numbers do not affect the result. For example (expt n 0) is ‘1’ for
>> any value of n, therefore (expt 5.0 0) is permitted to return an
>> exact ‘1’.
>
> In fact, in current Guile
>
> (expt 5.0 0) => 1

Right.  That's because (expt X N) for exact non-negative integer N is
equivalent to (* X ...) with N multiples of X.  Therefore (expt X 0) is
equivalent to (*), so the imprecision of X does not affect the result.

> (* -1.0 0) => 0.0

Yes, I did this deliberately, because (* +inf.0 0) => +nan.0.  However,
I've since come to believe that (* X 0) should be 0 for *any* X, even if
X is an infinity or NaN.  I should probably change this at some point.

> R5RS says specifically for max / min
>
>> If any argument is inexact, then the result will also be inexact
>> (unless the procedure can prove that the inaccuracy is not large
>> enough to affect the result, which is possible only in unusual
>> implementations).
>
> Certainly, there are calculations that return -inf.0 when done with
> inexact arithmetic that would have returned {hugely negative exact
> number} if done with exact arithmetic.

There are also calculations that return -inf.0 that would have returned
{hugely POSITIVE exact number} if done with exact arithmetic.  That's
precisely the reason why the result of (max -inf.0 9) must be inexact.

> My interest in this is that I don't want
>
> (fold max -inf.0 exact-number-list)
>
> to return an inexact number. I also find inconvenient that max doesn't
> return one of its arguments even though there's no NaN involved.

I understand that it would be convenient to avoid handling the empty
list specially in your example above, and I sympathize.  However, it is
far more important to never produce an exact result unless we can prove
that it is precisely equal to the result we would have gotten if exact
arithmetic was used everywhere.  This principle allows the construction
of provably correct programs involving arithmetic.

    Thanks,
      Mark

bug#13905: (max inexact exact) => always inexact?

[Mark H Weaver]

Daniel Llorens <daniel.llorens@bluewin.ch> writes:
> My interest in this is that I don't want
>
> (fold max -inf.0 exact-number-list)
>
> to return an inexact number.

By the way, there's an easy way to accomplish what you want.  Simply use
'reduce' (from SRFI-1) instead of 'fold':

(reduce max -inf.0 exact-number-list)

   Regards,
     Mark

bug#13905: (max inexact exact) => always inexact?

[Daniel Llorens]

On Mar 8, 2013, at 19:59, Mark H Weaver wrote:

> By the way, there's an easy way to accomplish what you want.  Simply use
> 'reduce' (from SRFI-1) instead of 'fold':
> 
> (reduce max -inf.0 exact-number-list)

I was about to roll my own, but this is exactly the case where fold doesn't work and reduce does.

Thank you,

	Daniel