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

Groups > comp.lang.java.programmer > #35750 > unrolled thread

Re: double == double

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-12 09:39 -0400
    Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-13 21:10 +0200
      Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-15 14:04 +0200
        Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 09:13 -0400
          Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 10:32 -0400
            Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 10:46 -0400
              Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-15 17:44 +0200
              Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 17:36 +0100
                Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 14:15 -0400
                  Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 19:41 +0100
              Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 20:39 -0400
        Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 10:41 -0400
          Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 23:09 +0100
            Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 18:28 -0400
              Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:13 +0100
                Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-16 08:37 -0400
                  Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 14:06 +0100
            Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 20:30 -0400
              Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:16 +0100
                Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:18 +0100
                Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 09:45 -0400
                  Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 14:51 +0100
                    Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 11:24 -0400
                      Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 16:43 +0100
                        Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 12:54 -0400
                          Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 18:37 +0100
                            Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 14:14 -0400
                              Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 22:19 +0100
                                Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 22:49 -0400
                                  Re: double == double a.laforgia@gmail.com - 2016-10-17 01:53 -0700
                                    Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 19:04 +0200
                                      Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 20:17 +0100
                                        Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 23:11 +0200
                                          Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 22:46 +0100
                                            Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-18 18:55 +0200
                                              Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-18 18:52 +0100
                                                Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-20 15:03 +0200
                                          True O-O [Was: double == double] Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-17 18:06 -0400
                                            Re: True O-O Patrick Roemer <sangamon@netcologne.de> - 2016-10-18 18:32 +0200
                                            Re: True O-O [Was: double == double] Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 22:09 -0400
                                    Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:58 -0400
                                  Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 18:58 +0200
                                    Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 20:32 +0100
                                      Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 23:21 +0200
                                      Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:38 -0400
                                    Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:47 -0400
                                      Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-20 15:01 +0200

Page 1 of 3  [1] 2 3  Next page →

#35750 — Re: double == double

On 10/12/2016 8:15 AM, Stefan Ram wrote:
>   Sometimes it is taught that it makes no sense to compare
>   two double values with »==«.

     That's an oversimplification, of course.

