octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No isimag() curioso


From: Daniel J Sebald
Subject: Re: No isimag() curioso
Date: Sat, 08 Sep 2012 16:33:23 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 09/07/2012 11:05 PM, Michael D Godfrey wrote:
On 09/07/2012 05:30 PM, Daniel J Sebald wrote:
In working with the fftfilt() routine and wanting to know if the
inputs were purely imaginary I wondered why there is no such thing as
isimag(). It seems as though it would be as useful as or more useful
than iscomplex().

Here's the thing: iscomplex() appears to be simply the complement of
isreal(), unless I'm missing a more sophisticated use of syntax:

octave:5> x = 1
x = 1
octave:6> [isreal(x) iscomplex(x)]
ans =

1 0

octave:7> x = i
x = 0 + 1i
octave:8> [isreal(x) iscomplex(x)]
ans =

0 1

octave:9> x = 1+i
x = 1 + 1i
octave:10> [isreal(x) iscomplex(x)]
ans =

0 1

octave:11>

I ask, What's the point of having a function that is simply !isreal()?
On the other hand isimag(), which is equivalent to "all (real (x) ==
0)) && !isreal (x)", would be a nice shorthand.

Just an observation. Usually duplication of function (or its
complement) is weeded out of programming languages.

Dan
I also recently noticed some quirks with complex:
x = 1 + 0i is treated as real and not complex.
but
x = 0 + 1i is treated as imag and complex.

Talking of Octave, there is no "isimag()", so what do you mean "treated as imag"?


But, this is consistent with Matlab. However, Matlab has no iscomplex
and also
differs in its example for help isreal. There, Matlab gives an example:
x = magic(3);
y = complex(x);

which gives:
> y

y =

8 1 6
3 5 7
4 9 2
> isreal(y)

ans =

0
but, ~isreal(y) gives:
ans =

1

The text in the help messages says that
isreal(y) returns
false, because COMPLEX returns y with an all zero imaginary
part.
-------------------------------------------
but Octave gives:

y =

8 + 0i 1 + 0i 6 + 0i
3 + 0i 5 + 0i 7 + 0i
4 + 0i 9 + 0i 2 + 0i

and:
octave:21> isreal(y)
ans = 0
and:
octave:29> ~isreal(y)
ans = 1

The only difference is in the display of y.

Well, if y is complex, I sort of prefer the Octave printout format.


This hardly qualifies as a bug, but does add a bit
to the confusion.

Add to, yes. Meaning it is already somewhat confusing by the Matlab standard.


 Some people would imagine
that real and imaginary would be treated "symmetrically."

I guess that is what I would prefer.  For example

PREFERRED, NOT CURRENT BEHAVIOR:

octave:29> x = 1
x =  1
octave:30> isreal(x)
ans =  1
octave:31> isimag(x)
ans =  0
octave:32> iscomplex(x)
ans = 0
octave:33> y = i
y =  1i
octave:34> isreal(y)
ans = 0
octave:35> isimag(y)
ans =  1
octave:36> iscomplex(y)
ans =  0
octave:37> z = 1 + i
z =  1 + 1i
octave:38> isreal(z)
ans = 0
octave:39> isimag(z)
ans = 0
octave:40> iscomplex(z)
ans =  1

The above scenario seems to me consistent and all three functions would be "orthogonal", i.e., not duplicate function or simple complement. If one were to mix-and-match real and imaginary, I'd think that promoting to "complex" in that case would make sense.

...

Just trying a few things here, I've sort of lost my faith in the meaning of "isreal()". Generally speaking, it could mean:

1) The class of the variable is real, meaning there is no imaginary component present. 2) The variable has no imaginary component, or it does have an imaginary component which is zero.

Unfortunately by having the property you describe above, i.e., "complex returns an all zero imaginary part", the two are sort of conflated.

Consider for example if I want to test if the imaginary portion of some variable is zero:

octave:41> isreal(1 + 0i)
ans =  1
octave:42> isreal(complex(1,0))
ans = 0

Well, "isreal()" clearly doesn't mean that. I just put together a patch for fftfilt() that intends to check if the imaginary component of the inputs are zero using "isreal()", but I think I will change that to all(imag(x) == 0)) instead because the latter expression has clear definition.

One could be lead to think that "isreal" DOES mean the imaginary portion is zero. Check this out:

octave:50> z = complex([1 2 3],[1 0 2])
z =

   1 + 1i   2 + 0i   3 + 2i

octave:51> isreal(z(2))
ans =  1
octave:52> iscomplex(z(2))
ans = 0

Perhaps the above is a compatibility disagreement. Otherwise it is a little confounding. Conceptually, I can grasp either scenario 1 or scenario 2 above, but there seems to be a hybrid that escapes me.

How do others feel about deprecating "iscomplex()" if it simply is the complement of "isreal()"?

I would be open to an "iscomplex" and "isimag" that have a more "class-related" behavior as I pondered above. I don't think that would go against compatibility.

I'm also wondering if it might be worth writing in the documentation for isreal() that "isreal(x) is not the same as all(imag(x)==0)".

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]