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@iem.at http://lists.puredata.info/listinfo/pd-dev