Hi Matt,
thanks for chiming in!
Christof:
This should ensure that the table is symmetric, unless the
underlying cos() function is broken :)
I think the underlying cos() function is dependent on architecture and
compiler?
Yes. cos() is a library function, so the output depends on the
particular C library implementation, the compiler and the also
architecture. I would still expect it to be (reasonably) symmetric, but
I haven't really checked.
Even with the new cosine table, on my machine the zero crossings have
a (very tiny) residual, so it's sitting at a very small DC offset.
You're right, I didn't consider the peaks and zero-crossings! The values
of 1/2 PI, PI and 3/2 PI cannot be accurately represented as floating
point numbers, so the result of cos() may be a bit off.
I think we should explicitly set these points:
cos_newtable[COSTABLESIZE / 4] = 0.0; /* 1/2 PI */
cos_newtable[COSTABLESIZE / 2] = -1.0; /* PI */
cos_newtable[COSTABLESIZE / 4 * 3] = 0.0; /* 3/2 PI */
@Miller: what do you think? IMO we should make the cos table as good as
we can, so we won't have any regrets :)
The rest of the function looks symmetric, though, and certainly much,
much better than the previous one.
Thanks for checking!
Christof
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
