[PD-dev] double precision Pd: .patch files, tests and benchmarks

Hans-Christoph Steiner hans at at.or.at
Sat Oct 1 17:25:13 CEST 2011


Hey Katja,

This is great, just starting to dig into it.  Its a great write-up too.
I'd like to put together some Pd-extended nightly builds based on this,
and start working out a work flow for all the fixes that we will
inevitably need to do.  To start with, I think you should request SVN
commit access so you can directly commit fixes to externals as we find
them.  I know there will be loads of changing float to t_float and
things like that, and I imagine a few places that'll need more work.

https://puredata.info/docs/developer/SVNCommitAccess

Then next, I think it makes sense to start a git fork to work on this.
github.com is a pretty easy place to put it, or gitorious.org.  Then I
can setup a nightly build based on that repo.

I just looking thru your patches, a couple of quick comments to make the
patches a lot more readable.  Basically, before submitting, read the
output of 'git diff' and try to make it so that the only changes that
appear are ones that change the function of the code, not how the code
looks.  That makes for a shorter and much more readable patch.

* keep the indentation the same, in a few places in the patch, it seems
that the only difference is the indentation.  It should be all spaces,
no tabs, with 4 spaces as a single level of indentation.

* try to eliminate spacing changes like:
-
-#ifndef N32
+#ifndef N32    
 t_float qsqrt(t_float f) {return (q8_sqrt(f)); }
 t_float qrsqrt(t_float f) {return (q8_rsqrt(f)); }
 #endif
 
-
-
 typedef struct sigrsqrt


* keep variable names the same, when it makes sense, for example:
-    x->x_arrayname = s;
+    x->arrayname = s;

-    float x_f;      /* scalar frequency */
+    t_float f;	    // scalar frequency 



* it seems you define this union a lot in d_math.c, why not just once at
the top?
+    union
+    {
+        float f;
+        int32_t l;
+    }u;

* same with GOODINT, perhaps that should just be defined once in a
header?

* also, I think the %g printf pattern should handle the number of
decimals, so perhaps in print_float it should just be %g or %lg.

.hc

On Sat, 2011-10-01 at 03:12 +0200, katja wrote:
> Hello,
> 
> 
> Finally my double-precision-Pd efforts resulted in code decent enough
> to be useful in practice. It's all documented on:
> 
> 
> http://www.katjaas.nl/doubleprecision/doubleprecision.html
> 
> 
> From there you can download a .zip with two .patch files to make
> vanilla Pd 0.43-0 double precision ready. In fact what you have is
> 'arbitrary-precision' code which can be built for single or double
> precision with the setting of a single definition in the API header
> m_pd.h. Test patches are included.
> 
> 
> So far, I have tested on OSX and Linux. Remarkably, double precision
> Pd performance is comparable to current Pd on the Intel CPU's. The
> only drawback that I can think of is, it eats memory. This would be a
> bummer for Pd users doing Ableton style stuff with lots of soundfiles
> to be loaded into RAM. Krzysztof Czaja already warned me for this at
> Pd Con, but at the time I forgot a bit about the problems with loading
> soundfiles during a live session.
> 
> 
> For me, as a precision freak, it is a delight to work with double
> precision Pd. Some examples are illustrated on mentioned webpage.
> Unfortunately, my music stuff needs Pd extended. I would be happy to
> continue the project.
> 
> 
> Katja
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev





More information about the Pd-dev mailing list