maybe you should also make sqrt~ should call the true functionwhile at it? references https://github.com/pure-data/pure-data/issues/1906 / https://github.com/pure-data/pddp/issues/125#issuecomment-1353459554
cheers Em dom., 26 de mai. de 2024 às 06:16, Miller Puckette < [email protected]> escreveu: > OK, so in a few years every new PC will probably have ARM or other RISC > architecture. > > I just made the interesting discovery that, on Mac ARMs, there is a > difference, probably a slight decrease, in numerical accuracy in Pd's > DSP objects. So we've lost exact compatibliity and only have > pretty-good-approximate compatibility. On one piece I tested the > divergence is about -100 dB relative to maximum amplitude and in > another, which I think has unstable feedback paths, the results are > further off. > > SO... I can now relax my insistence on exact back-compatibility for osc~ > and cos~ and ... make them more accurate! I think I should do this for > 0.55. > > Now for the questions: > > 1. Unfortunately COSTABLESIZE (512) is declared in m_pd.h. Can I > change this value (conditionally, increasing it for 64-bit PDs and for > some or all ARM architectures) without breaking externals that might use > the built-in cosine table? > > 2. should I make the table size variable, either by a new [declare] > flag, or by passing a flag to osc~ and cos~? This could affect run time > - I'd want to investigate that. > > 3. Alternatively, should I just leave COSTABSIZEE at 512 for specific > architectures in non-double (Intel for compatibilty, and possibly RPI if > there turns out to be a bad performance hit). I'd choose a new one > after doing some profiling because at some point increasing table size > will lead to bad cache behavior. (Historical note: the number 512 gives > a 4096-point table which is the memory page size of the Intel I860, > beyond qhich performance dropped by a factor of 10 or more. Recently I > tested a 2048-point table, which is 36dB lower-noise, on a bog-standard > Intel Linuix machine and... saw no penalty at all). > > I'm afraid it will take me (and whoever else is interested in this) some > time to figure everything out. But I think at 0.55 we're still at a > point where we don't have to be extremely strict about numerical > reproducibilty on ARM/Macintosh or on Pd-double, and so this seems a > good time to attack this. It's been a long-standing problem. > > cheers > > Miller > > > > > _______________________________________________ > 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
