From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87967 invoked by alias); 2 Jun 2015 17:18:40 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 87953 invoked by uid 89); 2 Jun 2015 17:18:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail.theptrgroup.com Received: from mail.theptrgroup.com (HELO mail.theptrgroup.com) (71.178.251.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jun 2015 17:18:38 +0000 Received: from [10.11.21.62] (unknown [10.11.21.62]) by mail.theptrgroup.com (Postfix) with ESMTPS id 2B718E090A for ; Tue, 2 Jun 2015 13:18:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Double vs DFloNum equivalency From: Jamison Hope In-Reply-To: <556D1548.3070304@bothner.com> Date: Tue, 02 Jun 2015 17:18:00 -0000 Content-Transfer-Encoding: 7bit Message-Id: References: <556D1548.3070304@bothner.com> To: "kawa@sourceware.org list" X-IsSubscribed: yes X-SW-Source: 2015-q2/txt/msg00044.txt.bz2 On Jun 1, 2015, at 10:30 PM, Per Bothner 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