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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
