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

[Daniel Llorens <daniel.llorens@bluewin.ch>]

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