bugGNU Octave - Bugs: bug #43313, Complex number relation operators...

 
 

bug #43313: Complex number relation operators (=, <, >) yield two logical trues

Submitter:  Dan Sebald <sebald>
Submitted:  Sun 28 Sep 2014 03:02:43 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 27 Jan 2015 06:33:46 PM UTC, comment #3: 

I applied your patch to the development branch in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/bdf90710dddf).  I'm not sure exactly why, but we have a different set of sort comparison functions for use with issorted.  So I updated those so that sort and issorted both agree on this new definition.  Finally I added a new file in the test/ directory to check the behavior of these two routines.

Rik <rik5>
Group administrator
Mon 29 Dec 2014 05:58:29 AM UTC, comment #2: 

A related bug appears to be bug #42301.

Rik <rik5>
Group administrator
Sat 04 Oct 2014 07:23:31 AM UTC, comment #1: 

The arg()/carg() function of the C math library has a range of [-pi,pi], i.e., -pi inclusive.  Attached is a changeset that will map -pi to pi.  This appears to fix complex(-1,0) > complex(-1,-0) case and sorting.

The change to the header file touches pretty much the whole tree, so before compiling make sure there's agreement with the logic of the conditionals.

(file #32221)

Dan Sebald <sebald>
Sun 28 Sep 2014 03:02:43 AM UTC, original submission:  

This was first discovered by R. in the sort() routine, in which complex numbers are first sorted by modulus and then angle.

The relational operators (=, <, >) for complex numbers in which the real portion is negative and the imaginary portion is -0 for one value and +0 for the other value show two cases that evaluate to true:


octave:137> complex(-1,0) == complex(-1,-0)
ans =  1
octave:138> complex(-1,0) > complex(-1,-0)
ans =  1
octave:139> complex(-1,0) < complex(-1,-0)
ans = 0


I believe only equality should be true, because the similar test for the floating point scenario behaves that way:


octave:143> -0 == 0
ans =  1
octave:144> -0 > 0
ans = 0
octave:145> -0 < 0
ans = 0


First modulus is compared and if the two numbers have equal modulus then angle is compared.  Given the behavior of atan2(), i.e.,


octave:152> atan2(0,-1)
ans =  3.1416
octave:153> atan2(-0,-1)
ans = -3.1416


the non-unique angle for the same number makes one of the inequality tests pass.  It's best to use the principle argument, which is created by mapping -pi of atan2() to pi before performing the test.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #32221:  octave-complex_operators-2014oct03.patch added by sebald (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-01-27 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2014-12-29 rik5 StatusNone Confirmed
    2014-10-04 sebald Attached File- Added octave-complex_operators-2014oct03.patch, #32221

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code