OK, that's clear, thanks. Still when using [tabread4~] or [tabosc4~] you still need a copy of the last element in the first index and copies of the first two elements in the last two indices, right? Even if you're not using sinesum or cosinesum but some other mathematical function..
On Thu, Sep 5, 2013 at 1:56 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----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_convers... -----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-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list