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
