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

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

[Octave-bug-tracker] [bug #48307] sinc loses precision for large argumen


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #48307] sinc loses precision for large arguments
Date: Sun, 26 Jun 2016 07:05:18 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

Follow-up Comment #3, bug #48307 (project octave):

OK, let's continue along these lines, but let's step back a bit and just
examine what is happening with floating point numbers in Octave.

To illustrate the finite precision of floating point numbers, here is 1/3 in
Octave:


>> sprintf('%0.100g', double(1)/3)
ans = 0.333333333333333314829616256247390992939472198486328125


Yes, that seems to be somewhere around 10^16 where numerical accuracy falls
apart.

Slightly odd is this result.  You indicated Maple's result is:

-0.82699326043336203093078665439080e-7

but when I display that value, I see:

>> Maple = -0.82699326043336203093078665439080e-7
Maple =   -8.2699e-08
>> sprintf('%0.100g', Maple)
ans =
-8.2699326043336200337390017901795236099360408843494951725006103515625e-08

Why doesn't the Maple number turn out to be the same as Octave?  One would
think the number representation is the same for the two programs as it is the
same processor.  Maybe you should try this test on your system.  Also, do a
comparison of division and sine on their own, i.e., compare

x = double(10000001) / 3;
sin(Pi*x)
1/(Pi*x)

between Maple and Octave.  Maybe we can determine if it is the division or
sinusoid that might be problematic.
1 / (Pi*x)

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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