[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Numerical issues with sin()/cos()
From: |
vlad ionescu |
Subject: |
Re: Numerical issues with sin()/cos() |
Date: |
Wed, 28 Mar 2018 06:46:47 +0000 |
Hello
I am sorry, despite being able to see all the (current) 4 replies in
the gnu.org list, Gmail still didn't bother to let me know, so I am
replying to my own sent mail.
> v1 = sin (0.37 * pi * n) ./ (pi * n);
> v2 = sin (0.37 * pi * [n]) ./ (pi * [n]);
>
> I think what is hurting your precision here is the lazy evaluation of
> ranges in Octave.
This is the first time I see this, so I did some search. Correct me if
I am wrong, but, apparently, it's about the way Octave stores the
range. If it's without square braces, it uses less storage, which
probably means it uses floats instead of doubles, which might explain
the precision (in fact, I am pleasantly surprised by the accuracy,
now), but that still leaves the question of why sin(-x) != -sin(x),
though I guess it's the floating point representation of the numbers,
as they go up, or down, different fractions (just guessing), but
then...
> FWIW the h I obtain above is not equal to the h I get from the attached
> fir function. The error is worst at index 18, the same as the error you
> are seeing.
Could it be that different CPU architectures calculate differently the
floats? I can't imagine why you would get different results. Did you
use fir(33,[0 0.37])? Still, the eror is, again, at index 18, so maybe
it really is about the floating point representation.
At any rate, as soon as I made my range as n=[...], everything went
spot on. Thank you.
> I ran across a fairly recent (2008) paper on some of the "dark arts" of
> finding good approximations to mathematical functions. It does in part
> look at sin(x).
Well, for my part, I'm fine with the way Octave does it, thank you for
the suggestion.
Vlad