octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #43741] different results from power operator


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #43741] different results from power operator in mxe-octave GUI/CLI
Date: Wed, 01 Apr 2015 19:35:51 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.2.0

Follow-up Comment #7, bug #43741 (project octave):

This is almost certainly a float-store problem, but I'm not sure why there is
a difference with the cli and gui versions.  Is it possible to set the storage
mode dynamically?

I don't fully understand what's happening, but using gdb I found that in both
cases the 10^(-2) operation is ultimately calling powi from the mingw math
library.  This function computes x = 1/10 and then x *= x to generate the
result.

Here is a simplified function that demonstrates the same problem:


#include <octave/oct.h>
DEFUN (foo, args, , "")
{
  double x = args(0).scalar_value ();
  x = 1 / x;
  x *= x;
  return octave_value (x);
}


Using "format bit", you can see the difference:


format bit
x = 1/10; [foo(10); x*x]
ans =

  0011111110000100011110101110000101000111101011100001010001111011
  0011111110000100011110101110000101000111101011100001010001111100


Declaring X volatile in Ffoo makes the results be the same, as does compiling
foo.cc with -ffloat-store.

I agree that it's bad to have the CLI and GUI versions produce different
results and we should probably try to figure out why that's happening.  But I
also see that the following expressions produce different results on my Debian
system:


x = 1/10; [x*x; 1/100]
ans =

  0011111110000100011110101110000101000111101011100001010001111100
  0011111110000100011110101110000101000111101011100001010001111011


I don't see what can be done about that, though I expect the result will be
surprising to some users.  In this case, I don't think the intermediate result
(x = 1/10) is stored in an extended precision register because it is stored in
a scalar octave_value object.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?43741>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]