t_float would also avoid float to double conversion, for very slightly better performance in Pd64 :)
On Fri, Jun 7, 2024, 11:28 AM Christof Ressi <[email protected]> wrote: > Another question: why is the cos table float* and not t_float *? With > Pd64 we basically throw away 29 bits of additional precision (23 bit vs. > 52 bit). I assume this is done to reduce the table size for Pd64. Is 23 > bit good enough for our purposes? I can imagine that the interpolation > error will be much larger than the difference between 23 bit and 52 bit > precision, but I didn't do the math. > > Christof > > On 06.06.2024 19:24, Miller Puckette 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 > >> <[email protected]> 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 > >> > <[email protected]> wrote: > >> > > >> > Em qua., 5 de jun. de 2024 às 14:31, Matt Barber > >> > <[email protected]> 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 > >> > <[email protected]> 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 <[email protected]> escreveu: > >> > > >> > Nice one Matt! > >> > > >> > Em qua., 5 de jun. de 2024 às 08:13, Christof > >> Ressi > >> > <[email protected]> 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!!! > >> > > >> >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
