Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: higher precision doubles Date: Wed, 10 Aug 2011 08:50:00 +0200 Organization: albasani.net Lines: 62 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net Le+5JTCeo9VahVTrXV87AZw2TaB9rtqVNhljBoyvd3g9W+PDmMhvzEJ0mivuCnvSqbr1K9l1TN3QhKXeqLzqaQ== NNTP-Posting-Date: Wed, 10 Aug 2011 06:50:01 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="IKzK7PVZhUoDgb1AIEyy9gIpzLPMcf8PQ4oD9OqAlDIffJqeQTuGbFv0A55SUuZyTFI0PHSIbu1Bc1UU+7SqRIR1SqyFoPnRzxMDvc+aQ1fiEOpSu/BnWAtLJUJU+1J3"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 In-Reply-To: Cancel-Lock: sha1:8gXpT+QEZ87qcDkY23LbLkLpynA= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6952 Patricia Shanahan schrieb: > On 8/9/2011 5:00 AM, Jan Burse wrote: > ... >> The above document is a little bit sloppy, since it mentions >> only additional bits in the exponent. But 80bit doubles have >> both, additional bits in the mantissa and in the exponent. >> So differences might be more subtle. > ... > > My understanding from discussions at the time is that they were not > being sloppy. They had already solved dealing with the extra mantissa > bits, and remember the JLS defines *exactly* how numbers must round. > > Patricia Don't understand me wrong. I don't refer to the JLS or VM as being sloppy. Only the cert.org article, they write in the introduction: .. can provide extended floating-point support with exponents that contain more bits .. They should mention exponents AND mantissa. So we can turn their example: double x = Double.MAX_VALUE * 1.1 / 1.1; Into a mantissa problem by replacing it with: double x = 1 + 1.0E-nn - 1; With nn sufficiently big but not too big. Under 80bit x can receive the value 1.0E-nn whereas under 64bit the result is zero. So differences need not always be that dramatic that an overflow/underflow occurs/does not occur. Pitty I don't have an example at hand where the differences are dramatic and without reaching into overflow/underflow. Well doing it like that: double x = 1 / (1 + 1.0E-nn - 1). You get in 64bit a NaN and under 80bit no NaN, just something close to 1.0Enn. So the cert article and the Wikipedia Article could mention that under non-strict computation not only overflows and underflows can disappear, but also NaNs can suddently disappear. So if an application relies on NaNs appearing in certain situations, this application might behave differently under 64bit and 80bit. Could result in different runtimes to reach some closure condition etc.. Best Regards