[PD-dev] [PD] double precision merged

[Christof Ressi]

> 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'm not sure I understand. Why do we have to change the default value? 
If someone wants to compile double precision externals, they just have 
to pass the -DPD_FLOATSIZE=64 to the build system (pd-lib-builder could 
add an option to simplify this). After all, I have to know the host I'm 
building for. Currently, I only have to care about the architecture, but 
single/double precision will become another distinguishing feature. Such 
features are not a problem as long as the runtime can detect it - which 
luckily is the case for single/double precision.

> 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".

I don't see the conflict, to be honest. Also, I don't think there's a 
*practical* difference between setting a configure flag and setting the 
CPPFLAGS variable. In your example, both happen at configure time. The 
big advantage of having a configure flag is that it is self-documenting 
("./configure --help").

Christof

On 26.02.2020 10:09, IOhannes m zmoelnig wrote:
> (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/6a0f9a48/attachment-0001.html>