[PD-dev] [PD] more about float limitation

IOhannes m zmölnig zmoelnig at iem.at
Tue Feb 3 20:16:17 CET 2015

moving this to pd-dev....

On 02/03/2015 06:16 PM, katja wrote:
> has for using Pd. When working on Pd-double in 2011 I was interested
> in 'scientific' applications of Pd like impulse response measurement,
> where double precision is crucial in some calculations. My current
> focus is more on live performance and I've never felt a need for
> doubles in this realm. Still I would be happy to help out with

i cannot help thinking of chun's really nice expr~ live-coding set and
the problem he experienced with the lack of precision (iirc, his [wrap~]
based counters would eventually become inaccurate in timing...which
turns into a problem if your minimal techno base drum get's out of sync...)


> 1. graceful handling of binary incompatibility between core <>
> externals of different precision


> Regarding binary incompatibility between builds of different
> precision, this is a serious problem which can't be resolved under the
> quick-and-easy approach of specifying t_float at compile time. I would

the main problem seems to be, that an external can register a new
double-precision object-class to a single-precision pd-runtime (or vice
versa, though the former case will lead easier to segfaults).

how about this simple suggestion:
a double-precision pd-runtime will only add new classes, if they are
registering themselves with "class_new64()" rather than "class_new()".
using a preprocessor macro, we can change the "class_new" to
"class_new64" in case the user is compiling for double precision.
the pd-runtime shall always support class_new64() but throw a warning
when called in a single-precision build

something like:

EXTERN t_class *class_new32(...)
EXTERN t_class *class_new64(...)
#if PD_FLOATSIZE == 64
# define class_new class_new64
# define class_new class_new32

t_class*class_new_doit(...) {
  /* put the actual implementation of the class registry in here */
t_class*class_new32(...) {
#if PD_FLOATSIZE != 32
   verbose(1, "not registering single-precision class");
   return 0;
   return class_new_doit(...);
t_class*class_new64(...) {
#if PD_FLOATSIZE != 64
   verbose(1, "not registering double-precision class");
   return 0;
   return class_new_doit(...);
#undef class_new
t_class*class_new(...) {
 /* legacy way to register (single-precision) classes */
 return class_new32(...);

afaict, the only thing left is to make sure that Pd handles
NULL-pointers as classptrs gracefully in the other class_... functions
(class_addbang()) - that is: ignores them.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150203/129f64c3/attachment.sig>

More information about the Pd-dev mailing list