[PD-dev] [PD] double precision merged

Alexandre Torres Porres porres at gmail.com
Wed Feb 26 11:48:00 CET 2020


well, let me ask this again.

Will we have for download both the single and double-precision Pds?

Makes sense to me it'd be officially either single or double - hence double
it'd be, so we could enjoy more precision.

So, what's the plan?

And what would we need to adapt and compile externals that can run in
double precision Pd?

cheers

Em qua., 26 de fev. de 2020 às 06:10, IOhannes m zmoelnig <zmoelnig at iem.at>
escreveu:

> (i'm not sure how this ended on pd-list, m oving it back to pd-dev)
>
> On 25.02.20 23:53, Dan Wilcox wrote:
> >> On Feb 25, 2020, at 11:41 PM, Christof Ressie wrote:
> >>
> >> I think there's no configure flag (yet). In the meantime you can
> >> compile Pd with
> >>
> >> make CPPFLAGS="-DPD_FLOATSIZE=64"
> >
> > I'd suggest --enable-double or --enable-double-precision
> >
>
> TL;DR adding a configure-flag opens a whole can of worms that are not
> related to double-precision
>
> long version:
>
> the reason why i have not added a configure flag to enable/disable
> double-precision builds is, that i was not satisfied with the
> implications of such a flag.
>
> enabling a feature via a configure-flag is (at least for me) a way of
> saying that "from now on, whatever i do with the so-generated project
> (Pd) will have this feature enabled".
>
> however, this is not the case in for a double-precision build.
> why?
>
> a double-precision Pd changes two fundamental things:
> - the precision of the Pd-core
> - the interface to externals
>
> the former is obvious, as this is what double-precision is about.
> the latter is not a problem per se, as we have taken steps to make sure
> to neither break API (so you can compile any well-written external with
> double-precision) nor ABI (so externals built for one precision won't
> fail *catastrophically* in a runtime of a different precision).
>
> however, the main expectation from any API is, that if you compile
> something against a given version of header-files, then the result
> outght to work *flawlessly* (which is much more strict than "not
> catastrophically") with the corresponding runtime (of the same version).
>
> with double-precision this is currently *not* the case:
> if you build Pd in double-precision mode, its headers will still be
> identical to a single-precision build. compiling an external against
> these headers will therefore produce a single-precision binary - which
> will not work properly in the double-precision Pd.
>
> if we want to pass the selected precision on to the entire ecosystem
> that depends on a given Pd runtime (that is: all externals that are
> built against a specific version of Pd), than the only solution is to
> replace the default value for PD_FLOATSIZE in m_pd.h.
>
> i have not done that, because traditionally Pd never modified (or
> generated) any headers during build.
> implementing that would not be hard, but it would be a major change in
> the build-system, which i didn't feel like proposing or even discussing
> (and i'm sure there are zillions of pitfalls where such a change would
> result in failing builds).
>
>
> otoh, adding a pre-processor flag to the build process is much more
> ephemeral.
> it basically says "i'm hacking some properties of the build-system to do
> what i want".
> nobody^Wi wouldn't expect such a temporary hack to be picked up by any
> external that happens to build against the given runtime (unless of
> course i apply the same or similar hack to those externals).
>
>
> which is exactly what we get with the current way to enable
> double-precision.
>
> the actual overhead for compiling a double-precision build is not that
> high.
> cf
> > configure CPPFLAGS="-DPD_FLOATSIZE=64"
> vs
> > configure --enable-double-precision
>
>
> mfgasdr
> IOhannes
>
> PS: i'm absolutely sure i write this up before (months, years ago?) but
> cannot find it anymore :-(
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200226/c35a9a10/attachment-0001.html>


More information about the Pd-dev mailing list