Lots of bool operations shouldn't compile

Thomas Kuehne thomas-dloop at kuehne.cn
Fri Mar 3 09:33:32 PST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Furlong schrieb am 2006-03-03:
> Don Clugston wrote:
>> Kyle Furlong wrote:
>>> Don Clugston wrote:
>>>> Thomas Kuehne wrote:
>>>>> Don Clugston schrieb am 2006-02-28:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> OK, there's another bug in there, comparing an int with an 
>>>>>> imaginary real should also not be legal.
>>>>>>
>>>>>>      if (1 > -2i) { assert(0); }
>>>>>>      if (1 > ireal.nan) { assert(0); }
>>>>>>
>>>>>> Reals and ireals cannot be compared. Ever.
>>>>>
>>>>> Sure you can. Floats and imaginary floats can both be implicitly 
>>>>> promoted to complex floats.
>>>>
>>>> That only gives you == and !=.
>>>>
>>>> <snip>
>>>>> Thus
>>>>>
>>>>>>      if (1 > -2i) { assert(0); }
>>>>>>      if (1 > ireal.nan) { assert(0); }
>>>>>
>>>>> are interpreted as
>>>>>
>>>>>>      if (1 + 0i > 0 - 2i) { ... }
>>>>>>      if (1 + 0i > 0 + ireal.nan) { ... }
>>>>
>>>> Yes, but that still doesn't work, there's no > for complex numbers.
>>>> Is  2 - 3i > 3 - 2i ?
>>>
>>> One could speak of their magnitudes, I suppose.
>>>
>>> creal i = 2 - 3i;
>>> creal j = 3 - 2i;
>>>
>>> real i_m = sqrt(i * complexConjugate(i));
>>> real j_m = sqrt(j * complexConjugate(j));
>>>
>>> but then I guess you are just comparing reals.
>> 
>> And then you have the problem (as in this case) that
>> (i >= j) is true, and (i <= j) is true, but (i==j) is false.
>> 
>> Actually, though, you _could_ bring the NCEG operators into play, and
>> define
>> a >  b  as   abs(a) > abs(b)
>> a >= b  as   abs(a) > abs(b) || a==b
>> a !< b  as   abs(a) !< abs(b)
>> a !<=b  as   abs(a) !< abs(b) && a!=b
>> a <> b  as   abs(a) != abs(b)
>> a !<>b  as   abs(a) == abs(b)
>> a == b  as   a == b
>> a <>=b  as   abs(a) <> abs(b) || a==b
>> a!<>=b  as   abs(a) == abs(b) && a!=b
>> 
>> which would even work correctly with NANs.
>> But there's no mathematical precedent for this, AFAIK.
>
> As long as its well documented and doesn't introduce bugs, why not?

http://www.digitalmars.com/d/float.html
# Floating Point Comparisons
#
# In addition to the usual < <= > >= == != comparison operators, D adds
# more that are specific to floating point. These are !<>= <> <>= !<= !<
# !>= !> !<> and match the semantics for the NCEG extensions to C.

creal/cdouble/cfloat are "Floating Point Types" and
"Floating Point Comparisons" are those stated by NCEG.

So what does NCEG say on compairing _Complex?
(Couldn't find any useful NCEG documents ...)

Thomas




-----BEGIN PGP SIGNATURE-----

iD8DBQFECHri3w+/yD4P9tIRApwuAJ46SuFsHnytm8aVfp4/w9fnt7Le4gCfSb6F
Zu/XOm3qGyAJ14TyVUKQBv4=
=WDhO
-----END PGP SIGNATURE-----



More information about the Digitalmars-d-bugs mailing list