The double precision testing thread leads me to comment on an external I've been writing. I decided I needed an external (with 32-bit signals input) that would add up blocks of signals over time with an internal 64-bit accumulator to avoid losing precision during this step.
But as I thought about other options for it to perform (sample-wise accumulation, sum of squares, whether the output should be normalized), it started turning into a real swiss army knife, one object with a ton of configuration choices, outputs, and control options. It could be used to read long tables with tabread4~~ for instance, or turn distributions into normalized cumulative distribution functions. There would be the option of retrieving the full 64-bit value on the output through pairs of signals/messages or truncating the precision back to 32-bits with a single output. When signals fan in to a inlet they are summed together in 32-bits, so that has to be avoided. Should I have it use a variable number of inlets or make new objects that have multiple inlets? Yikes... what am I doing? Is there a different question here? What set of 64-bit externals could do all the things a double-precision Pd *could* do? You only really lose precision when doing certain things. Is there a better way to organize the functions for usage among several objects? Which ones are essential? What set would make it complete? Yikes... In the same manner as the PdCUDA signal memory space and perform routine duplication (I designed but never published an implementation), you could control whether objects used a 32-bit signal memory space and dsp functions vs a 64-bit version of the same. You'd control the behavior through the dspcontext struct and add an object to switch it on/off in subpatches, thus using the double precision only when you need it. Array design and implementation remains problematic. This is a terrible idea. I'll go ahead and build something for my immediate usage (after my classes conclude in 2 weeks) that does just a few things, but I have to wonder if there's something better there that should be done instead. Any advice? Chuck _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
