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

## [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.

_______________________________________________________

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

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

```