Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #35761

Re: double == double

From Arne Vajhøj <arne@vajhoej.dk>
Newsgroups comp.lang.java.programmer
Subject Re: double == double
Date 2016-10-14 22:37 -0400
Organization Aioe.org NNTP Server
Message-ID <nts4og$127g$1@gioia.aioe.org> (permalink)
References <double-20161012130409@ram.dialup.fu-berlin.de> <ntlr0a$2iq$1@dont-email.me>

Show all headers | View raw


On 10/12/2016 1:14 PM, 4ndre4 wrote:
> On 12/10/2016 13:15, Stefan Ram wrote:
>>   Sometimes it is taught that it makes no sense to compare
>>   two double values with »==«.
>
> This is not necessarily true. It is a good rule to stick to, given that
> most of the times double values are results of computations, therefore
> subject to round-off errors, but it is not always true that == would
> fail. Consider this:
>
>         System.out.println(1.0 == 1.0);
>         double x = 0;
>         for (int i=0; i<50; i++) {
>             x += 1.0/50.0;
>         }
>         System.out.println(x == 1.0);
>
> On my machine, the first printing true, the second printing false.
>
> If it is granted that the double values are internally represented the
> same way (see the literals above), they are equal.

I think that the example seen as a whole actually say to avoid == on
double.

Sometimes it follows math rules sometimes it does not.

Usually it is too much work to analyze if it will work and
document it so the maintenance programmer know what can be
done and what can not be done without breaking the code.

The obvious solution is to avoid the construct.

Arne

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-12 18:14 +0100
  Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-14 22:37 -0400
    Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 07:36 +0100

csiph-web