Double vs DFloNum equivalency

[Per Bothner]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: quaternion-test.patch
Type: text/x-patch
Size: 2028 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/kawa/attachments/20150602/c2474508/attachment.bin>