[PD] Sinesum, cosinesum and cubic interpolation's guard points

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-09-05 09:45, Alexandros Drymonitis wrote:
> OK, index 0 is the negative of index 2,

no not really, they just happen to be the same.

> which can again make sense as it's a sine (supposing that index 0
> is a copy of the table's last element), but index 512 doesn't have
> that value, why? And why do indices 1 and 513 have different values
> too?

do they?

when it comes to floating point, "equality" becomes a little bit fuzzy.
e.g. "0.1" is really the 'same' as "0.100000001490116119384765625" [1].

comparing the values, you can see that they are not *very* wrong:

array[512]-array[0] = -5.30668e-6 = -0.0000053
array[513]-array[1] = -5.30718e-6 = -0.0000053
array[514]-array[2] = -5.30668e-6 = -0.0000053

so the errors are really rather small, and hopefully don't matter so
much in the interpolation (which is another approximation anyhow).

the reason why the error is not smaller, is that Pd internally
(src/g_array.c:896) deals with a PI value of 3.14159, which is a
rather rough estimate and is the reason why the cycle is not exactly
512 points long.


fgamsdr
IOhannes

[1]
http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion_and_rounding
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlIoY3UACgkQkX2Xpv6ydvTY1wCcDCyH8kY50snbVOv5AxwspIAB
jwQAoLJOrVoESvzyqrZyvWKky0ec1eUT
=YqkS
-----END PGP SIGNATURE-----