## D - reasoning for operator!=

• Immanuel Scholz (13/13) Mar 05 2002 Hi,
• Pavel Minayev (6/13) Mar 05 2002 think...
• Immanuel Scholz (23/40) Mar 05 2002 Hm, maybe in C, but not in math! NAN is in math really "not a number"
• Pavel Minayev (13/33) Mar 05 2002 Agreed. However, computers sometimes think stupidly from our
• Immanuel Scholz (13/29) Mar 05 2002 But now, you have to check too. Plus the fact, that when you forget to
• Pavel Minayev (9/18) Mar 05 2002 You have to check only when you really care when it happens.
• Immanuel Scholz (22/31) Mar 05 2002 I think it is much the same like exceptions versus return values&errno. ...
• Pavel Minayev (9/16) Mar 05 2002 The problem is, comparison ops happen MUCH frequently than new ops.
• Christophe Bouchon (29/42) Mar 05 2002 An extract from the D manual (look at the Note at the bottom):
• Walter (8/17) Mar 06 2002 I've sent google email about that, but so far no reply.
"Immanuel Scholz" <digital-mars kutzsche.net> writes:
```Hi,

I am new to the list, maybe this was answered before.. (sorry, but google
seems not to index digitalmars-newsserver?)

Why this:

double a = double.nan;
double b = 1.0;

if (a == b)
assert (a != b);    // assertion failed.. very strange thing, I think...

Maybe to throw some kind of arethmetic_exception in case of comparing
nan-doubles instead of this very strange double-!= behaviour?

Imi

PS: I am using Outlook as newsreader the first time, I hope I got the
settings correct and nothing is messed up... ?!
```
Mar 05 2002
"Pavel Minayev" <evilone omen.ru> writes:
```"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62lfc\$2top\$1 digitaldaemon.com...

Why this:

double a = double.nan;
double b = 1.0;

if (a == b)
assert (a != b);    // assertion failed.. very strange thing, I

think...
Maybe to throw some kind of arethmetic_exception in case of comparing
nan-doubles instead of this very strange double-!= behaviour?

I thought that if one of the operands is NAN, both == and != would
give false - which is the usual behaviour for floating-point
comparisons, AFAIK.
```
Mar 05 2002
"Immanuel Scholz" <digital-mars kutzsche.net> writes:
```"Pavel Minayev" <evilone omen.ru> schrieb im Newsbeitrag
news:a62rb8\$30eg\$1 digitaldaemon.com...
"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62lfc\$2top\$1 digitaldaemon.com...

Why this:

double a = double.nan;
double b = 1.0;

if (a == b)
assert (a != b);    // assertion failed.. very strange thing, I

think...
Maybe to throw some kind of arethmetic_exception in case of comparing
nan-doubles instead of this very strange double-!= behaviour?

I thought that if one of the operands is NAN, both == and != would
give false - which is the usual behaviour for floating-point
comparisons, AFAIK.

Hm, maybe in C, but not in math! NAN is in math really "not a number"
and you can't comparing it, because it is, err, not a number!
So I think it should not try to compare, but throw an exception.

I always thought these two parts are semantical equal:

if (a == b)
foo ();
else
bar ();

if (a != b)
bar ();
else
foo ();

I know, in times when you can override operator!= in c++ this is not
guaranteed anymore,
but I think forbidding to override != is good, and make it the opposite of
== essential.

double a = double.nan;
a += 2;

So why to allow comparing and not adding (or why not forbid comparing?)

Imi
```
Mar 05 2002
"Pavel Minayev" <evilone omen.ru> writes:
```"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62tui\$3m\$1 digitaldaemon.com...

Hm, maybe in C, but not in math! NAN is in math really "not a number"
and you can't comparing it, because it is, err, not a number!

Agreed. However, computers sometimes think stupidly from our
point of view. This is probably such a case =)

So I think it should not try to compare, but throw an exception.

This would require an additional check to be inserted before
each fp-comparison - a bit too much overhead, isn't it?

Unfortunately, Intel FPUs don't have the built-in ability to
throw D exceptions when some NAN error occurs =)

I always thought these two parts are semantical equal:

if (a == b)
foo ();
else
bar ();

if (a != b)
bar ();
else
foo ();

Not for floating-point numbers.

I know, in times when you can override operator!= in c++ this is not
guaranteed anymore,
but I think forbidding to override != is good, and make it the opposite of
== essential.

Operators == and != aren't neccessary boolean (remember fuzzy logic!).
So I don't think it's the best idea. It's better to leave this up
to the programmer.

double a = double.nan;
a += 2;

So why to allow comparing and not adding (or why not forbid comparing?)

Adding is allowed as well. It will just give you a NAN.
```
Mar 05 2002
"Immanuel Scholz" <digital-mars kutzsche.net> writes:
```"Pavel Minayev" <evilone omen.ru> schrieb im Newsbeitrag
news:a62ujl\$bj\$1 digitaldaemon.com...
"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62tui\$3m\$1 digitaldaemon.com...

So I think it should not try to compare, but throw an exception.

This would require an additional check to be inserted before
each fp-comparison - a bit too much overhead, isn't it?

But now, you have to check too. Plus the fact, that when you forget to
check,
very strange results are happen...

Unfortunately, Intel FPUs don't have the built-in ability to
throw D exceptions when some NAN error occurs =)

Ok, this one counts. :)
(BTW: Shouldn't it be easier to implement that double.nan == double.nan is
true? Why it is false here?)

I know, in times when you can override operator!= in c++ this is not
guaranteed anymore,
but I think forbidding to override != is good, and make it the opposite

of
== essential.

Operators == and != aren't neccessary boolean (remember fuzzy logic!).
So I don't think it's the best idea. It's better to leave this up
to the programmer.

Hm.. okok, maybe I start to write !(a == b) instead of a != b.
But only if you promise not to define "!a" to "1-a"   ;-)

So why to allow comparing and not adding (or why not forbid comparing?)

Adding is allowed as well. It will just give you a NAN.

Uh, so I can really calculate the magic odd of  1 to 2^(INF-1)  ?

Imi.
```
Mar 05 2002
"Pavel Minayev" <evilone omen.ru> writes:
```"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62v60\$sh\$1 digitaldaemon.com...

But now, you have to check too. Plus the fact, that when you forget to
check,
very strange results are happen...

You have to check only when you really care when it happens.
After all, if the float is read from the file or keyboard,
you can always check it once at the point where it is read -
and act accordingly. Why do a check each time comparison happens?

Ok, this one counts. :)
(BTW: Shouldn't it be easier to implement that double.nan == double.nan is
true? Why it is false here?)

Hm.. okok, maybe I start to write !(a == b) instead of a != b.
But only if you promise not to define "!a" to "1-a"   ;-)

Well... a == b could return "almost equal", so !(a == b) would be
"a bit not equal" =)

Uh, so I can really calculate the magic odd of  1 to 2^(INF-1)  ?

You could give it a try =)
```
Mar 05 2002
"Immanuel Scholz" <digital-mars kutzsche.net> writes:
```"Pavel Minayev" <evilone omen.ru> schrieb im Newsbeitrag
news:a634dj\$3ol\$1 digitaldaemon.com...
"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62v60\$sh\$1 digitaldaemon.com...

But now, you have to check too. Plus the fact, that when you forget to
check,
very strange results are happen...

You have to check only when you really care when it happens.
After all, if the float is read from the file or keyboard,
you can always check it once at the point where it is read -
and act accordingly. Why do a check each time comparison happens?

I think it is much the same like exceptions versus return values&errno. I
think returning false, when comparing an invalid number is like returning
null
(an invalid pointer) within the new-operator.

I assume, that NAN==1 -> false  is never what you really want. You really
do not want to compare NANs at all!

// here, a could be NAN. so lets check it (only once)

if (a == 1) ...  // of course, you have not to check to NAN again
if (a == 5) ...  // but you also do not have to check again, if
if (a == b) ...  // (double.nan == 1) throws an exception.

the same applies to adding/subtracting to a NAN or as example dividing by 0
with integers. (Although I think the result "NAN" is ok for a division by 0
in the
floating-point-world ;-)

Just keep in mind that if you deceide to let NAN == NAN -> false, that is
only
a performance issue, and NOT a good decision. :-)

Imi.
```
Mar 05 2002
"Pavel Minayev" <evilone omen.ru> writes:
```"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a63560\$41e\$1 digitaldaemon.com...

I think it is much the same like exceptions versus return values&errno. I
think returning false, when comparing an invalid number is like returning
null
(an invalid pointer) within the new-operator.

The problem is, comparison ops happen MUCH frequently than new ops.
So the overhead is just too much.

Just keep in mind that if you deceide to let NAN == NAN -> false, that is
only
a performance issue, and NOT a good decision. :-)

Sometimes perfomance issue IS a good decision. It depends on the POV.
For example, a game programmer might consider exception-on-NAN
to be the most stupid things he'd ever heard of - simply 'cause he'll
get 20fps on a PIV, because 100000 vertices have their coordinates
checked every frame =)
```
Mar 05 2002
"Christophe Bouchon" <cbouchon hotmail.com> writes:
```An extract from the D manual (look at the Note at the bottom):

Floating point comparisons
If one or both operands are floating point, then a floating point comparison
is performed.

Useful floating point operations must take into account NAN values. In
particular, a relational operator can have NAN operands. The result of a
relational operation on float values is less, greater, equal, or unordered
(unordered means either or both of the operands is a NAN). That means there
are 14 possible comparison conditions to test for:

Token		Relation
<		less
>		greater
<=		less or equal
>=		greater or equal
==		equal
!=		unordered, less, or greater
!<>=		unordered
<>		less or greater
<>=		less, equal, or greater
!<=		unordered or greater
!<		unordered, greater, or equal
!>=		unordered or less
!>		unordered, less, or equal
!<>		unordered or equal

Note: for floating point comparison operators, (a !op b) is not the same as
!(a op b).

"Immanuel Scholz" <digital-mars kutzsche.net> wrote in news message:
a62lfc\$2top\$1 digitaldaemon.com...
Hi,

I am new to the list, maybe this was answered before.. (sorry, but google
seems not to index digitalmars-newsserver?)

Why this:

double a = double.nan;
double b = 1.0;

if (a == b)
assert (a != b);    // assertion failed.. very strange thing, I

think...
Maybe to throw some kind of arethmetic_exception in case of comparing
nan-doubles instead of this very strange double-!= behaviour?

Imi

PS: I am using Outlook as newsreader the first time, I hope I got the
settings correct and nothing is messed up... ?!

```
Mar 05 2002
"Roberto Mariottini" <rmariottini lycosmail.com> writes:
```"Christophe Bouchon" <cbouchon hotmail.com> wrote in message
news:a63dil\$7il\$1 digitaldaemon.com...
[...]
Token Relation
< less
greater

<= less or equal
= greater or equal

== equal
!= unordered, less, or greater
!<>= unordered
<> less or greater
<>= less, equal, or greater
!<= unordered or greater
!< unordered, greater, or equal
!>= unordered or less
!> unordered, less, or equal
!<> unordered or equal

Note: for floating point comparison operators, (a !op b) is not the same

as
!(a op b).

I think I've never understood how I can use these operators.
Can you show some examples?

Ciao
```
Mar 06 2002
"Walter" <walter digitalmars.com> writes:
```"Immanuel Scholz" <digital-mars kutzsche.net> wrote in message
news:a62lfc\$2top\$1 digitaldaemon.com...
I am new to the list, maybe this was answered before.. (sorry, but google
seems not to index digitalmars-newsserver?)

Why this:
double a = double.nan;
double b = 1.0;
if (a == b)
assert (a != b);    // assertion failed.. very strange thing, I

think...
Maybe to throw some kind of arethmetic_exception in case of comparing
nan-doubles instead of this very strange double-!= behaviour?

It does it that way because that's the way IEEE 754 specifies the behavior
of floating point ops. This has been adopted by C99. Changing it in D would
subtly and very obscurely break code. Some things it's just too hard to swim
upstream against <g>.
```
Mar 06 2002