[L2Ork-dev] A plea for full double precision support out of the box in Purr data

[Jonathan Wilkes]

Hi Yoann,
I've always been interested in this. But it's a daunting task because of the multitude of 
externals which ship with Purr Data. It's very difficult to predict how any of those libraries 
will behave by changing t_float from float to double.
However, in the next few days I'm going to have a rudimentary testing patch in place 
for the CI runners. This rudimentary test counts the number of successful object instantiations 
for every in the "extra" directory. There must be a minimum number of successful
object creations returned after loading all the libraries, or else the 
build will fail. (There was a script to load libs this back in the Pd-extended days to check 
for segfaults, but it doesn't look like it was ever used in an automated 
fashion.)
Right now the test is very primitive because the number of bug revealed merely by 
trying to test all possible constructors required lots of fixes, and that ate up most of my dev 
time. However, it should be possible to extend these tests in order to clamp down on 
the number of constructors _per_ _libdir_. That will instill an initial sense of sanity to 
the development process.

Once that is done, it should then be possible to test each built-in method of every object 
that can be instantiated. (Excepting some special cases that make get in an infinite loop 
merely by sending a "0" or a "bang".) Additionally, it should be possible to test a dsp method 
for each tilde object, making sure that the actual vector that gets output is the same across 
releases.
Now if we can get to that point, we can then take the state of the tests from release n and 
use them to gauge the effect of changing t_float to double for release n+1. (Ignoring for the 
moment all of the core changes and ports of katja's code that must happen even for core 
pd to function properly at double precision.) Any object that returns vector state that is 
off by some threshold warrants further investigation, as would crashes, of course.
Everything except the upcoming rudimentary test is rank speculation. And I have no idea 
how many external libraries use novel things like type punning tricks inside dsp perform routines.
Anyway, more feedback is welcome. I think there are quite a few places where double precision 
makes life easier. (E.g., 32-bit int fits comfortably inside it.)

-Jonathan

> Hi! 

> Intermediate user of Pd for a few years, I've been looking at Purr data this week and I'm quite amazed how slick it feels patching with it! Kudos to the devs and contributors, this is really impressive :). I'm writing this mail to exchange on a pretty specific feature that Pd lacks and to know if it could make its way into Purr data. 
  > Double precision. 
  > There is a clear explanation on the whereabouts of double precision computing in Pd here (http://www.katjaas.nl/doubleprecision/doubleprecision.html), a video illustrating this point here (https://youtu.be/93632nc8LVs) and a fork of Pd extended 0.43.1 with full DP support here (https://github.com/pd-projects/pd-double).
 > An interesting quote from the first link: 
> While having limited effect on overall sound quality, double precision can still be beneficial for the quality of Pd programming in a different sense. Precision-robustness, combined with full numerical control from within the GUI, will convert Pd from a pocket calculator into a scientific calculator. Any user - artist or scientist - could verify meticulous math stuff directly in Pd, rather than bc, Octave, Grapher, C, or whatever inconvenient combination of these. As a computer language, Pd could be used for math classes and assignments at any level. Abstractions illustrating advanced math topics could be made. A wider use of Pd as a serious math language could have an impact on technical knowledge shared within Pd community. In my view,  double precision could affect sound quality in particular via this detour. 
  > On a more personal experience, I crashed at least twice on the single precision wall.  The first time was when I followed this serie of articles (http://www.earlevel.com/main/2013/06/01/envelope-generators/) on creating an ADSR enveloppe with adjustable curve. I had to triple check my port of the C code following wires and boxes to then see that after a few math operations there were huge calculation errors. The second time was when I found this thesis on Roland supersaw(https://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2010/rapporter10/szabo_adam_10131.pdf). An interesting read that I couldn't implement in Pd due to rounding errors in computations of the equation shown p.12. 
  > I see Purr data as a refreshing reboot of Pd trying to tackle some of its inherited quirks and nice-at-the-time-but-ageing-nowadays technological choices and couldn't resist to ask you if you could at least please consider this request. Seeing that Purr data intends to keep a K12 release, this could be a nice addition for scholar use ;)
  Cheers, 
  Yoann
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/l2ork-dev/attachments/20170819/9016106c/attachment.html>