bugGNU Octave - Bugs: bug #65618, Complex numbers cant be computed...

 
 

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
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items
bugspower operator: 0.^0 results in NaN in some case (bug #54302, Confirmed)

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.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-04-21 mmuetzel StatusNone Confirmed
        Operating SystemGNU/Linux Any
        Dependencies- Depends on bugs #54302

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-ec04.
    Corresponding source code