# [Numpy-discussion] Complex numbers response

Tim Hochberg tim.hochberg at ieee.org
Tue Oct 3 17:59:57 CDT 2006

```Kenny Ortmann wrote:
>> There may be a better way, but::
>>
>>    alltrue(isreal(x))
>>
>> Would work. As would:
>>
>>    not sometrue(x.imag)
>>
>> In the above test you are already negating the test, so you could just
>> drop the not.
>>
>>>  and if so is
>>> there a way to extract the(a + ib) because the absolute value of a
>>> complex
>>> number is like the pythagorean therom on a and b?
>>>
>
> what i was looking for in the above is that when I looked up the
> abs(complexnum) i saw that the abs() of a complex num is (a^2 + b^2)^.5 so i
> was asking for a way to do this because i was assuming that i was going to
> have to parse through the array in a for loop and if i found a complex
> number then get the a and b to do the pythagorean theorom but it seems i
> will not have to do this, as for the matlab code see below
>
OK. Yeah, you shouldn't have to do element by element calculations here.

>> I'm not entirely sure what you are looking for here, but x.imag and
>> x.real will give you the real and imaginary parts. abs(x) will return
>> the magnitude of x whether x is real or complex. x.conj() will return
>> complex conjugate.
>>
>> I'm somewhat suspicious of that matlab code. The code given is
>> discontinuous as you cross the negative real axis. Does the result
>> subsequently get squared or something? I'm guessing that either the
>> matlab code is doing extra work, or there are some hidden assumptions
>> (all values are in the positive real half-plane). Or some such. In
>> either case, you'd probably be OK just skipping the check for realness
>> and always taking the absolute of array. I can't say for sure without
>> more context though.
>>
>> -tim
>>
>
> this is taken out of a program i am converting from matlab to python, so I
> can not explain all of it, it would take forever, BUT
> COEmix, the input, is equal to a different arrays 0 and 2 rows added
> together.  So with that being said, it can not be empty, and must be actual
> numbers.  The reason I am "scared" to remove the isreal statement that i
> asked about is because the array before hand has values that are taken from
> square roots.  I do not know if these could ever end up being complex and I
> am meeting with the head of this project tomorrow to discuss it, but you
> asked so i thought i would share.
>

Just to beat a deceased equine a bit more: what I'm concerned about here
is that the code as it stands will result in a positive number for
(-x+jy), not matter how small y is, while resulting in a negative number
for -x. That discontinuity seems unlikely to be what is desired.
Actually, it's worse than that, if there are any complex numbers in the
array, all the numbers will be converted to positive real numbers. So,
for example:

[-1, 1, -2, 2, 5] => [-1, 1, -2, 2, 5]

while:

[-1, 1, -2, 2, 3+4j] => [1, 1, 2, 2, 5]

Now it's quite possible that the way COEmix is generated constrains it's
value in some way. It's possible that it's constrained to the positive
half plane, or perhaps more likely that it's ideally a positive real
number that may stray slightly off the real axis, so to clean it up the
absolute value is being taken.

Since, I can't think of a case where you actually want the discontinuity
described above, I'm guessing that the code would be just fine as
COEmix = abs(COEmix)
That is, unconditionally take the absolute value. However, that *is*
just a guess. The answer lies in how COEmix is originally generated and
perhaps in how it is used as well.

Regards,

-tim

[... CODE...]

```