MATLAB Central Newsreader - i <= 0 ??

i <= 0 ??

Muhammad — Fri, 30 Oct 2009 20:55:18 -0400

Complex number are ordered in matlab. For the imaginary unit, i, for example, I get
? disp(i < 0 | i == 0)
ans =
0
This may be consistent behavior. But it is certainly inconsistent with the following result:
? disp (i <= 0)
ans =
1

Re: i <

Nathan — Fri, 30 Oct 2009 21:05:44 -0400

On Oct 30, 1:55 pm, "Muhammad " <muh...@shaw.ca> wrote:
> Complex number are ordered in matlab. For the imaginary unit, i, for example, I get
> ? disp(i < 0 | i == 0)
> ans =
> 0
> This may be consistent behavior. But it is certainly inconsistent with the following result:
> ? disp (i <= 0)
> ans =
> 1

That's interesting:
>> disp(i>0)
     0
>> disp(i>=0)
     1
>> disp(i==0)
     0
>> disp(i<=0)
     1
>> disp(i<0)
     0

But then again, why would you compare i to zero anyways?

-Nathan

Re: i <= 0 ??

Bruno Luong — Fri, 30 Oct 2009 21:15:20 -0400

From the doc:

[... The operators <, >, <=, and >= use only the real part of their operands for the comparison. The operators == and ~= test real and imaginary parts. ..]

And to confuse even more, SORT uses another relation ordering (I believe the *magnitude* is compared)

>> sort([1+1i 2i])

ans =

1.0000 + 1.0000i 0 + 2.0000i

>> 1+1i<=2i

ans =

0

% Bruno

Re: i <= 0 ??

Bruno Luong — Fri, 30 Oct 2009 21:22:01 -0400

And you have not finish with another astonishing rule:

>> sort([0 1 -2])

ans =

-2 0 1

>> sort([1i 1 -2])

ans =

1.0000 0 + 1.0000i -2.0000 % 1 <= -2 !!!

% Bruno

Re: i <= 0 ??

Nasser M. Abbasi — Fri, 30 Oct 2009 21:38:30 -0400

"Muhammad " <muhali@shaw.ca> wrote in message
news:hcfjrm$jcs$1@fred.mathworks.com...
> Complex number are ordered in matlab. For the imaginary unit, i, for
> example, I get
> ? disp(i < 0 | i == 0)
> ans =
> 0
> This may be consistent behavior. But it is certainly inconsistent with the
> following result:
> ? disp (i <= 0)
> ans =
> 1

Ordering where complex numbers are involved should be based on the real
parts. If 2 complex numbers have the same real part, then the imaginary part
(its absolute value) should break the tie.

In the first example, i<0 , here since real part of i which is 0 is NOT
less than zero then i<0 is false. For i==0, since the real parts are equal
(both are zero) then we look at the imaginary part to break the tie. Since
the abs value of the imaginary part of i (which is 1) is clearly not equal
to the imaginary part of zero, which is zero, then we get False again.
Hence the result false Or False is False as shown.

For the case of i<=0, the real part of i is zero, and the real part of 0 is
zero, so it is a tie, looking at the imaginary parts, the absolute value of
the imaginary part of i is 1, and the for 0 it is zero, hence 1<=0 should be
False.

Hence Matlab answer for i<=0 should be 0 not 1. This is a bug. Or Matlab
uses some other logic to decide on these issues.

--Nasser

Re: i <= 0 ??

James Tursa — Fri, 30 Oct 2009 22:20:19 -0400

"Nasser M. Abbasi" <nma@12000.org> wrote in message <s1JGm.37806$Tx1.13127@newsfe15.iad>...
>
> Hence Matlab answer for i<=0 should be 0 not 1. This is a bug.

No.

> Or Matlab uses some other logic to decide on these issues.

Yes, they use the rules they list in the doc for these operators. See Bruno's earlier post for the rules in the doc:

[... The operators <, >, <=, and >= use only the real part of their operands for the comparison. The operators == and ~= test real and imaginary parts. ..]

I don't see any discrepancy between this example and their documented rules. Now if you don't like their documented rules, that is another matter ...

James Tursa

Re: i <= 0 ??

Matt — Sun, 08 Nov 2009 16:17:01 -0500

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hcfldp$pr1$1@fred.mathworks.com>...
> And you have not finish with another astonishing rule:
>
> >> sort([0 1 -2])
>
> ans =
>
> -2 0 1
>
> >> sort([1i 1 -2])
>
> ans =
>
> 1.0000 0 + 1.0000i -2.0000 % 1 <= -2 !!!

Hazardous indeed. A likely pitfall is, for example, if you want to sort the result of an ifft() output. Often you expect the output to be real-valued, and would expect the sorting to be done according to the real-part only, but forget that the output will have a residual complex part due to numerical round-off.

I guess it's worth cooking up a realsort() function and getting into the habit of using that...