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 [hidden email] http://per.bothner.com/ quaternion-test.patch (2K) Download Attachment |
On Jun 1, 2015, at 10:30 PM, Per Bothner <[hidden email]> 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 |
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 [hidden email] http://per.bothner.com/ |
Free forum by Nabble | Edit this page |