# bug #65618: Complex numbers cant be computed when the value is 0 and in a vector

 Submitter: None Submitted: Sun 21 Apr 2024 09:24:05 AM UTC Category: Interpreter Severity: 3 - Normal Priority: 5 - Normal Item Group: None Status: Confirmed Assigned to: None Originator Name: Originator Email: -email is unavailable- Open/Closed:  * Open Release:  * 7.3.0 Operating System:  * Any Fixed Release: None Planned Release: None
* Mandatory Fields

Add a New Comment Rich Markup

## Discussion

Mon 22 Apr 2024 05:25:56 AM UTC, comment #4:

Ah. You might have meant that the exponent in your example is not complex.
That is true. But bug #54302 still applies in that case.

Markus Mützel <mmuetzel>
Mon 22 Apr 2024 05:23:53 AM UTC, comment #3:

`[0*j j 2*j]` is an array of complex double precision floating point numbers. All elements of it are stored as complex. Arrays can't store a mix of complex and real numbers (in a storage type sense).
The `0*j` (outside of an array) might look like a complex zero. But it is implicitly converted to real (by the times operator).

Markus Mützel <mmuetzel>
Sun 21 Apr 2024 03:25:55 PM UTC, comment #2:

the exponential is not complex

Anonymous
Sun 21 Apr 2024 10:22:44 AM UTC, comment #1:

IIUC, the issue is that the following operations have different results in Octave:

>> 0^0
ans = 1
>> complex(0,0)^complex(0,0)
ans =  NaN + NaNi

In Matlab R2024a:

>> 0^0

ans =

1

>> complex(0,0)^complex(0,0)

ans =

1

>>

IIUC, the result of 0^0 is up for definition. See: https://en.wikipedia.org/wiki/Zero_to_the_power_of_zero

Imho, that definition should probably be consistent independent on whether the input is real or complex valued.
That doesn't seem to be the case for the C or C++ standards though. See the section "Programming languages" of that Wikipedia article. That (directly taking the result from the standard library implementation) might very well be the reason why the results differ in Octave...

All in all this sounds like a duplicate of bug #54302.

I'll leave this open for now in case this is something different.

Markus Mützel <mmuetzel>
Sun 21 Apr 2024 09:24:05 AM UTC, original submission:

num=1
den=[1 1]

fun=@(s) num*s'.^[ length(num)-1:-1:0]' ./(den*s'.^[ length(den)-1:-1:0]')

fun(0*j)%<----the 0 works

fun(j)

fun(2*j)

fun([0*j j 2*j])%<-----the 0 gives NaN but it works when the 0 is alone

fun([ j 2*j])

when calculating complex numbers of value 0 in a vector it gives NaN but it works alone and with other numbers in a vector.

Anonymous

## Attached Files

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Comment:

No files currently attached

## Dependencies

Depends on the following items

Digest:
bug dependencies.

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by mmuetzel (Posted a comment)
•

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only group members can vote.