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