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

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

[Octave-bug-tracker] [bug #53713] test failure "speed.m" in Octave 4.3.9


From: Hartmut
Subject: [Octave-bug-tracker] [bug #53713] test failure "speed.m" in Octave 4.3.91
Date: Sun, 22 Apr 2018 16:55:02 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0

Follow-up Comment #5, bug #53713 (project octave):

If have tested your suggestions from comment #3 on my Win7 machine.

Running this code:

for n=1:5
  n
  t1 = time; sum (rand (1e5, 1)); ta = time - t1
  t1 = time; sum (rand (3e5, 1)); tb = time - t1
  t1 = tic;  sum (rand (1e5, 1)); tc = toc (t1)
endfor


produces the following results:

n =  1
ta =  0.0050001
tb =  0.014001
tc =  0.0043731
n =  2
ta =  0.0039999
tb =  0.014001
tc =  0.0043750
n =  3
ta =  0.0039999
tb =  0.015001
tc =  0.0053759
n =  4
ta =  0.0040009
tb =  0.014000
tc =  0.0043781
n =  5
ta =  0.0039999
tb =  0.015001
tc =  0.0043790


So, no, the results are not very close to the "zero" of a floating point type.
Is this some discrepancy to your current hypothesis?

And regarding your code on comment #4:

for n=1:10
  t0 = time (); pause (0.001); t = time () - t0
endfor


gives:

t =  0.0010002
t =  0.0010009
t =  0.0010002
t =  0.0019999
t =  0.0010002
t =  0.00099993
t =  0.0010002
t =  0.00099993
t =  0.00099993
t =  0.0010002


So a threshold at t<0.001 does NOT seem to be a good idea to me.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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