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

[katja]

On Wed, Feb 4, 2015 at 12:03 PM, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> just a word with my debian maintainer hat on:
>
> if Pd-vanilla supported double-precision builds, i would like to make
> these available for Debian and derivatives as well.
>
> if i made single- and double-precision builds co-installable (which
> iÄm not sure yet), it would be as "pd" and "pd64", with pd64 using
> different default configuration (~/.pd64settings) and search paths
> (/usr/lib/pd64/extra/).
> and install all (packaged) externals that can be build for double
> precision into /usr/lib/pd64/extra/, rather than having phat builds.
>
> i don't think we should spend too much time/energy on designing and
> supporting foolproof phat builds at all (as this is probably
> impossible without the help from the OS).
>

Allright, I was just carried away by the prospect of phat /
fat-precision binaries. But indeed it's regular practice to keep Pd
build and externals together. So the only critical point is install
time. If users add external libs in the path of Pd 'by hand' they need
to verify the origin anyway. For example one can't add Pd-L2Ork
externals to Pd vanilla / extended or vice versa, even though these
have the same name and extension.

So what you propose (for the 'non-phat' case) is a protection
mechanism to avoid Pd loading a wrong-precision external. That is most
important, because a wrong-precision external causes spurious
malfunctions, of which segfaulting may not even be the worst because
that is at least a clear signal. And a double precision Pd build and
process should identify itself as such so you need not guess what
precision you're using at any moment. It is perfectly possible to run
Pd instances of different precision simultaneously, is what I recall
from my experiments in 2011.

Katja