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


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

Submitter:  Rik <rik5>
Submitted:  Wed 13 Nov 2013 01:14:51 AM UTC
Category:  Libraries Severity:  5 - Blocker
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

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

### When compiling math for x87, problems may arise in some code comparing
### floating-point intermediate results.
### Generally, it helps to store the result in a local volatile variable,
### but it also degrades performance.
### Thus, we provide a FLOAT_TRUNCATE macro that may be defined to "volatile"
### when compiling for x87 target, or left empty for modern SSE math, that
### doesn't suffer from this problem at all.
    [enables truncating intermediate FP results.])],
  [if test "$enableval" = yes; then

Rik <rik5>
Group 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.

 Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.

 This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a "double" is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables.
 This option allows further control over excess precision on machines where floating-point registers have more precision than the IEEE "float" and "double" types and the processor does not support operations rounding to those types. By default, -fexcess-precision=fast is in effect; this means that operations are carried out in the precision of the registers and that it is unpredictable when rounding to the types specified in the source code takes place. When compiling C, if -fexcess-precision=standard is specified then excess precision will follow the rules specified in ISO C99; in particular, both casts and assignments cause values to be rounded to their semantic types (whereas -ffloat-store only affects assignments). This option is enabled by default for C if a strict conformance option such as -std=c99 is used.

 -fexcess-precision=standard is not implemented for languages other than C, and has no effect if -funsafe-math-optimizations or -ffast-math is specified. On the x86, it also has no effect if -mfpmath=sse or -mfpmath=sse+387 is specified; in the former case, IEEE semantics apply without excess precision, and in the latter, rounding is unpredictable.

Rik <rik5>
Group 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):

#include <complex>
#include <iostream>

#include "octave-hg/liboctave/util/oct-cmplx.h"

int main (int argc, char **argv)
  std::complex<double> c1;
  std::complex<double> c2;

  c1 = std::complex<double> (0, 1);
  c2 = std::complex<double> (0, 1);

  bool r1 = (c1 < c2);
  bool r2 = (c1 == c2);
  bool r3 = (c1 > c2);

  std::cout << "result:" << std::endl;
  std::cout << " < : " << r1 << std::endl;
  std::cout << " = : " << r2 << std::endl;
  std::cout << " > : " << r3 << std::endl;

  return 0;

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>
Wed 13 Nov 2013 01:14:51 AM UTC, original submission:  

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

octave-cli.exe:9> a = 1 + 1i;
octave-cli.exe:10> b = 1 + 1i;
octave-cli.exe:11> a < b
ans =  1
octave-cli.exe:12> a == b
ans =  1
octave-cli.exe:13> a > b
ans = 0

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

Rik <rik5>
Group administrator


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (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 project members can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-13 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2013-11-13 rik5 Severity3 - Normal 5 - Blocker

    Back to the top

    Powered by Savane 3.12