Double vs DFloNum equivalency

Double vs DFloNum equivalency

[Per Bothner]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

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?
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

[-- Attachment #2: quaternion-test.patch --]
[-- Type: text/x-patch, Size: 2028 bytes --]

Index: testsuite/quaternion-test.scm
===================================================================
--- testsuite/quaternion-test.scm	(revision 8483)
+++ testsuite/quaternion-test.scm	(working copy)
@@ -167,19 +167,19 @@
        (m3 (quaternion->rotation-matrix (* q q q)))) ; 360 degrees
   ;; for a 120-degree rotation about (1,1,1),  +X->+Y, +Y->+Z, +Z->+X
   ;; m1 is #2a((0 0 1) (1 0 0) (0 1 0))
-  (test-equal '(0.0 1.0 0.0) (list (m1 0 0) (m1 1 0) (m1 2 0))) ; col 0
-  (test-equal '(0.0 0.0 1.0) (list (m1 0 1) (m1 1 1) (m1 2 1))) ; col 1
-  (test-equal '(1.0 0.0 0.0) (list (m1 0 2) (m1 1 2) (m1 2 2))) ; col 2
+  (test-equal '(0.0d0 1.0d0 0.0d0) (list (m1 0 0) (m1 1 0) (m1 2 0))) ; col 0
+  (test-equal '(0.0d0 0.0d0 1.0d0) (list (m1 0 1) (m1 1 1) (m1 2 1))) ; col 1
+  (test-equal '(1.0d0 0.0d0 0.0d0) (list (m1 0 2) (m1 1 2) (m1 2 2))) ; col 2
   ;; for 240 degrees, +X->+Z, +Y->+X, +Z->+Y
-  (test-equal '(0.0 0.0 1.0) (list (m2 0 0) (m2 1 0) (m2 2 0))) ; col 0
-  (test-equal '(1.0 0.0 0.0) (list (m2 0 1) (m2 1 1) (m2 2 1))) ; col 1
-  (test-equal '(0.0 1.0 0.0) (list (m2 0 2) (m2 1 2) (m2 2 2))) ; col 2
+  (test-equal '(0.0d0 0.0d0 1.0d0) (list (m2 0 0) (m2 1 0) (m2 2 0))) ; col 0
+  (test-equal '(1.0d0 0.0d0 0.0d0) (list (m2 0 1) (m2 1 1) (m2 2 1))) ; col 1
+  (test-equal '(0.0d0 1.0d0 0.0d0) (list (m2 0 2) (m2 1 2) (m2 2 2))) ; col 2
   ;; for 360 degrees, matrix is identity -- but we're on the other
   ;; side of the hypersphere: q^3 == -1
   (test-equal -1 (* q q q))
-  (test-equal '(1.0 0.0 0.0) (list (m3 0 0) (m3 1 0) (m3 2 0))) ; col 0
-  (test-equal '(0.0 1.0 0.0) (list (m3 0 1) (m3 1 1) (m3 2 1))) ; col 1
-  (test-equal '(0.0 0.0 1.0) (list (m3 0 2) (m3 1 2) (m3 2 2)))) ; col 2
+  (test-equal '(1.0d0 0.0d0 0.0d0) (list (m3 0 0) (m3 1 0) (m3 2 0))) ; col 0
+  (test-equal '(0.0d0 1.0d0 0.0d0) (list (m3 0 1) (m3 1 1) (m3 2 1))) ; col 1
+  (test-equal '(0.0d0 0.0d0 1.0d0) (list (m3 0 2) (m3 1 2) (m3 2 2)))) ; col 2
 (test-end "rotation-matrix")
 
 (test-begin "rotation-axis/angle")

Re: Double vs DFloNum equivalency

[Jamison Hope]

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

Re: Double vs DFloNum equivalency

[Per Bothner]

On 06/02/2015 10:18 AM, Jamison Hope wrote:
> 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

Ah, good point.

It seems useful to have sqrt when given a primitive (unboxed) double
to always return a double (maybe NaN), for performance at least.
We want double and java.lang.Double to behave the same.
So we probably do want the current behavior, and hence
(eqv? (->java.lang.Double 1.0) (->gnu.math.DFloNum 1.0)) should be #f.

So I guess the answer is to tweak quaternion-test.scm.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/