Re: Infinity (to the nearest integer)
Kevin Reid <kpreid-M/[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
On Oct 8, 2010, at 9:58, Thomas Leonard wrote:
> This is a bit surprising...
>
> ? Infinity.round()
> # value: 9223372036854775807
>
> ? NaN.floor()
> # value: 0
Following the implementation, I find that both are defined directly in
terms of java.lang.StrictMath, which has this to say:
> To help ensure portability of Java programs, the definitions of many
> of the numeric functions in this package require that they produce
> the same results as certain published algorithms. These algorithms
> are available from the well-known network library netlib as the
> package "Freely Distributable Math Library" (fdlibm).
In the field of floating-point arithmetic, I am inclined to be very
cautious about assuming that existing systems are doing something
wrong. However, our situation is different from these sources, in that
we are giving *bigint* rather than float or bounded integer results.
That makes these rules arbitrary:
> • If the argument is negative infinity or any value less than or
> equal to the value of Long.MIN_VALUE, the result is equal to the
> value of Long.MIN_VALUE.
> • If the argument is positive infinity or any value greater than or
> equal to the value of Long.MAX_VALUE, the result is equal to the
> value of Long.MAX_VALUE.
In all of {-Infinity,Infinity,NaN}.{floor,round}(), I see these as
reasonable options:
1. Return the argument, as all-floating operations usually do.
2. Throw an exception.
1 is an option where it is not in Java, because we do not define
necessarily-disjoint numeric types; but neither do we well support
"integer or NaN" and similar as a reasonable type.
Note that under sealed-exception rules throwing should never be used
for “handled” exceptional situations; therefore option 2 implies that
programs expecting a NaN/Infinity must test for it.
I am at the moment inclined to specify option 1. I welcome input from
people with more numeric experience than I.
--
Kevin Reid <http://switchb.org/kpreid/>