Re: Double vs DFloNum equivalency

[Jamison Hope <jrh at theptrgroup dot com>]

On Jun 1, 2015, at 10:30 PM, Per Bothner <per@bothner.com> wrote:

> As mentioned, I'm trying to make uniform vectors more compatible
> with Java arrays, and also trying to make "boxing" primitive number
> types be the standard java.lang class.  Thus indexing a f64vector
> returns a double which is boxed as a java.lang.Double.
> 
> That may break some existing code.  However, Java really wants
> double to be boxed as Double, and for performance we want
> indexing a f64vector to return a double when inlined.  So I think
> we're being pushed to have f64vector-ref return a Double.
> 
> Long-term we might want to drop the DFloNum class and just
> use Double, but I think that is too big a change for right now.
> (I think it is worth pursuing in conjunction with using
> invokedynamic for arithmetic (when compile-time type information
> is lacking).
> 
> Surprising very little in the testsuite breaks.  One issue is
> the tests for quaternion->rotation-matrix in quaternion-test.scm.
> With my current changes, as an example (m1 0 0) returns a Double,
> but 0.0 is a DFloNum.
> 
> One solution is to fix the test - see the attached patch.
> 
> Another solution is to treat DFloNum and Double objects with
> identical (bit-bits) values for doubleValue as equivalent in
> terms of eqv? and thus equal?.  I haven't tried this, since I
> just through of it. It looks like a relatively simple
> change to IsEqual.numberEquals might do it.  It might be a
> better longer-term solution, especially if we end up moving
> away from DFloNum.
> 
> Thoughts?

I'm OK with the proposed change to the test suite; my intent was
to test whether those values are 0 and 1, not whether they're 0
and 1 instances of a particular class.

I probably should've used = there, as in
(test-assert (= 0 (m1 0 0)))
(test-assert (= 1 (m1 1 0)))
...



One major wrinkle if we want to make DFloNum and Double eqv? (with
or without the eventual goal of dropping DFloNum entirely) is what
to do about math functions which can produce complex results given
real arguments.

The spec says that if two inexact numbers are eqv?, then they must
produce eqv? results when passed to any finite composition of
Scheme's standard arithmetic procedures "provided it does not
result in a NaN value".  I take that to mean that it has to
produce NaN results for both, or non-NaN eqv? results for both.

Right now we've got cases where procedures will return Double.NaN
given double arguments but non-NaN Complex numbers given DFloNum:

(sqrt -1.0d0) => NaN
(sqrt -1.0) => +1.0i

(asin 1.01d0) => NaN
(asin 1.01) => 1.5707963267948966-0.1413037694856485i

(log -1.0d0) => NaN
(log -1.0) => +3.141592653589793i


--
Jamison Hope
The PTR Group
www.theptrgroup.com