>   But what about this function?
>
> public static double max( final double a, final double b)
> { return
>   a == 0.0 && b == 0.0 && java.lang.Double.doubleToRawLongBits( a )
>   == Double.doubleToRawLongBits( -0.0d )? b : a >= b ? a : b; }
>
>   which tries to return positive zero if one argument is
>   positive zero and the other one negative zero?

     The function could be simplified by eliminating the `a == 0.0'
comparison.  In fact, a further simplification is possible:

	public static double max(double a, double b) {
	    return Math.max(a, b);
	}

>   It seems that there are special cases when a comparison
>   of double values with »==« is appropriate. I have observed
>   that this is usually the case when comparing with »0.0« -
>   another example would be avoiding to divide by 0.0.

     The problem with comparing double or float values for equality
(or inequality) isn't the values themselves, but their "provenance."
Calculations that yield identical results when performed with real
numbers and their infinite precision may yield different outcomes
when finite-precision floating-point values are used instead.  We
know, for example, that `ln xy = ln x + ln y' for all positive x,y,
yet we cannot rely on `Math.log(x*y) == Math.log(x) + Math.log(y)'.
A rearrangement that appears innocuous can produce a result that is
slightly different (sometimes more than "slightly!") from that of
the original, and it's no simple matter to say which, if either,
is "right."

     Going more deeply than the "provenance" of a value we might want
to consider its "genesis:" Where did the original inputs to the
calculation come from?  Usually they represent measurements of some
kind: mass, speed, income, time spent writing Usenet posts, whatever.
Measurements are not infinitely precise; they are not even "finitely
precise" to the limits of our understanding -- how tall are you, in
Ångström units?  Different people making "the same" measurement will get
different answers, especially if they use different techniques or are
measuring attributes of different instances.  Start with these already-
approximate measures, run them through a chain of approximating
calculations, and it makes little sense to expect exact equality of
outcomes.  It may be worth knowing that the average height of forty-two
Swedish teenagers is greater than that of thirty-nine Ethiopians, but
it is silly to ask whether the difference is "exactly" one centimeter.

     Finally, as to avoiding division by zero: Yes, an exactly-zero
test can avoid it.  But that still isn't armor against a meaningless
result!  If you divide a very large number by a very small one, even
if the latter is not exactly zero, you may wind up with a result
that floating-point arithmetic will call "infinite."  In other words,
even a non-zero divisor can lead to the loss of *all* significant
digits in the supposed "answer."

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [next] | [standalone]

#35752

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 10/12/2016 8:15 AM, Stefan Ram wrote:
>>   Sometimes it is taught that it makes no sense to compare
>>   two double values with »==«.
>>   But what about this function?
>> public static double max( final double a, final double b)
>> { return
>>   a == 0.0 && b == 0.0 && java.lang.Double.doubleToRawLongBits( a )
>>   == Double.doubleToRawLongBits( -0.0d )? b : a >= b ? a : b; }
>>
>>   which tries to return positive zero if one argument is
>>   positive zero and the other one negative zero?

The situations, where you'd want max(+0,-0) = +0 and not -0 are
extremely limited, considering that +0 = -0, even for (Java) doubles.

>>   It seems that there are special cases when a comparison
>>   of double values with »==« is appropriate. I have observed
>>   that this is usually the case when comparing with »0.0« -
>>   another example would be avoiding to divide by 0.0.

In fact, one of the extremely rare applications of +0 and -0 is division
by them: 1/+0 = +Infinity , 1/-0 = -Infinity.

And, of course, "a == b iff a - b == 0.0" intuitively; allowing equality
on 0.0 opens it for all numbers.

Put in other words, using +0 and -0 as different turns doubles into
something they were not meant to be.

>
>     The problem with comparing double or float values for equality
> (or inequality) isn't the values themselves, but their "provenance."
> Calculations that yield identical results when performed with real
> numbers and their infinite precision may yield different outcomes
> when finite-precision floating-point values are used instead.  We
> know, for example, that `ln xy = ln x + ln y' for all positive x,y,
> yet we cannot rely on `Math.log(x*y) == Math.log(x) + Math.log(y)'.
> A rearrangement that appears innocuous can produce a result that is
> slightly different (sometimes more than "slightly!") from that of
> the original, and it's no simple matter to say which, if either,
> is "right."

Maybe it is easiest to see how fast you get there by evaluating the
following code:

public static void main(String[] args) {
  System.out.println(0.1 + 0.2 == 0.3);
  System.out.println(0.1 + 0.2 - 0.3 == 0);
}

[toc] | [prev] | [next] | [standalone]

#35763

Michael Jung <miju@golem.phantasia.org> writes:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> On 10/12/2016 8:15 AM, Stefan Ram wrote:
[...]
>>     The problem with comparing double or float values for equality
>> (or inequality) isn't the values themselves, but their "provenance."
>> Calculations that yield identical results when performed with real
>> numbers and their infinite precision may yield different outcomes
>> when finite-precision floating-point values are used instead.  We
>> know, for example, that `ln xy = ln x + ln y' for all positive x,y,
>> yet we cannot rely on `Math.log(x*y) == Math.log(x) + Math.log(y)'.
>> A rearrangement that appears innocuous can produce a result that is
>> slightly different (sometimes more than "slightly!") from that of the
>> original, and it's no simple matter to say which, if either, is
>> "right."
[...] 

More pointedly: don't use "==", when doing arithmetic. One of the
applications of using "==" on doubles may be when they are used as
version numbers such as modelling those of (La)TeX in Java.

(This "argument" does not apply to +0 and -0, though.)

Michael

[toc] | [prev] | [next] | [standalone]

#35764

On 10/15/2016 8:04 AM, Michael Jung wrote:
> Michael Jung <miju@golem.phantasia.org> writes:
>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>> On 10/12/2016 8:15 AM, Stefan Ram wrote:
> [...]
>>>     The problem with comparing double or float values for equality
>>> (or inequality) isn't the values themselves, but their "provenance."
>>> Calculations that yield identical results when performed with real
>>> numbers and their infinite precision may yield different outcomes
>>> when finite-precision floating-point values are used instead.  We
>>> know, for example, that `ln xy = ln x + ln y' for all positive x,y,
>>> yet we cannot rely on `Math.log(x*y) == Math.log(x) + Math.log(y)'.
>>> A rearrangement that appears innocuous can produce a result that is
>>> slightly different (sometimes more than "slightly!") from that of the
>>> original, and it's no simple matter to say which, if either, is
>>> "right."
> [...]
>
> More pointedly: don't use "==", when doing arithmetic. One of the
> applications of using "==" on doubles may be when they are used as
> version numbers such as modelling those of (La)TeX in Java.
>
> (This "argument" does not apply to +0 and -0, though.)

     The scare quotes around "argument" seem appropriate.  I attempted
to explain the basis of the simplistic "Don't use ==" advice, hoping
that an informed understanding would trump blind obedience to some
mysterious rule.  (Perhaps I was overly optimistic.)

     There are instances (admittedly not many) where floating-point ==
is reliable, appropriate, and "safe when used as directed."  It seems
to me that someone who can distinguish the safe from the unsafe cases
will be a better programmer than someone who closes his mind and simply
says "Never use ==, it's sometimes dangerous."

-- 
esosman@comcast-dot-net.invalid
"Everybody must get stoned."  Looks like the Swedish Academy was.

[toc] | [prev] | [next] | [standalone]

#35765

On 10/15/2016 9:13 AM, Eric Sosman wrote:
>     The scare quotes around "argument" seem appropriate.  I attempted
> to explain the basis of the simplistic "Don't use ==" advice, hoping
> that an informed understanding would trump blind obedience to some
> mysterious rule.  (Perhaps I was overly optimistic.)
>
>     There are instances (admittedly not many) where floating-point ==
> is reliable, appropriate, and "safe when used as directed."  It seems
> to me that someone who can distinguish the safe from the unsafe cases
> will be a better programmer than someone who closes his mind and simply
> says "Never use ==, it's sometimes dangerous."

But I would say that someone that even though a particular use of
double == is safe still consider alternatives that are less fragile
to break with future code modifications is a better software engineer
than those who reason that since they can see it is safe then all
future maintainers of the code will understand the issue and keep
it safe.

Arne

[toc] | [prev] | [next] | [standalone]

#35767

On 10/15/2016 10:32 AM, Arne Vajhøj wrote:
> On 10/15/2016 9:13 AM, Eric Sosman wrote:
>>     The scare quotes around "argument" seem appropriate.  I attempted
>> to explain the basis of the simplistic "Don't use ==" advice, hoping
>> that an informed understanding would trump blind obedience to some
>> mysterious rule.  (Perhaps I was overly optimistic.)
>>
>>     There are instances (admittedly not many) where floating-point ==
>> is reliable, appropriate, and "safe when used as directed."  It seems
>> to me that someone who can distinguish the safe from the unsafe cases
>> will be a better programmer than someone who closes his mind and simply
>> says "Never use ==, it's sometimes dangerous."
>
> But I would say that someone that even though a particular use of
> double == is safe still consider alternatives that are less fragile
> to break with future code modifications is a better software engineer
> than those who reason that since they can see it is safe then all
> future maintainers of the code will understand the issue and keep
> it safe.

     Allow me to pose a related question: Do you ever use > with
floating-point values?  And do you ever use >= similarly?  Now:
How do you choose between > and >=, and why?

     I contend that someone who blindly obeys "Never use ==" will
have no (rational) way to decide whether to use > as opposed to >=,
since the only difference between them is the equality comparison
he's pledged to avoid.

     That is, I contend there's no substitute for understanding.
My own understanding is imperfect -- the field called Numerical
Analysis is large, intricate, and subtle -- but nonetheless I feel
that dicta like "Never" are, er, "Always" out of place.  (Almost.)

-- 
esosman@comcast-dot-net.invalid
"Everybody must get stoned."  Looks like the Swedish Academy was.

[toc] | [prev] | [next] | [standalone]

#35768

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 10/15/2016 10:32 AM, Arne Vajhøj wrote:
>> On 10/15/2016 9:13 AM, Eric Sosman wrote:
>>>     The scare quotes around "argument" seem appropriate.  I attempted
>>> to explain the basis of the simplistic "Don't use ==" advice, hoping
>>> that an informed understanding would trump blind obedience to some
>>> mysterious rule.  (Perhaps I was overly optimistic.)

Those weren't scare quotes. Your explanation I also assume sufficient. I
was trying to find a rule-of-thumb that was "better" than the simple
"never use" clause but not too clumsy. It wasn't an argument at
all. Neither as argument nor as rule does this (unquoted) elaboration
apply to +0 and -0. I don't think Stefan fell for the usefulness of ==
with doubles but more possibly for the usefulness of +0 and -0. Anyway,
there's a scare quote up there now. :-)

[...]
>     Allow me to pose a related question: Do you ever use > with
> floating-point values?  And do you ever use >= similarly?  Now:
> How do you choose between > and >=, and why?
>     I contend that someone who blindly obeys "Never use ==" will
> have no (rational) way to decide whether to use > as opposed to >=,
> since the only difference between them is the equality comparison
> he's pledged to avoid.

">" = !"<=" and "<" = !">=". It turns out to be a matter of taste or
clarity in a situation, which to use. Equality doesn't really come into
it. I think, going for a rule-of-thumb on "==" is aiming too short. The
better rule-of-thumb is "to shy away from 0 with doubles and
calculations".

>     That is, I contend there's no substitute for understanding.
> My own understanding is imperfect -- the field called Numerical
> Analysis is large, intricate, and subtle -- but nonetheless I feel
> that dicta like "Never" are, er, "Always" out of place.  (Almost.)

Of course. An example for using "==" on zero with doubles _and
calculations_ (foiling my own "dicta") is

double a = 1;
int b = 1;
while (!(a == 0)) {
  b++;
  a = a/2;
}
System.out.println("b=" + b);

With a large enough numeric hammer you can possibly forge a useful
example out of it.

Michael

[toc] | [prev] | [next] | [standalone]

#35769

On 15/10/2016 15:46, Eric Sosman wrote:

[...]
>     That is, I contend there's no substitute for understanding.
> My own understanding is imperfect -- the field called Numerical
> Analysis is large, intricate, and subtle -- but nonetheless I feel
> that dicta like "Never" are, er, "Always" out of place.  (Almost.)

My opinion is that suggesting that == should *never* be used to test 
equality for doubles is totally sensible. I only object to "it doesn't 
make sense", from a formal point of view. If you choose - as the golden 
rule prescribes - a small enough delta, you can still test equality 
between two identical values. If a developer understands how fp numbers 
are represented internally (e.g IEEE 754), they also understand why two 
different representations of the same number are going to fail the 
comparison, while using == for two identical representations (e.g. two 
literals) makes perfect sense.

The problem, in some cases, is how to choose that delta. I was 
developing a 3D geometry library in C++ a while ago. The problem I had 
was testing the library. I had to test for equality with 0.0 when 
checking whether a point belonged to a plane or a rect was the result of 
the intersection between two planes. Determining the delta to use turned 
out to be extremely difficult, if not impossible. I ended up tranforming 
my classes into templates with a generic type for the coordinate, and 
write tests using integers instead of doubles. I'd be curious to know if 
there can be a better solution.

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35770

On 10/15/2016 12:36 PM, 4ndre4 wrote:
> [...] I was
> developing a 3D geometry library in C++ a while ago. The problem I had
> was testing the library. I had to test for equality with 0.0 when
> checking whether a point belonged to a plane or a rect was the result of
> the intersection between two planes. Determining the delta to use turned
> out to be extremely difficult, if not impossible. I ended up tranforming
> my classes into templates with a generic type for the coordinate, and
> write tests using integers instead of doubles. I'd be curious to know if
> there can be a better solution.

<topicality level="marginal">

     Although it covers only the two-dimensional case, this paper

http://www.cpsc.ucalgary.ca/~marina/papers/Segment_intersection.ps

describes some techniques you might find (or might have found) useful.
In particular, it offers a method of determining *exactly* whether a
sum of floating-point values would be negative, zero, or positive if
it were carried out in perfect precision.

</topicality>

-- 
esosman@comcast-dot-net.invalid
"Everybody must get stoned."  Looks like the Swedish Academy was.

[toc] | [prev] | [next] | [standalone]

#35771

On 15/10/2016 19:15, Eric Sosman wrote:

[...]
>     Although it covers only the two-dimensional case, this paper

Thanks a lot!

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35776

On 10/15/2016 10:46 AM, Eric Sosman wrote:
> On 10/15/2016 10:32 AM, Arne Vajhøj wrote:
>> On 10/15/2016 9:13 AM, Eric Sosman wrote:
>>>     The scare quotes around "argument" seem appropriate.  I attempted
>>> to explain the basis of the simplistic "Don't use ==" advice, hoping
>>> that an informed understanding would trump blind obedience to some
>>> mysterious rule.  (Perhaps I was overly optimistic.)
>>>
>>>     There are instances (admittedly not many) where floating-point ==
>>> is reliable, appropriate, and "safe when used as directed."  It seems
>>> to me that someone who can distinguish the safe from the unsafe cases
>>> will be a better programmer than someone who closes his mind and simply
>>> says "Never use ==, it's sometimes dangerous."
>>
>> But I would say that someone that even though a particular use of
>> double == is safe still consider alternatives that are less fragile
>> to break with future code modifications is a better software engineer
>> than those who reason that since they can see it is safe then all
>> future maintainers of the code will understand the issue and keep
>> it safe.
>
>     Allow me to pose a related question: Do you ever use > with
> floating-point values?  And do you ever use >= similarly?  Now:
> How do you choose between > and >=, and why?
>
>     I contend that someone who blindly obeys "Never use ==" will
> have no (rational) way to decide whether to use > as opposed to >=,
> since the only difference between them is the equality comparison
> he's pledged to avoid.

But there is one big difference between the problems.

== will frequently lead to problems.

 > or >= will in most proper cases be equally good for the same
reason that cause the problem with ==.

>     That is, I contend there's no substitute for understanding.
> My own understanding is imperfect -- the field called Numerical
> Analysis is large, intricate, and subtle -- but nonetheless I feel
> that dicta like "Never" are, er, "Always" out of place.  (Almost.)

I disagree.

The purpose of writing code is not to produce something aesthetically
beautiful.

The purpose of writing code is to solve some problem in an efficient
way. Usually efficient means fast initial development in easy
maintenance. There are cases where run time efficiency comes
into play, but that is sort of orthogonal to the topic being
discussed.

Doing extensive numerical analysis to determine if the usage of
== is correct and put in the necessary documentation/training
to ensure that the future maintenance programmers do not
mess it up will rarely be efficient.

Follow the rule of thumb and find an workaround that do not
require the == will usually be more efficient.

Arne

[toc] | [prev] | [next] | [standalone]

#35766

On 10/15/2016 8:04 AM, Michael Jung wrote:
> More pointedly: don't use "==", when doing arithmetic. One of the
> applications of using "==" on doubles may be when they are used as
> version numbers such as modelling those of (La)TeX in Java.

I don't think that double nor String are good choices for version
numbers.

Version numbers has a large number of funky variations and
rules.

Arne

[toc] | [prev] | [next] | [standalone]

#35773

On 15/10/2016 15:41, Arne Vajhøj wrote:

[...]
> I don't think that double nor String are good choices for version
> numbers.

Why not String? Maven's versions are strings, for example.

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35774

On 10/15/2016 6:09 PM, 4ndre4 wrote:
> On 15/10/2016 15:41, Arne Vajhøj wrote:
>
> [...]
>> I don't think that double nor String are good choices for version
>> numbers.
>
> Why not String? Maven's versions are strings, for example.

     One problem is that String comparison is character-by-character,
meaning that version "1.10" compares *less* than "1.9".

     (Anecdote: Long ago at Sun Microsystems, I worked with a partner
whose software ran into exactly this problem.  The installation script
carefully checked that the O/S was a supported version, which in their
case was "Solaris 5.7 or later."  All went well until Solaris 5.9 was
upgraded to Solaris 5.10, and the partner's stuff refused to install.
Using double would not have helped, either: Their whole scheme of
version-checking was flawed.)

     (Side observation: I believe the version numbers Michael Jung
mentioned are rather different.  As a mathematician, Knuth chose to
assign version numbers that aren't in an incrementing sequence, but
are "better and better approximations" to the bug-free ideal.  So,
for example, he'd begin with versions 3, then 3.1, then 3.14, then
3.142, then 3.1416, ...)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#35777

On 15/10/2016 23:28, Eric Sosman wrote:

[...]
>     One problem is that String comparison is character-by-character,
> meaning that version "1.10" compares *less* than "1.9".

That's true, but I was assuming that any comparison on versions would 
not just be a mere string comparison, but take into account the specific 
structure of the version number. For example, for a typical major.minor 
version, I assume that the checker would split the two parts of the 
version and compare them separately.

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35781

On 10/15/2016 10:13 PM, 4ndre4 wrote:
> On 15/10/2016 23:28, Eric Sosman wrote:
>
> [...]
>>     One problem is that String comparison is character-by-character,
>> meaning that version "1.10" compares *less* than "1.9".
>
> That's true, but I was assuming that any comparison on versions would
> not just be a mere string comparison, but take into account the specific
> structure of the version number. For example, for a typical major.minor
> version, I assume that the checker would split the two parts of the
> version and compare them separately.

     ... and *still* get the wrong answer!

	String major = "1";
	String minor = "10";
	// OK if version is 1.9 or later:
	boolean okay = major.compareTo("1") > 0
	    || (major.compareTo("1") == 0 && minor.compareTo("9") >= 0);
	// Oops ...

That is, plain String comparison is inadequate for checking complete
version numbers, and also inadequate for checking the individual
components of version tuples.  As Arne suggests, something more
sensitive to the structure and significance of the tuples is needed.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#35782

On 16/10/2016 13:37, Eric Sosman wrote:

[...]
>     ... and *still* get the wrong answer!

You did not get my point.

Those subparts have to be converted to *integers* and compared as such, 
not compared as string. If I know the semantics of a version number, I 
know how to compare it to another version number. No matter how silly 
your version format is: if I know that a '@' means newer and '#' means 
older, than I'll have a version comparator that takes that into account.

 > That is, plain String comparison is inadequate for checking complete
 > version numbers

See above: plain string comparison is *not* what I am talking about.

Again: saying that strings are not a good idea to store dates or 
versions, just because you cannot compare dates or versions as strings 
is a flawed argument. If you expect a date in the form dd/mm/yyyy you 
need a specific comparator. If you expect a version in the form 
major.minor.update-build, you need a specific comparator.

Let me remind you that the original argument was: "I don't think that 
double nor String are good choices for version numbers"

That's illogical. Strings are a good choice for version numbers as well 
as they are for dates.

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35775

On 10/15/2016 6:09 PM, 4ndre4 wrote:
> On 15/10/2016 15:41, Arne Vajhøj wrote:
> [...]
>> I don't think that double nor String are good choices for version
>> numbers.
>
> Why not String? Maven's versions are strings, for example.

= is fine for String. But < <= > >= can be problematic:

"1.10" < "1.9"

"1.0" < "1.0 beta"

"1.1.1" < 1.1pl1"

Arne

[toc] | [prev] | [next] | [standalone]

#35778

On 16/10/2016 01:30, Arne Vajhøj wrote:

[...]
> = is fine for String. But < <= > >= can be problematic:

I know well, but - as said in my previous post - I am assuming that the 
comparator would parse the version and carry out a correct comparison on 
its single parts. Similarly to having a sstring representing a date. 
It's not that strings are problematic to represent strings; you have to 
parse those strings correctly.

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

#35779

On 16/10/2016 03:16, 4ndre4 wrote:

[...]
Okay, let me rephrase, cause 3am is not a good time to write posts :)

"It's not that strings are problematic to represent dates; you have to 
parse those strings correctly."

-- 
4ndre4

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web