(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 :-(
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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 26.02.20 13:00, Christof Ressi wrote:
I think I found it :-)
https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
thanks!
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
that's the point.
i don't want to "compile double precision externals". i want to compile an external that works with the installed version of Pd, no matter what endianness, data model or sample-type.
if the installed Pd has not been produced with a tweaked build (overriding *FLAGS, using a non-standard compiler,...) then any external that was built via the standard procedure (using default *FLAGS and compiler,...) should "just work".
endianness, data model,... are kept consistent by using the "default" compiler for your environment/OS.
sample-type is defined via a public header that comes with Pd. why would it define a value that does not match the Pd runtime that provides it?
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.
that was my point: it's equally simple to use any of the two methods. but using CPPFLAGS supposedly tells you that you are now cruising dangerous waters. (some people might not smell any difference; but if for them both options are the same, /they/ are not a compelling reason to prefer one over the other)
In your example, both happen at configure time. The big advantage of having a configure flag is that it is self-documenting ("./configure --help").
yes. that's the advantage. i don't think it outweighs the drawback though.
just to make clear: i'm not at all opposed to adding a configure flag to select the precision (whether it's "--enable-double", "--enable-double-precision" or "--enable-precision=double" doesn't matter though i like the latter better). but that flag should be reflected in the public API.
fgasdrm IOhannes
I see you point and I think it's a philosophical issue. In Supercollider, for example, I can't compile a UGen plugin and expect it to run on both Scsynth and Supernova, I rather have to pass the correct define ("SUPERNOVA"). Plugins are therefore usually built twice - with and without "-DSUPERNOVA" - and since they have different extensions and export different symbols, they can coexist. I think this could be a solution for Pd as well. If we had some naming convention for double precision externals, we can then just built both versions unconditionally and Pd will load the correct version. This can be automated by pd-lib-builder.
Christof
On 26.02.2020 13:39, IOhannes m zmoelnig wrote:
On 26.02.20 13:00, Christof Ressi wrote:
I think I found it :-)
https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729 thanks!
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
that's the point.
i don't want to "compile double precision externals". i want to compile an external that works with the installed version of Pd, no matter what endianness, data model or sample-type.
if the installed Pd has not been produced with a tweaked build (overriding *FLAGS, using a non-standard compiler,...) then any external that was built via the standard procedure (using default *FLAGS and compiler,...) should "just work".
endianness, data model,... are kept consistent by using the "default" compiler for your environment/OS.
sample-type is defined via a public header that comes with Pd. why would it define a value that does not match the Pd runtime that provides it?
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.
that was my point: it's equally simple to use any of the two methods. but using CPPFLAGS supposedly tells you that you are now cruising dangerous waters. (some people might not smell any difference; but if for them both options are the same, /they/ are not a compelling reason to prefer one over the other)
In your example, both happen at configure time. The big advantage of having a configure flag is that it is self-documenting ("./configure --help").
yes. that's the advantage. i don't think it outweighs the drawback though.
just to make clear: i'm not at all opposed to adding a configure flag to select the precision (whether it's "--enable-double", "--enable-double-precision" or "--enable-precision=double" doesn't matter though i like the latter better). but that flag should be reflected in the public API.
fgasdrm IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I have also requested this:
https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html
:)
Mensaje telepatico asistido por maquinas.
On 2/26/2020 9:58 AM, Christof Ressi wrote:
I see you point and I think it's a philosophical issue. In Supercollider, for example, I can't compile a UGen plugin and expect it to run on both Scsynth and Supernova, I rather have to pass the correct define ("SUPERNOVA"). Plugins are therefore usually built twice - with and without "-DSUPERNOVA" - and since they have different extensions and export different symbols, they can coexist. I think this could be a solution for Pd as well. If we had some naming convention for double precision externals, we can then just built both versions unconditionally and Pd will load the correct version. This can be automated by pd-lib-builder.
Christof
On 26.02.2020 13:39, IOhannes m zmoelnig wrote:
On 26.02.20 13:00, Christof Ressi wrote:
I think I found it :-)
https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729 thanks!
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
that's the point.
i don't want to "compile double precision externals". i want to compile an external that works with the installed version of Pd, no matter what endianness, data model or sample-type.
if the installed Pd has not been produced with a tweaked build (overriding *FLAGS, using a non-standard compiler,...) then any external that was built via the standard procedure (using default *FLAGS and compiler,...) should "just work".
endianness, data model,... are kept consistent by using the "default" compiler for your environment/OS.
sample-type is defined via a public header that comes with Pd. why would it define a value that does not match the Pd runtime that provides it?
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.
that was my point: it's equally simple to use any of the two methods. but using CPPFLAGS supposedly tells you that you are now cruising dangerous waters. (some people might not smell any difference; but if for them both options are the same, /they/ are not a compelling reason to prefer one over the other)
In your example, both happen at configure time. The big advantage of having a configure flag is that it is self-documenting ("./configure --help").
yes. that's the advantage. i don't think it outweighs the drawback though.
just to make clear: i'm not at all opposed to adding a configure flag to select the precision (whether it's "--enable-double", "--enable-double-precision" or "--enable-precision=double" doesn't matter though i like the latter better). but that flag should be reflected in the public API.
fgasdrm IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I have requested this as it will be more simple for me to upload double-precision externals builds from my current w64 deken (I have uploded (many, almost all) the with sources and pd-lib-builder so it shouldn't be hard to have windows32/windows64 double builds)
:)
Mensaje telepatico asistido por maquinas.
On 2/26/2020 11:40 AM, Lucas Cordiviola wrote:
I have also requested this:
https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html
:)
Mensaje telepatico asistido por maquinas.
On 2/26/2020 9:58 AM, Christof Ressi wrote:
I see you point and I think it's a philosophical issue. In Supercollider, for example, I can't compile a UGen plugin and expect it to run on both Scsynth and Supernova, I rather have to pass the correct define ("SUPERNOVA"). Plugins are therefore usually built twice - with and without "-DSUPERNOVA" - and since they have different extensions and export different symbols, they can coexist. I think this could be a solution for Pd as well. If we had some naming convention for double precision externals, we can then just built both versions unconditionally and Pd will load the correct version. This can be automated by pd-lib-builder.
Christof
On 26.02.2020 13:39, IOhannes m zmoelnig wrote:
On 26.02.20 13:00, Christof Ressi wrote:
I think I found it :-)
https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729 thanks!
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
that's the point.
i don't want to "compile double precision externals". i want to compile an external that works with the installed version of Pd, no matter what endianness, data model or sample-type.
if the installed Pd has not been produced with a tweaked build (overriding *FLAGS, using a non-standard compiler,...) then any external that was built via the standard procedure (using default *FLAGS and compiler,...) should "just work".
endianness, data model,... are kept consistent by using the "default" compiler for your environment/OS.
sample-type is defined via a public header that comes with Pd. why would it define a value that does not match the Pd runtime that provides it?
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.
that was my point: it's equally simple to use any of the two methods. but using CPPFLAGS supposedly tells you that you are now cruising dangerous waters. (some people might not smell any difference; but if for them both options are the same, /they/ are not a compelling reason to prefer one over the other)
In your example, both happen at configure time. The big advantage of having a configure flag is that it is self-documenting ("./configure --help").
yes. that's the advantage. i don't think it outweighs the drawback though.
just to make clear: i'm not at all opposed to adding a configure flag to select the precision (whether it's "--enable-double", "--enable-double-precision" or "--enable-precision=double" doesn't matter though i like the latter better). but that flag should be reflected in the public API.
fgasdrm IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
PS: i'm absolutely sure i write this up before (months, years ago?) but cannot find it anymore :-(
I think I found it :-) https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmoelnig -
Lucas Cordiviola