bugGNU Octave - Bugs: bug #40560, a < b incorrect for complex...

 
 

bug #40560: a < b incorrect for complex numbers on MinGW

Submitted by:  Rik <rik5>
Submitted on:  Wed 13 Nov 2013 01:14:51 AM UTC  
 
Category: LibrariesSeverity: 5 - Blocker
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 13 Nov 2013 11:30:24 PM UTC, comment #6:

Fixed by enabling float truncation on MinGW and Cygwin platforms (http://hg.savannah.gnu.org/hgweb/octave/rev/82f096e1a805)

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 09:05:08 PM UTC, comment #5:

I re-compiled with --enable-float-truncate and the comparisons work again. Now, this just needs to be added into the build scripts.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 08:23:39 PM UTC, comment #4:

Rik said:
"What about compiling with either of these two options from gcc which limit the precision of math results to IEEE standards? "

It seems to me that this is the best choice. It is only very
exceptional cases where it would make sense to go outside
the IEEE Standard. Such cases are typically coded in Fortran
in any case.

Michael Godfrey <godfrey>
Project Member
Wed 13 Nov 2013 06:27:44 PM UTC, comment #3:

More of the history is comping back now. I think we added the --float-truncate option specifically for Tatsuro who was doing Windows builds at the time. Here is the excerpt from configure.ac.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 06:20:04 PM UTC, comment #2:

What about compiling with either of these two options from gcc which limit the precision of math results to IEEE standards? It might be easier to throw a compile flag, so we know we get the correct behavior everywhere, rather than the only place we've seen a problem which is with Complex numbers.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 06:06:16 PM UTC, comment #1:

I believe this is due to rounding/truncation error accumulation in the FPU registers. Consider the following test code (adapt the octave include to the actual location of octave source tree):

The expected output is r1=0, r2=1, r3=0. However it occurs that the output can be r1=1, r2=1, r3=0

Using MinGW/GCC-4.8.1 I can observe the following:
- compiling with -O2 leads to incorrect output
- compiling with -O0 leads to correct output
- compiling with -O2 and defining FLOAT_TRUNCATE to "volatile" leads to correct output

Michael Goffioul <goffioul>
Project Member
Wed 13 Nov 2013 01:14:51 AM UTC, original submission:

I found the following behavior while investigating a failing test in quadgk.

a < b should return false, and it does on Linux, but something is wrong with the MinGW system.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 13 Nov 2013 11:30:24 PM UTCrik5StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 13 Nov 2013 04:57:41 PM UTCrik5Severity3 - Normal=>5 - Blocker

    Back to the top


    Powered by Savane 3.1-cleanup1