Path: csiph.com!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: [OT] Re: missing import java.lang.Comparable
Date: Fri, 8 Jul 2016 20:18:19 -0400
Organization: Aioe.org NNTP Server
Lines: 33
Message-ID: <nlpfsd$v3d$1@gioia.aioe.org>
References: <drj6nb1mja17fads03ucr3v7mi2fcn2d36@4ax.com> <00835840-56aa-4ba2-b496-e364a62a38e8@googlegroups.com> <nl3d72$4qn$1@dont-email.me> <nl3o2f$b28$1@dont-email.me> <nl3rm7$r1d$1@dont-email.me> <8668311a-503f-46b6-909c-dcbfbfc5ce19@googlegroups.com> <nl41pc$apo$2@dont-email.me> <slrnnnc4cm.456.avl@login.logic.tuwien.ac.at> <e66db7c3-40cd-4df2-9e0e-9f23b0cb680c@googlegroups.com> <slrnnnivqf.456.avl@login.logic.tuwien.ac.at> <128e7e20-d311-413d-abbc-e885b34ae402@googlegroups.com> <slrnnnnr8l.456.avl@login.logic.tuwien.ac.at> <87dc5bee-f689-4f2e-90a8-a43a2de9fe49@googlegroups.com> <slrnnnsssr.456.avl@login.logic.tuwien.ac.at> <nlltdh$1u0$1@dont-email.me> <nlm1lh$iat$1@dont-email.me> <slrnnnt7ri.456.avl@login.logic.tuwien.ac.at> <nlmbm6$ndk$1@dont-email.me> <slrnnnunec.456.avl@login.logic.tuwien.ac.at> <nlo63s$293$1@dont-email.me> <c28c0b50-9105-4a51-930f-8721c3ed5bfd@googlegroups.com> <nlocjc$pmu$1@dont-email.me> <638a1d64-f125-4456-a20b-4dbf45f49da2@googlegroups.com>
NNTP-Posting-Host: 7SK6yTFfqwlIPNBLl3l7Qg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:34814

On 7/8/2016 10:35 AM, Eric Douglas wrote:
> On Friday, July 8, 2016 at 10:16:23 AM UTC-4, Eric Sosman wrote:
>> No one would want that.  Also, no one experiences that (not in
>> Java, at any rate).  I get your point, though, that floating-point
>> arithmetic can be surprising.
>
> I don't know if or how it happens with whole numbers offhand but it's
> definitely an issue with decimals, and that is more than financials.
> When you're trying to write an application that manages inventory
> quantities and calculates the decimals as in to represent the
> percentage of a can of paint, then this is a problem. Program: double
> a = .0002; double b = .0001; System.out.println(a + b); Result:
> 3.0000000000000003E-4

But that result is really correct.

.0002 +/- some uncertainty + .0001 +/- some uncertainty is 
3.0000000000000003E-4 +/- some uncertainty

But maybe your inventory system do not work with built in uncertainty.

Point being that in this case you should not use floating point either.

Every time you think about using float and double to store
some data always ask whether values has uncertainty. If not
drop float/double and start looking at something else
(maybe BigDecimal).

Arne