[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