[Octave-bug-tracker] [bug #49166] "system.tst" fails under Windows

[Rik]

Update of bug #49166 (project octave):

                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #3:

This is repeatable on a Windows XP virtual machine that I keep around for
testing.  There are some weird correlations.  If I remove the 'cd ...' line
from the sample script in comment #2--which means Octave is running in the
same directory as the script itself--then the failure does not happen so
quickly.  If I cd to a directory that is not quite so far away from the test
script then the script will fail, but at perhaps the 140th iteration.  If I
keep the original 'cd ...' line then the script fails on the first or second
iteration.

This may be due to extended precision, or lack thereof, when running on
Windows platforms.  If you look at the C++ code for Fcputime in data.cc it is
quite simple.


  if (args.length () != 0)
    print_usage ();

  octave::sys::cpu_time cpu_tm;

  double usr = cpu_tm.user ();
  double sys = cpu_tm.system ();

  return ovl (usr + sys, usr, sys);


>From this, you can see that the m-file code


[t1, u1, s1] = cputime ();
assert (t1, u1 + s1);


really should pass.

In the first case, it is C++ double variables and the C++ '+' operator.

In the second case, it is Octave double variables and the Octave '+'
operator.

After a failure, using format long, I can see that the variables look
correct.


error: ASSERT errors for:  assert (t1,u1 + s1)

  Location  |  Observed  |  Expected  |  Reason
     ()         1.6409       1.6409      Abs err 2.2204e-016 exceeds tol 0>>
format long
>> t1
t1 =  1.64092200000000
>> u1
u1 =  1.32046100000000
>> s1
s1 =  0.320461000000000
>> u1 + s1
ans =  1.64092200000000


And if I do some arbitrary arithmetic, I can get the assert statement to
pass.


>> t = t1 + eps
t =  1.64092200000000
>> u = u1 + eps
u =  1.32046100000000
>> s = s1 + eps
s =  0.320461000000000
>> assert (t, u + s)


I'm going to try declaring the double variables in data.cc Fcputime using the
OCTAVE_FLOAT_TRUNCATE option which should truncate intermediate results and
see if that makes a difference.  That test will take several hours as I have
to rebuild a Windows installer with MXE. 



    _______________________________________________________

Reply to this item at:

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

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