March 02, 2006 Re: Lots of bool operations shouldn't compile | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Furlong | Kyle Furlong wrote:
> Don Clugston wrote:
>> Thomas Kuehne wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> 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.
|
March 03, 2006 Re: Lots of bool operations shouldn't compile | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don Clugston wrote:
> Kyle Furlong wrote:
>> Don Clugston wrote:
>>> Thomas Kuehne wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> 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?
|
March 03, 2006 Re: Lots of bool operations shouldn't compile | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Furlong | >>>> 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?
I really don't think it's a good idea (mathematicians would laugh at us). If you want to compare the magnitudes, you should say so. But, I find it interesting that the NCEG operators allow you to define meaningful ordering comparisons for quantities for which a strict weak ordering does not exist.
|
March 03, 2006 Re: Lots of bool operations shouldn't compile | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Furlong Attachments: | 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 |
Copyright © 1999-2021 by the D Language Foundation