Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Lucas Cordiviola 

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




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Lucas Cordiviola 
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




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em qua., 26 de fev. de 2020 às 10:30, IOhannes m zmoelnig 
escreveu:

> i think alex really meant: "I've tested loading externals and it just
> doesn't create[,] and [instead] complain[s]."
>

yup
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig 
On 26.02.20 14:26, Christof Ressi wrote:
>> I've tested loading externals and it just doesn't create and complain
> 
> Are you sure? Turn on log level 4.

i think alex really meant:

"I've tested loading externals and it just doesn't create[,] and
[instead] complain[s]."


mgfsdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig 
On 26.02.20 14:22, IOhannes m zmoelnig wrote:
> On 26.02.20 14:12, Alexandre Torres Porres wrote:
>> I've tested loading externals and it just doesn't create and complain, but
>> trying to load cyclone with [declare -lib cyclone] crashes Pd!
> 
> could that be a duplicate of
> ?

ah sure:



class_new() *might* return a NULL-pointer (and it will, if the precision
doesn't match), so you have to check for that before you access any
class members.


asdrm
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi 

I've tested loading externals and it just doesn't create and complain


Are you sure? Turn on log level 4. Here's what I get when I try to load 
a single precision [markex/randomF] in my double precision built:



refusing to load 32bit-float object 'randomF' into 64bit-float Pd
maximum object loading depth 1000 reached
 markex/randomF

Note that actual warning is only visible with log level 3 and above.


but trying to load cyclone with [declare -lib cyclone] crashes Pd! 

Please run Pd in a debugger and see where it crashes.

I also get a crash when trying to load [iemguts/receivecanvas]. In this 
specific case, the reason is that this object registers a proxy class 
without a name (passing NULL instead of a symbol for the class name), so 
Pd segfaults when it tries to print the warning. Pd should do a NULL 
check and probably omit the warning for unnamed classes.


Christof


On 26.02.2020 14:12, Alexandre Torres Porres wrote:



Em qua., 26 de fev. de 2020 às 10:09, Dan Wilcox > escreveu:


Forgive me if this has been gone over, but what's the behavior if
a single-precision Pd tries to load a double-precision external or
vice versa? Does it fail to load or simply crash?

If it crashes, maybe there needs to be some mechanism to query the
compiled precision of the external, ie. some sort of function
pointer or define, etc. If it's not there, then assume
single-precision and act accordingly. It would be nice to have
useful error print concerning this. I'm just musing here. :)


I've tested loading externals and it just doesn't create and complain, 
but trying to load cyclone with [declare -lib cyclone] crashes Pd!


___
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

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig 
On 26.02.20 14:12, Alexandre Torres Porres wrote:
> I've tested loading externals and it just doesn't create and complain, but
> trying to load cyclone with [declare -lib cyclone] crashes Pd!

could that be a duplicate of
?

fgmasdf
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig 
On 26.02.20 14:09, Dan Wilcox wrote:
> Forgive me if this has been gone over, but what's the behavior if a 
> single-precision Pd tries to load a double-precision external or vice versa? 
> Does it fail to load or simply crash?

with Pd>=0.51, the class_new will refuse to register the objectlcass
(and instead return NULL).

e.g.

> refusing to load 32bit-float object 'choice' into 64bit-float Pd

resp.

> refusing to load 64bit-float object 'choice' into 32bit-float Pd

if you attempt to load a double-precision external with Pd<0.51, it will
refuse to load the library with an error:

> choice.pd_linux: undefined symbol: class_new64

fgmasdr
IOhannes

PS: https://lists.puredata.info/pipermail/pd-dev/2015-02/020073.html



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em qua., 26 de fev. de 2020 às 10:09, Dan Wilcox 
escreveu:

> Forgive me if this has been gone over, but what's the behavior if a
> single-precision Pd tries to load a double-precision external or vice
> versa? Does it fail to load or simply crash?
>
> If it crashes, maybe there needs to be some mechanism to query the
> compiled precision of the external, ie. some sort of function pointer or
> define, etc. If it's not there, then assume single-precision and act
> accordingly. It would be nice to have useful error print concerning this.
> I'm just musing here. :)
>

I've tested loading externals and it just doesn't create and complain, but
trying to load cyclone with [declare -lib cyclone] crashes Pd!
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Dan Wilcox 
Forgive me if this has been gone over, but what's the behavior if a 
single-precision Pd tries to load a double-precision external or vice versa? 
Does it fail to load or simply crash?

If it crashes, maybe there needs to be some mechanism to query the compiled 
precision of the external, ie. some sort of function pointer or define, etc. If 
it's not there, then assume single-precision and act accordingly. It would be 
nice to have useful error print concerning this. I'm just musing here. :)

> On Feb 26, 2020, at 1:58 PM, pd-dev-requ...@lists.iem.at wrote:
> 
> Message: 4
> Date: Wed, 26 Feb 2020 13:58:50 +0100
> From: Christof Ressi mailto:i...@christofressi.com>>
> To: pd-dev@lists.iem.at 
> Subject: Re: [PD-dev] [PD] double precision merged
> Message-ID: <7f65121f-810d-c952-40f8-4f0facbbb...@christofressi.com 
> >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 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


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi 
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

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em qua., 26 de fev. de 2020 às 09:50, Christof Ressi 
escreveu:

> The other possibility would be that the GUI objects perform some kind of
> rounding in double precision mode according to the box width.
>

Yeah, I think that definitely would be the best feature/solution
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi 
Yes, but additional digits are just truncated, there's no rounding. The 
problem IOhannes mentioned is that with double precision you more often 
encounter situations where you don't get exact numbers because the 
rounding happens much later. So you might something like 3.9 
in double precision where single precision might have rounded to 4. In a 
number box, this would be displayed as "3.999".


The other possibility would be that the GUI objects perform some kind of 
rounding in double precision mode according to the box width.


Christof

On 26.02.2020 13:44, Alexandre Torres Porres wrote:



Em qua., 26 de fev. de 2020 às 09:29, Christof Ressi 
mailto:i...@christofressi.com>> escreveu:


I can see that showing too many digits can be annoying in number boxes

But you can set the width/digits of number boxes, it's not that now 
all boxes will change and show more numbers, and by default it still 
is 5 digits.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em qua., 26 de fev. de 2020 às 09:29, Christof Ressi 
escreveu:

> I can see that showing too many digits can be annoying in number boxes
>
But you can set the width/digits of number boxes, it's not that now all
boxes will change and show more numbers, and by default it still is 5
digits.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi 
I can see that showing too many digits can be annoying in number boxes, 
but in object boxes, where the number is (usually) typed by the user, 
the higher precision is certainly desirable. At the very least, Pd 
should *save* the number with a higher precision.


Christof

On 26.02.2020 12:48, Alexandre Torres Porres wrote:
Em qua., 26 de fev. de 2020 às 08:31, IOhannes m zmoelnig 
mailto:zmoel...@iem.at>> escreveu:


no. see
https://github.com/pure-data/pure-data/pull/807#issue-348421658


hmm, I see a discussion about pd being able to have double precision 
numbers but the GUI not being able to hold it. I don't understand why. 
I'd like to be able to see something like 3.1415926535 in a number box 
and be able to save in the patch something like [* 3.1415926535].


___
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

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Christof Ressi 

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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em qua., 26 de fev. de 2020 às 08:31, IOhannes m zmoelnig 
escreveu:

> no. see https://github.com/pure-data/pure-data/pull/807#issue-348421658


hmm, I see a discussion about pd being able to have double precision
numbers but the GUI not being able to hold it. I don't understand why. I'd
like to be able to see something like 3.1415926535 in a number box and be
able to save in the patch something like [* 3.1415926535].
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
Em ter., 25 de fev. de 2020 às 20:44, Alexandre Torres Porres <
por...@gmail.com> escreveu:

> I was expecting to see huge numbers in the atom boxes and print, but I
> still get it with the same resolution as before.
>

So, does it mean we still have single precision on floats?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread Alexandre Torres Porres 
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 
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
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

2020-02-26 Thread IOhannes m zmoelnig 
(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 :-(



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev