Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7832895C0 for ; Wed, 16 Nov 2011 19:20:47 +0000 (UTC) Received: (qmail 17315 invoked by uid 500); 16 Nov 2011 19:20:46 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 17209 invoked by uid 500); 16 Nov 2011 19:20:46 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 17201 invoked by uid 99); 16 Nov 2011 19:20:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Nov 2011 19:20:46 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com designates 209.85.210.41 as permitted sender) Received: from [209.85.210.41] (HELO mail-pz0-f41.google.com) (209.85.210.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Nov 2011 19:20:40 +0000 Received: by pzk37 with SMTP id 37so140857pzk.0 for ; Wed, 16 Nov 2011 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ByArwwNbRCrbHCo1Sv//mxE3WYIhfNtlX/Pw4DRFxdg=; b=X9ky/Xk1FTy5D8n2UGHbCOhPuE1TJk/acEsmy8pc4lpVTVFmA3kMXE4bT1vALJoifg y3QNCHwbMT83fCBbGNdgEh9rbpN6RWdi6l3BhFW5Lx268bMtx7p8TtiRfAc+KhUx2rCd JJkHSVclMEyu/WO3pzPeR6l7Fn3Ouhf/WlN3Q= Received: by 10.50.94.229 with SMTP id df5mr34359111igb.27.1321471216036; Wed, 16 Nov 2011 11:20:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.159.200 with HTTP; Wed, 16 Nov 2011 11:19:55 -0800 (PST) In-Reply-To: <20111116161940.GS8910@dusk.harfang.homelinux.org> References: <20111116132838.GR8910@dusk.harfang.homelinux.org> <20111116161940.GS8910@dusk.harfang.homelinux.org> From: Ted Dunning Date: Wed, 16 Nov 2011 11:19:55 -0800 Message-ID: Subject: Re: [Math] x + h - x != h To: Commons Developers List Content-Type: multipart/alternative; boundary=e89a8f2353ff69a94e04b1defee3 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f2353ff69a94e04b1defee3 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 16, 2011 at 8:19 AM, Gilles Sadowski < gilles@harfang.homelinux.org> wrote: > On Wed, Nov 16, 2011 at 07:52:27AM -0800, Ted Dunning wrote: > > The JVM is likely to in-line dummy, realize it does nothing and then > > coalesce your other code. > > > > It isn't any wonder that this produces the same results. > > I'm not sure I understand what you mean: Does "coalesce" means that > x + delta - x > will be equal to > delta > ? > No. Just that the in-lined code will disappear. I don't think that the JIT is naive enough to simplify away the subtraction. > The issue is whether an optimization could do that transformation. > If there are cases where IEEE FP arithmetic allows x + delta - x != delta then the optimization should not happen. Obviously, if x is NaN or infinite, this holds. Also, it is clear that (x+delta) - x != delta for some values of delta so I doubt that the optimization happens. [Note that I did not implement any "dummy" function but rather called the > quite non-dummy "doubleToLongBits" and "longBitsToDouble".] > If you didn't actually use the results, then it will disappear. If you called the java.math routines to do this, then those may be known to be inverses and disappear as well. If you called your own implementations and actually use the bits, then it will probably survive. --e89a8f2353ff69a94e04b1defee3--