Yep, this one, with a one-shot [until] through the indices into $0-cos-BAD is better than cosinesum in the previous patch, but it still drifts visibly/audibly after a couple minutes; obviously wouldn't be as much of a problem in double precision, though.

On Thu, Jun 6, 2024 at 1:53 PM Matt Barber <brbrofsvl@gmail.com> wrote:

Here's the demonstration. While the symmetric table will eventually drift a little, it stays stable for far longer than osc~ or cosinesum. Although, to be fair, the real test in building a cosine table from scratch in Pd would be to fill the table using [cos], walking through indices and dividing by table size to get phase.

Matt

On Thu, Jun 6, 2024 at 1:39 PM Matt Barber <brbrofsvl@gmail.com> wrote:

The main reason for symmetry was stable FM synthesis – when you modulate frequency, any overall differences in the shape of the cosine wave shape accumulate quickly as an error in the osc~'s phase increment, causing significant drift in the spectrum. It's not a problem when you modulate phase directly since the modulator is decoupled from the phasor.

MB

On Thu, Jun 6, 2024, 1:24 PM Miller Puckette <mpuckette@cloud.ucsd.edu> wrote:

Precisely that: cache pollution in general.  At some point the overall
speed of the program will suffer, depending on CPU design, cache size,
and probable other factors.

If the input to a cos~ object (for example) is between 1 and 2 you'll
get the same loss of accuracy but still there will be rounding behavior
that will (probably) give unsymmetric behavior.

Anyway, I don't remember hearing any reason why symmetry should be
important in itself.

cheers

M

On 6/6/24 6:51 PM, Matt Barber wrote:
> Since cos~ wraps, one could theoretically take advantage of the equal
> distribution of float values between 1.0 and 2.0.
>
> Profiling a larger table would be useful – I prefer accuracy over
> performance in general, but I wonder where the performance hit would
> come from, outside of unpredictable cache misses.
>
>
>
> On Thu, Jun 6, 2024, 11:25 AM Miller Puckette
> <mpuckette@cloud.ucsd.edu> wrote:
>
>     Well, as far as I can tell making the table "symmetric" won't
>     matter at
>     all since, for instance, 0.1 and 0.9 won't give the same lookup
>     values
>     anyway because they can't themselves be represented exactly and
>     will be
>     truncated differently (0.1 will be more accurately represented than
>     0.9).  On the other hand, values like 0.25 or -0.5 can be represented
>     exactly so it might be worthwhile to bash true 1s, -1,s, and 0s where
>     they belong in the table.
>
>     Hearing that Max defaults to a ridiculously big table makes me wonder
>     though... first, is 2048 really enough (and at what point is there a
>     real performance penalty for bigger tables).  And: not for this
>     release
>     but later perhaps, should 64-bit Pd use a bigger table?
>
>     As I figure it, the 2048-point table differs from the true cosine,
>     absolute worst case, by (2pi/2048)^2 / 8, or about 2(-19.7) -
>     i.e., 19.7
>     bit accuracy.  But the error is dominated by an amplitude change (the
>     best-matching cosine to the line-segment approximation has amplitude
>     less than 1).  Accounting for that and taking RMS error instead of
>     worst-case gives an error estimate 2.7 bits more optimistic: 22.4
>     bits,
>     which is close to the accuracy of a 32-bit number.
>
>     I don't have my RPI3 handy (I'm on the road) but I'm now wondering if
>     the default shouldn't be 4096, which would give us an additional 2
>     bits
>     of goodness.  Any opinions?
>
>     cheers
>
>     M
>
>     On 6/5/24 9:35 PM, Matt Barber wrote:
>     > A couple of things:
>     >
>     > 1. I'm pretty sure any error in cos at pi and 2pi will be
>     smaller in
>     > double precision than float's epsilon, so I don't think that
>     there's
>     > any need to set -1.0 and 1.0 explicitly after all except to be
>     extra
>     > safe. However, at pi/2 and 3pi/2 the error is still larger than the
>     > minimum normal number, so it is worth setting the zero crossings
>     to 0.0.
>     >
>     > 2. For garray_dofo() there isn't a great way of using explicit
>     0.0 at
>     > zero crossings without incurring an extra check, like don't add
>     to the
>     > sum if absolute value is less than e.g. 1.0e-10. For this, probably
>     > just using M_PI and incrementing integer phase like for the cosine
>     > table is enough.
>     >
>     > MB
>     >
>     >
>     > On Wed, Jun 5, 2024 at 2:20 PM Alexandre Torres Porres
>     > <porres@gmail.com> wrote:
>     >
>     >     Em qua., 5 de jun. de 2024 às 14:31, Matt Barber
>     >     <brbrofsvl@gmail.com> escreveu:
>     >
>     >         While we're at it, I think it would be worth tuning
>     >         garray_dofo() to use the same so that sinesum and
>     >         cosinesum have the same level of accuracy, guarantees of
>     >         symmetry, etc.
>     >
>     >         MB
>     >
>     >
>     >     Good catch! In fact, I think this is a great opportunity to also
>     >     fix this bug https://github.com/pure-data/pure-data/issues/371
>     >   
>      <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/371__;!!Mih3wA!Gx7B-gwSgjsuIXmREh2__bBbYdt1d6pi29crpkLOOyltinVweZR3u6Q6vl9ItouugFy2oefgYhPlew$>
>     >     which is totally related. I just reopened
>     > https://github.com/pure-data/pure-data/issues/105
>     >   
>      <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/105__;!!Mih3wA!Gx7B-gwSgjsuIXmREh2__bBbYdt1d6pi29crpkLOOyltinVweZR3u6Q6vl9ItouugFy2oedw4qUPfQ$>
>     >     as well as I'm still considering the table could/should be still
>     >     "perfectly symmetric" considering 0 crossings and the start/end
>     >     points.
>     >
>     >
>     >         On Wed, Jun 5, 2024 at 12:52 PM Alexandre Torres Porres
>     >         <porres@gmail.com> wrote:
>     >
>     >             For the record and sake of comparison, Cyclone uses
>     >             a 16384 points table, and linear interpolation,
>     calculated
>     >             with double precision. We did this because MAX documents
>     >             it uses such a table, and we made it (well, Matt did)
>     >             simetric.
>     >
>     >             I see Pd is doing kind of the same, huh? linear
>     >             interpolation on a table calculated with double
>     precision.
>     >
>     >             I see SuperCollider mentions it uses 8192 points and
>     >             linear interpolation on its oscillator.
>     >
>     >             I guess MAX is exaggerating its table size a bit :)
>     but I
>     >             wonder why Pd is still about to use a relatively smaller
>     >             table size. I'm curious to know how much an increase in
>     >             table size actually offers a better resolution and how
>     >             much it ruins performance. For instance, I'm using the
>     >             same as Cyclone in ELSE oscillators, could I just reduce
>     >             it at least to 8192 points or even less and down to Pd's
>     >             2048 size worry free?
>     >
>     >             Thanks
>     >
>     >
>     >
>     >             Em qua., 5 de jun. de 2024 às 13:28, Alexandre Torres
>     >             Porres <porres@gmail.com> escreveu:
>     >
>     >                 Nice one Matt!
>     >
>     >                 Em qua., 5 de jun. de 2024 às 08:13, Christof Ressi
>     >                 <info@christofressi.com> escreveu:
>     >
>     >>                         @Miller: what do you think? IMO we should
>     >>                         make the cos table as good as we can, so we
>     >>                         won't have any regrets :)
>     >>
>     >                 +1000!!!
>     >
>