I am an algebraic geometer and not a numerical analyst, so I leave it to others to decide whether round-to-even or round-away-from-zero is better.

Some seem to argue that round-to-even is better. Those who argue in favor of round-away-from-zero seem to do so because it is implementable without any cost if a C FFI is present. However, even the C people will most likely get round-to-even: http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1778.pdf. (That TS aims for covering IEEE 754-2008 in a future C standard.)

For the time being, there's already roundeven in the GNU C library, and probably also in other implementations of the C standard library.

So, in the long run, it does not make sense not to use round-to-even just for the reason that there is no C equivalent. However, the naming would be irregular. In C, it will be called roundeven vs. flround in SRFI 144.

So far, so good. 

Now, when I read the definition of flround in SRFI 144, it says: "Returns the closest integral flonum not larger than x, rounding to even when x represents a number halfway between two integers. (Not the same as C99 round, which rounds away from zero)"

What does this actually mean? Doesn't the first half describe the behaviour of the floor function? The second half contradicts the first half in cases like 3.5, which, by the second part, is being rounded to 4, but 4 is larger than 3.5, contradicting the first half.

In contrast, in the TR mentioned above, it says: "The roundeven functions round their argument to the nearest integer value in floating-point format, rounding halfway cases to even (that is, to the nearest value whose least significant bit 0), regardless of the current rounding direction."



William D Clinger <xxxxxx@ccs.neu.edu> schrieb am Di., 18. Juli 2017 um 19:28 Uhr:
John Cowan wrote:

> The notion that a mere difference in marshaling conventions is in any way
> equivalent to the flround discrepancy is absurd.  The C procedures in
> question *do* return two values, using the regular C convention for doing
> so.

That convention is available in Scheme also, by passing a
bytevector of length 8 as the second argument and extracting
the result via bytevector-ieee-double-native-ref or similar.

> You can think what you like, say what you like, and do what you like on
> this point, but your implementation is tested against the behavior of
> libraries that conform to Posix/C99. and therefore amounts to a concession
> that (with the exception of flround), Posix/C99 is the prevailing standard.

If you insist upon this point, I will correct the sample
implementation and Larceny's implementation of SRFI 144 so they
require programmers to pass an 8-element bytevector as second
argument to the


procedures and as a third argument to the flremquo procedure.

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=L1OsVn7vrlnxb0ECqnMxrKaYv64BHIpQ