Hi Christof, Thanks!
Don't forget the guard point, which could also be set explicitly to 1.0 Matt On Wed, Jun 5, 2024, 4:29 AM Christof Ressi <[email protected]> wrote: > 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 >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
