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

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

[Octave-bug-tracker] [bug #48736] Multiplication is thrice as fast as di


From: anonymous
Subject: [Octave-bug-tracker] [bug #48736] Multiplication is thrice as fast as division
Date: Wed, 29 Mar 2017 03:38:33 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0

Follow-up Comment #10, bug #48736 (project octave):

Next try:

...gives on my x86-64 about 0.27. And you can even motivate why this is about
25% (and for specific distributions a and b are drawn from would probably be
exact): 1./b is an operation, and its result gets assigned to an intermediate
variable (let's call it c), aquiring up to a half eps of rounding error. Thus,
the exact results of  a./b  and  a.*c  differ by this up to half eps. And now
you assign these results again to floating-point variables. And if you do the
convolutions, you get 25% in different bins, which you can simulate like
this:


a=rand(1000000,1);
b=rand(1000000,1);
mean(round(a)!=round(a+b-.5))


In this context:
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html What Every
Computer Scientist Should Know About Floating-Point Arithmetic: "The IEEE
standard requires that the result of addition, subtraction, multiplication and
division be exactly rounded." Octave wants to be IEEE 754 compliant, isn't it?
Thus, every computer scientist should read up on floating-point arithmetic,
and if he decides that in this specific application it is not necessary, he is
free to do this optimization by hand. Otherwise, on octave forge there is an
unmaintained fenv package listed. Perhaps this can relax the compliance,
allowing octave to optimize such expressions (which would be a nice feature
request -- I would definitely turn it on by default, as the only purpose of
the strict compliance can be for debugging on different platforms, while if
you see effects due to this in standard operation, you are probably just
computing artefacts anyway). 

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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