Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach chakekatzil@gmail.com:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry ch@chnry.net wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit :
it's a limitation of 32 bit float
I thought so, but same happens when I use the new Pd Vanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits
Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
6 significant digits also allow a number like 0.000123456
2015-01-29 14:17 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach chakekatzil@gmail.com:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry ch@chnry.net wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit :
it's a limitation of 32 bit float
I thought so, but same happens when I use the new Pd Vanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits
Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 29/01/15 16:17, Alexandre Torres Porres wrote:
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution?
32 bit float with 24 bit precision (around 7.22 decimal digits)
And why can't you have the same resolution in a message?
You can have higher resolution in .pd files, but when they are loaded Pd decides to reduce the resolution for display purposes. Then when you save the patch the higher resolution is lost.
Pd reduces the resolution for display purposes so that (eg) adding "0.1" ten times displays as "1" instead of it's true value which is closer to "1.0000001".
Whether this is a good idea or not is debatable - on the plus side "1" is easier to read, on the minus side numbers can look the same but compare unequal (eg) adding "0.1" ten times then [select 1].
2015-01-28 16:06 GMT-02:00 Martin Peach chakekatzil@gmail.com:
You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
pdlua uses whatever number type Lua was compiled with, usually double.
Claude
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>> wrote: Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla 64 bits... this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua. Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto: chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla64 bits...
this mean that it's compiled for 64 bit CPU, not that float arestore on 64 bits
Also last time I checked, Pd saves floats by first printing them to 6digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres porres@gmail.com wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto: chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla64 bits...
this mean that it's compiled for 64 bit CPU, not that float arestore on 64 bits
Also last time I checked, Pd saves floats by first printing them to6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
and how does one use [lpi] in a mac?
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto: chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that float arestore on 64 bits
Also last time I checked, Pd saves floats by first printing them to6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you have pd-extended it will open lpi with the built-in pdlua loader. I placed lpi-test and lpi.pd_lua in a directory and started pd-extended from there. You can also right-click on the lpi object to open it in an editor.
Martin
On Thu, Jan 29, 2015 at 1:05 PM, Alexandre Torres Porres porres@gmail.com wrote:
and how does one use [lpi] in a mac?
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I
get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that floatare store on 64 bits
Also last time I checked, Pd saves floats by first printing themto 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i got extended 0.42-5, it doesn't happen
2015-01-29 16:22 GMT-02:00 Martin Peach chakekatzil@gmail.com:
If you have pd-extended it will open lpi with the built-in pdlua loader. I placed lpi-test and lpi.pd_lua in a directory and started pd-extended from there. You can also right-click on the lpi object to open it in an editor.
Martin
On Thu, Jan 29, 2015 at 1:05 PM, Alexandre Torres Porres <porres@gmail.com
wrote:
and how does one use [lpi] in a mac?
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I
get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that floatare store on 64 bits
Also last time I checked, Pd saves floats by first printing themto 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have 0.43-4. Probably one of these will work: http://autobuild.puredata.info/auto-build/latest/
Martin
On Thu, Jan 29, 2015 at 1:36 PM, Alexandre Torres Porres porres@gmail.com wrote:
i got extended 0.42-5, it doesn't happen
2015-01-29 16:22 GMT-02:00 Martin Peach chakekatzil@gmail.com:
If you have pd-extended it will open lpi with the built-in pdlua loader.
I placed lpi-test and lpi.pd_lua in a directory and started pd-extended from there. You can also right-click on the lpi object to open it in an editor.
Martin
On Thu, Jan 29, 2015 at 1:05 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
and how does one use [lpi] in a mac?
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I
get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)]
- also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
> Well, thanks everyone. > > And now for some related issues. > > Pd can only represent up to 6 significant digits, so they say. For > example, in a message, you can have a number with up to 5 decimal places, > like: -5.29314e+12 > > but it does have a better internal resolution, if you compare 4 / 3 > to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and > check). > > So, what's this internal resolution? And why can't you have the same > resolution in a message? > > thanks > > 2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com > mailto:chakekatzil@gmail.com>: > > On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net > mailto:ch@chnry.net> wrote: > > > > Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > > > it's a limitation of 32 bit float > > I thought so, but same happens when I use the new Pd > Vanilla 64 bits... > > this mean that it's compiled for 64 bit CPU, not that float > are store on 64 bits > > Also last time I checked, Pd saves floats by first printing them > to 6 digit precision, so they have even less range than a 'float' type. > You could use an object made with pdlua to manipulate large > floating-point numbers, as there is no(?) limit to the size of a float in > lua. > > Martin > > _______________________________________________ > Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
So, cant we raise the bit resolution of pd to more than what's there? how?
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto: chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that float arestore on 64 bits
Also last time I checked, Pd saves floats by first printing them to6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 31/01/2015 07:46, Alexandre Torres Porres a écrit :
So, cant we raise the bit resolution of pd to more than what's there? how?
by replacing float by double. katja made a lot's of work around this http://www.katjaas.nl/doubleprecision/doubleprecision.html there are lot's of mail in this list to read, search the archive for pd double.
but this ill not solve the precision problem, just move it...
cheers c
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol. Martin On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: >more that 7 digit but less than 8 digits ... > so, 4/3 =! 1.33333 > but 4/3 == 1.33333333 (8 "3") I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8? In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits... I have a work around using expr. Just put the number in parenthesis. Try [expr 4./3 == (1.33333333)] (8 "3") but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3" cheers 2015-01-29 14:58 GMT-02:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: hello, ok, claude was faster to answer, but since i already write my mail, i send it anyway... pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float. the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved) try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch) you can also have a look on the top right of the patch: a weird effect of float precision... cheers c Le 29/01/2015 17:17, Alexandre Torres Porres a écrit : Well, thanks everyone. And now for some related issues. Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12 but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check). So, what's this internal resolution? And why can't you have the same resolution in a message? thanks 2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com <mailto:chakekatzil@gmail.com> <mailto:chakekatzil@gmail.com <mailto:chakekatzil@gmail.com>>__>: On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> wrote: Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla 64 bits... this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua. Martin _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I erroneously sent my last reply to a single recipient-- here's the gist... There's a hidden premise in this thread that Pd's representation of float atoms in the GUI must be exactly the same as the representation in the Pd file. Not only is that false, but AFAICT the only sane way to solve the problem is to decouple the two. I can display floats as an abacus widget in a GUI without storing a blurry base64 jpeg representation in a patch file, so surely Pd can display the same user-friendly number representation people are used to, and store a lossless representation in a patch file. What I didn't say in my single-recipient reply is that making a change like that would probably be a pain. I haven't investigated the details, but I'll guess that it either requires introducing some asymmetry in the parser, or parsing object box text a second time to convert from hex (or whatever it would be in the patch file) to readable numbers to display in the GUI. Plus the current patch file number representation would need to carry forward, so that adds more complexity. Finally-- since we're not building financial systems with Pd, it's unclear to me which category of bug this is. Is this actually breaking patches in subtle ways? On the one hand I notice when I lose precision in an iemcolor after setting some color and reloading a patch. On the other I've never noticed a timbre changing in an analogous way when producing audio. I guess if you're doing something like saving/reloading a message box full of sine frequency/amplitude pairs you'd notice? -Jonathan
On Saturday, January 31, 2015 3:35 AM, Cyrille Henry <ch@chnry.net> wrote:
Le 31/01/2015 07:46, Alexandre Torres Porres a écrit :
So, cant we raise the bit resolution of pd to more than what's there? how?
by replacing float by double. katja made a lot's of work around this http://www.katjaas.nl/doubleprecision/doubleprecision.html there are lot's of mail in this list to read, search the archive for pd double.
but this ill not solve the precision problem, just move it...
cheers c
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
>more that 7 digit but less than 8 digits ... > so, 4/3 =! 1.33333 > but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com <mailto:chakekatzil@gmail.com mailto:chakekatzil@gmail.com>__>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net <mailto:ch@chnry.net mailto:ch@chnry.net>> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit :
> it's a limitation of 32 bit float
I thought so, but same happens when I use the new Pd Vanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits
Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin
_________________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello, can you help me to connect a [adc~] object to my TR808 drum-machine patch ? Thanks ! David
Envoyé de mon iPhone
Le 31 janv. 2015 à 07:46, Alexandre Torres Porres porres@gmail.com a écrit :
So, cant we raise the bit resolution of pd to more than what's there? how?
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres porres@gmail.com wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>> wrote: Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla 64 bits... this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua. Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/31/2015 12:06 PM, Rivoire David wrote:
Hello, can you help me to connect a [adc~] object to my TR808 drum-machine patch ? Thanks ! David
- switch to edit mode (Ctrl-E)
- move the mouse to one of the small black rectangles at the bottom of
the [adc~]. 3. click and drag the mouse cursor to the small black rectangle at the top of your TR808 drum-machine patch. 4. release the mouse button
- do not hijack unrelated posts.
quoting the [netiquette]:
If you want to start a new thread (that is, bring up a new topic), please, please do start a new thread by sending a fresh email which is not a reply; do not take a random post to the list and reply to this post with a changed subject and body just because you don't know the email address of the list. A lot of people with decent mail readers view their mails in "thread view", so they know which mail is a reply to which other mail. It is quite annoying if you cannot find the mail regarding the possibilities to play back a sound file (which you know has the answer to your troubles) just because it is deep within a thread regarding the problems of firewalls on W32-XP!
So never reply to an email on the list, if you don't have anything to say about the content of the email you are replying to.
- do not assume that anybody knows the contents of your harddisk. what
is "your TR808 drum-machine patch".
- it might also help if you gave a bit of context (what do you really
want to do?)
nmfgdsr IOhannes
[netiquette] http://puredata.info/community/lists/Netiquette
oops,
On 01/31/2015 02:46 PM, IOhannes m zmölnig wrote:
- do not hijack unrelated posts.
[...]
- in any case, always make sure that the subject of your post is
up-to-date (*change* the subject if the topic of the thread moves away from the original question)
gfmsadr IOhannes
Le 31/01/2015 14:46, IOhannes m zmölnig a écrit :
On 01/31/2015 12:06 PM, Rivoire David wrote:
Hello, can you help me to connect a [adc~] object to my TR808 drum-machine patch ? Thanks ! David
- do not assume that anybody knows the contents of your harddisk. what
is "your TR808 drum-machine patch".
- it might also help if you gave a bit of context (what do you really
want to do?)
nmfgdsr IOhannes
The only TR808 patch I know is in netpd, it's a sample player so using [adc~] seems pointless.
I tried this using c on Windows:
float: Pi is 3.14159274101257320000000000000 double: Pi is 3.14159265358979310000000000000 , which matches the supercollider value: 3.1415926535898
My lpi.pd_lua also gives 3.141592653589793100 on WIndows but on linux I got 48 digits after the decimal: 3.1415926535897931159979634685441851615905761718750000
And from http://www.piday.org/million/ the first 54 digits of pi are these:
3.14159265358979323846264338327950288419716939937510582
So a float is accurate to 6 decimal places, a double is accurate to 15, and supercollider rounds the double to 13. Lua on linux gives 48 digits but it's also only accurate to 15.
Martin
On Sat, Jan 31, 2015 at 1:46 AM, Alexandre Torres Porres porres@gmail.com wrote:
So, cant we raise the bit resolution of pd to more than what's there? how?
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I
get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that floatare store on 64 bits
Also last time I checked, Pd saves floats by first printing themto 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, SC is double float, but they seem to round it up for some reason, maybe the same reason as Pd. But SC uses single float for signal processing, so it is the same as Pd in the end.
Well, I did believe that Pd compiled for 64bits did increase the resolution to double, but ok, it does not. And yeah, it just means it's compiled for a 64 bit OS... But what does it mean in practical terms? What is the advantage?
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
Now, if it were to run as double precision, then it'd clearly run slower, right?
I don't have much deep knowledge in this, I appreciatte if anyone cares to share their wisdom.
thanks Alex
2015-01-31 18:23 GMT-02:00 Martin Peach chakekatzil@gmail.com:
I tried this using c on Windows:
float: Pi is 3.14159274101257320000000000000 double: Pi is 3.14159265358979310000000000000 , which matches the supercollider value: 3.1415926535898
My lpi.pd_lua also gives 3.141592653589793100 on WIndows but on linux I got 48 digits after the decimal: 3.1415926535897931159979634685441851615905761718750000
And from http://www.piday.org/million/ the first 54 digits of pi are these:
3.14159265358979323846264338327950288419716939937510582
So a float is accurate to 6 decimal places, a double is accurate to 15, and supercollider rounds the double to 13. Lua on linux gives 48 digits but it's also only accurate to 15.
Martin
On Sat, Jan 31, 2015 at 1:46 AM, Alexandre Torres Porres <porres@gmail.com
wrote:
So, cant we raise the bit resolution of pd to more than what's there? how?
Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as
3.1415926535898
so thats more than 24 bit float, but what is it?
cheers
2015-01-29 15:47 GMT-02:00 Martin Peach chakekatzil@gmail.com:
Here's a patch using pdlua that shows the value of pi in various ways. I
get 48 decimal places in a symbol.
Martin
On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry ch@chnry.net:
hello,
ok, claude was faster to answer, but since i already write my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float.
the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of the patch: a weird effect of float precision...
cheers c
Le 29/01/2015 17:17, Alexandre Torres Porres a écrit :
Well, thanks everyone.
And now for some related issues.
Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And why can't you have the same resolution in a message?
thanks
2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.netmailto:ch@chnry.net> wrote:
Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new PdVanilla 64 bits...
this mean that it's compiled for 64 bit CPU, not that floatare store on 64 bits
Also last time I checked, Pd saves floats by first printing themto 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 01/02/2015 17:42, Alexandre Torres Porres a écrit :
Yeah, SC is double float, but they seem to round it up for some reason, maybe the same reason as Pd. But SC uses single float for signal processing, so it is the same as Pd in the end.
Well, I did believe that Pd compiled for 64bits did increase the resolution to double, but ok, it does not. And yeah, it just means it's compiled for a 64 bit OS... But what does it mean in practical terms? What is the advantage?
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.
Now, if it were to run as double precision, then it'd clearly run slower, right?
I don't have much deep knowledge in this, I appreciatte if anyone cares to share their wisdom.
benchmarck and lot's more are here : http://www.katjaas.nl/doubleprecision/doubleprecision.html
cheers c
thanks Alex
2015-01-31 18:23 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com>:
I tried this using c on Windows: float: Pi is 3.14159274101257320000000000000 double: Pi is 3.14159265358979310000000000000 , which matches the supercollider value: 3.1415926535898 My lpi.pd_lua also gives 3.141592653589793100 on WIndows but on linux I got 48 digits after the decimal: 3.1415926535897931159979634685441851615905761718750000 And from http://www.piday.org/million/ the first 54 digits of pi are these: 3.14159265358979323846264338327950288419716939937510582 So a float is accurate to 6 decimal places, a double is accurate to 15, and supercollider rounds the double to 13. Lua on linux gives 48 digits but it's also only accurate to 15. Martin On Sat, Jan 31, 2015 at 1:46 AM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: So, cant we raise the bit resolution of pd to more than what's there? how? Martin, about the pi in lua, i never got to see it, but supercollider prints the value of pi as 3.1415926535898 so thats more than 24 bit float, but what is it? cheers 2015-01-29 15:47 GMT-02:00 Martin Peach <chakekatzil@gmail.com <mailto:chakekatzil@gmail.com>>: Here's a patch using pdlua that shows the value of pi in various ways. I get 48 decimal places in a symbol. Martin On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com>> wrote: >more that 7 digit but less than 8 digits ... > so, 4/3 =! 1.33333 > but 4/3 == 1.33333333 (8 "3") I don't get it. More than 7 decimal digits but less than 8 decimal digits? How does that work? In practice, is it 7 or 8? In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits... I have a work around using expr. Just put the number in parenthesis. Try [expr 4./3 == (1.33333333)] (8 "3") but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3" cheers 2015-01-29 14:58 GMT-02:00 Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net>>: hello, ok, claude was faster to answer, but since i already write my mail, i send it anyway... pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float. the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved) try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch) you can also have a look on the top right of the patch: a weird effect of float precision... cheers c Le 29/01/2015 17:17, Alexandre Torres Porres a écrit : Well, thanks everyone. And now for some related issues. Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12 but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check). So, what's this internal resolution? And why can't you have the same resolution in a message? thanks 2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com <mailto:chakekatzil@gmail.com> <mailto:chakekatzil@gmail.com <mailto:chakekatzil@gmail.com>>__>: On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> wrote: Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla 64 bits... this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua. Martin _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
2015-02-01 14:52 GMT-02:00 Cyrille Henry ch@chnry.net:
Le 01/02/2015 17:42, Alexandre Torres Porres a écrit :
Yeah, SC is double float, but they seem to round it up for some reason, maybe the same reason as Pd. But SC uses single float for signal processing, so it is the same as Pd in the end.
Well, I did believe that Pd compiled for 64bits did increase the resolution to double, but ok, it does not. And yeah, it just means it's compiled for a 64 bit OS... But what does it mean in practical terms? What is the advantage?
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.
Now, if it were to run as double precision, then it'd clearly run slower, right?
I don't have much deep knowledge in this, I appreciatte if anyone cares to share their wisdom.
benchmarck and lot's more are here : http://www.katjaas.nl/doubleprecision/doubleprecision.html
cheers c
thanks Alex
2015-01-31 18:23 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto: chakekatzil@gmail.com>:
I tried this using c on Windows: float: Pi is 3.14159274101257320000000000000 double: Pi is 3.14159265358979310000000000000 , which matches the supercollider value: 3.1415926535898 My lpi.pd_lua also gives 3.141592653589793100 on WIndows but on linuxI got 48 digits after the decimal: 3.1415926535897931159979634685441851615905761718750000
And from http://www.piday.org/million/ the first 54 digits of pi arethese:
3.14159265358979323846264338327950288419716939937510582 So a float is accurate to 6 decimal places, a double is accurate to15, and supercollider rounds the double to 13. Lua on linux gives 48 digits but it's also only accurate to 15.
Martin On Sat, Jan 31, 2015 at 1:46 AM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
So, cant we raise the bit resolution of pd to more than what'sthere? how?
Martin, about the pi in lua, i never got to see it, butsupercollider prints the value of pi as
3.1415926535898 so thats more than 24 bit float, but what is it? cheers 2015-01-29 15:47 GMT-02:00 Martin Peach <chakekatzil@gmail.commailto:chakekatzil@gmail.com>:
Here's a patch using pdlua that shows the value of pi invarious ways. I get 48 decimal places in a symbol.
Martin On Thu, Jan 29, 2015 at 12:36 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
>more that 7 digit but less than 8 digits ... > so, 4/3 =! 1.33333 > but 4/3 == 1.33333333 (8 "3") I don't get it. More than 7 decimal digits but less than8 decimal digits? How does that work? In practice, is it 7 or 8?
In the example we see that 4/3 == 1.33333333 (8 "3") - soit's 8 decimal digits...
I have a work around using expr. Just put the number inparenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3") but the thing is that this is also true - [expr 4./3 ==(1.3333333)] - also equal to 7 "3"
cheers 2015-01-29 14:58 GMT-02:00 Cyrille Henry <ch@chnry.nethello, ok, claude was faster to answer, but since i alreadywrite my mail, i send it anyway...
pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.emore that 7 digit but less than 8 digits) pd graphical representation is 6 digits
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of3... this is a generic problem of computer float.
the only odd thing concerning pd is that number arealso saved with 6 digit. (so precision can be lost when a patch is saved)
try the attachment patch. then save the patch, and open it back, and see thatprecision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch)
you can also have a look on the top right of thepatch: a weird effect of float precision...
cheers c Le 29/01/2015 17:17, Alexandre Torres Porres a écrit : Well, thanks everyone. And now for some related issues. Pd can only represent up to 6 significant digits,so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12
but it does have a better internal resolution, ifyou compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check).
So, what's this internal resolution? And whycan't you have the same resolution in a message?
thanks 2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com mailto:chakekatzil@gmail.com <mailto: chakekatzil@gmail.com mailto:chakekatzil@gmail.com>__>:
On Wed, Jan 28, 2015 at 12:00 PM, CyrilleHenry <ch@chnry.net mailto:ch@chnry.net <mailto:ch@chnry.net mailto: ch@chnry.net>> wrote:
Le 28/01/2015 17:47, Alexandre TorresPorres a écrit :
> it's a limitation of 32 bit float I thought so, but same happens whenI use the new Pd Vanilla 64 bits...
this mean that it's compiled for 64 bitCPU, not that float are store on 64 bits
Also last time I checked, Pd saves floats byfirst printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua.
Martin ______________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at><mailto:Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list < http://lists.puredata.info/listinfo/pd-list%3E
On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
if you run a 32bit binary on a 64bit OS, there might be some overhead involved (bit then i really don't know much about the performance of multi-arch systems)
if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is compatible with 32bit CPUs), then it might be slightly slower than compared to a full 64bit system.
the real advantages are:
- memory access!
a 32bit application/OS uses 32bit pointers to access memory. this limits the accessible memory to 4GB (your OS might be able to manage more using PAE; but the application itself will have a maximum of 4GB.) a 64bit application uses 64bit pointers to access memory. thats much more as you are likely to ever see in your lifetime (but then: 2640k are enough" anybody?)
- modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
become a 64bit system). it seems silly to run 32bit applications on such systems (and a waste of ressources, as you need to install a 32bit version the entire runtime-environment)
also check out: http://en.wikipedia.org/wiki/64-bit_computing
fgrsam IOhannes
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS,
right?
why?
The only thing I have to back this assumption up is a recollection of a message by miller to the list saying that tests with the 64 bit version showed it was running faster, but I don't know anything about it, really. Still trying to learn from you.
I'd also suspect that a double precision in Pd would make it much slower, but the benchmarks from Katja didn;t point this out.
Seems like some future version of Pd running in full double precision is not too crazy, huh?
cheers
2015-02-01 19:08 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it
were
compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS,
right?
why?
if you run a 32bit binary on a 64bit OS, there might be some overhead involved (bit then i really don't know much about the performance of multi-arch systems)
if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is compatible with 32bit CPUs), then it might be slightly slower than compared to a full 64bit system.
the real advantages are:
- memory access!
a 32bit application/OS uses 32bit pointers to access memory. this limits the accessible memory to 4GB (your OS might be able to manage more using PAE; but the application itself will have a maximum of 4GB.) a 64bit application uses 64bit pointers to access memory. thats much more as you are likely to ever see in your lifetime (but then: 2640k are enough" anybody?)
- modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
become a 64bit system). it seems silly to run 32bit applications on such systems (and a waste of ressources, as you need to install a 32bit version the entire runtime-environment)
also check out: http://en.wikipedia.org/wiki/64-bit_computing
fgrsam IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think you're talking about several things at once. Katja's Pd Double is essentially about changing t_float to be a double-precision floating point number. But as I understand it she also revised the code in some of the core tilde classes like osc~ and phasor~ to optimize their performance. Those optimizations matter even if you compile her version of Pd to have a _single_ precision t_float. (I.e., with single-precision it will still outperform Pd Vanilla in her tests.)
That's a different issue than what happens when you run Pd on a 64-bit architecture. I don't understand how a 64-bit architecture would improve efficiency for math involving double-precision floats. Does it?
-Jonathan
On Sunday, February 1, 2015 11:52 PM, Alexandre Torres Porres <porres@gmail.com> wrote:
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
The only thing I have to back this assumption up is a recollection of a message by miller to the list saying that tests with the 64 bit version showed it was running faster, but I don't know anything about it, really. Still trying to learn from you. I'd also suspect that a double precision in Pd would make it much slower, but the benchmarks from Katja didn;t point this out. Seems like some future version of Pd running in full double precision is not too crazy, huh? cheers 2015-02-01 19:08 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
if you run a 32bit binary on a 64bit OS, there might be some overhead involved (bit then i really don't know much about the performance of multi-arch systems)
if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is compatible with 32bit CPUs), then it might be slightly slower than compared to a full 64bit system.
the real advantages are:
- memory access!
a 32bit application/OS uses 32bit pointers to access memory. this limits the accessible memory to 4GB (your OS might be able to manage more using PAE; but the application itself will have a maximum of 4GB.) a 64bit application uses 64bit pointers to access memory. thats much more as you are likely to ever see in your lifetime (but then: 2640k are enough" anybody?)
- modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
become a 64bit system). it seems silly to run 32bit applications on such systems (and a waste of ressources, as you need to install a 32bit version the entire runtime-environment)
also check out: http://en.wikipedia.org/wiki/64-bit_computing
fgrsam IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There are indeed two matters here. What (rather little) I know about it is this... On Mac OSX, it's easy to compare the performance of the 32 and 64 bit versions of Pd on a single 64-bit machine - and the 64 bit Pd consistently out-performs the 32-bit one by, as I recall, 15-20%.
I believe Katja's benchmarks show that it would be possible to make a Pd for Mac that not only runs "in 64 bit" (compiled fro a different instruction set than the 32-bit version, and with 64-bit pointers) but also making Pd's "float" and audio samples use double precision, and still eseitially get the same performance (i.e., there would be little penalty for increasing the precision of all numerical calculations in Pd).
This raises horrible compatibility problems, of which the worst might be that there would then have to be three formats for externs on Mac and linux. But another ugly thing is that someone could develop a patch in 64 bits which wouldn't work in 32 bits - that could cause a world of misery and confusion.
So although I'm strongly tempted to add new "double" versions of Pd for Mac and linux, I simply don't know whether the benefits really outweight the dangers.
cheers Miller
On Mon, Feb 02, 2015 at 03:49:03PM +0000, Jonathan Wilkes via Pd-list wrote:
I think you're talking about several things at once. Katja's Pd Double is essentially about changing t_float to be a double-precision floating point number. But as I understand it she also revised the code in some of the core tilde classes like osc~ and phasor~ to optimize their performance. Those optimizations matter even if you compile her version of Pd to have a _single_ precision t_float. (I.e., with single-precision it will still outperform Pd Vanilla in her tests.)
That's a different issue than what happens when you run Pd on a 64-bit architecture. I don't understand how a 64-bit architecture would improve efficiency for math involving double-precision floats. Does it?
-Jonathan
On Sunday, February 1, 2015 11:52 PM, Alexandre Torres Porres <porres@gmail.com> wrote:sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
The only thing I have to back this assumption up is a recollection of a message by miller to the list saying that tests with the 64 bit version showed it was running faster, but I don't know anything about it, really. Still trying to learn from you. I'd also suspect that a double precision in Pd would make it much slower, but the benchmarks from Katja didn;t point this out. Seems like some future version of Pd running in full double precision is not too crazy, huh? cheers 2015-02-01 19:08 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
if you run a 32bit binary on a 64bit OS, there might be some overhead involved (bit then i really don't know much about the performance of multi-arch systems)
if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is compatible with 32bit CPUs), then it might be slightly slower than compared to a full 64bit system.
the real advantages are:
- memory access!
 a 32bit application/OS uses 32bit pointers to access memory. this limits the accessible memory to 4GB (your OS might be able to manage more using PAE; but the application itself will have a maximum of 4GB.)  a 64bit application uses 64bit pointers to access memory. thats much more as you are likely to ever see in your lifetime (but then: 2640k are enough" anybody?)
- modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
become a 64bit system). it seems silly to run 32bit applications on such systems (and a waste of ressources, as you need to install a 32bit version the entire runtime-environment)
also check out: http://en.wikipedia.org/wiki/64-bit_computing
fgrsam IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Miller,What do you think is causing that performance increase on the version of Pd that is compiled for the 64-bit architecture? -Jonathan
On Monday, February 2, 2015 11:16 AM, Miller Puckette <msp@ucsd.edu> wrote:
There are indeed two matters here. What (rather little) I know about it is this... On Mac OSX, it's easy to compare the performance of the 32 and 64 bit versions of Pd on a single 64-bit machine - and the 64 bit Pd consistently out-performs the 32-bit one by, as I recall, 15-20%.
I believe Katja's benchmarks show that it would be possible to make a Pd for Mac that not only runs "in 64 bit" (compiled fro a different instruction set than the 32-bit version, and with 64-bit pointers) but also making Pd's "float" and audio samples use double precision, and still eseitially get the same performance (i.e., there would be little penalty for increasing the precision of all numerical calculations in Pd).
This raises horrible compatibility problems, of which the worst might be that there would then have to be three formats for externs on Mac and linux. But another ugly thing is that someone could develop a patch in 64 bits which wouldn't work in 32 bits - that could cause a world of misery and confusion.
So although I'm strongly tempted to add new "double" versions of Pd for Mac and linux, I simply don't know whether the benefits really outweight the dangers.
cheers Miller
On Mon, Feb 02, 2015 at 03:49:03PM +0000, Jonathan Wilkes via Pd-list wrote:
I think you're talking about several things at once. Katja's Pd Double is essentially about changing t_float to be a double-precision floating point number. But as I understand it she also revised the code in some of the core tilde classes like osc~ and phasor~ to optimize their performance. Those optimizations matter even if you compile her version of Pd to have a _single_ precision t_float. (I.e., with single-precision it will still outperform Pd Vanilla in her tests.)
That's a different issue than what happens when you run Pd on a 64-bit architecture. I don't understand how a 64-bit architecture would improve efficiency for math involving double-precision floats. Does it?
-Jonathan
On Sunday, February 1, 2015 11:52 PM, Alexandre Torres Porres porres@gmail.com wrote:
>> sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
The only thing I have to back this assumption up is a recollection of a message by miller to the list saying that tests with the 64 bit version showed it was running faster, but I don't know anything about it, really. Still trying to learn from you. I'd also suspect that a double precision in Pd would make it much slower, but the benchmarks from Katja didn;t point this out. Seems like some future version of Pd running in full double precision is not too crazy, huh? cheers 2015-02-01 19:08 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/01/2015 06:05 PM, Alexandre Torres Porres wrote:
Seems Pd runs faster if compiled to 64 bits in a 64 bit OS than if it were compiled as 32, which does makes sense. That's all?
"*no : pd compiled for 64 bit system will not run on 32 bit sytem, and it will not load 32 bit externals.*"
sure, but it still runs faster if compiled to 64 bits in a 64 bit OS, right?
why?
if you run a 32bit binary on a 64bit OS, there might be some overhead involved (bit then i really don't know much about the performance of multi-arch systems)
if you run a 32bit binary on a 32bit OS on a 64bit CPU (x86_64, which is compatible with 32bit CPUs), then it might be slightly slower than compared to a full 64bit system.
the real advantages are:
- memory access!
a 32bit application/OS uses 32bit pointers to access memory. this limits the accessible memory to 4GB (your OS might be able to manage more using PAE; but the application itself will have a maximum of 4GB.) a 64bit application uses 64bit pointers to access memory. thats much more as you are likely to ever see in your lifetime (but then: 2640k are enough" anybody?)
- modern OSs are 64bit (even the not-so-modern w32[sic!] has started to
become a 64bit system). it seems silly to run 32bit applications on such systems (and a waste of ressources, as you need to install a 32bit version the entire runtime-environment)
also check out: http://en.wikipedia.org/wiki/64-bit_computing
fgrsam IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
What I've heard is that the 64-bit instruction set has wider bit fields for specifying registers, so that you can have many more of them. (The 386 had two or three I think; the 64 bit machines have dozens, depending how you count.) So one saves steps reading and writing to/from memory.
OTOH, since all pointers have to be 64 bits, one uses more memory as a whole, perhaps by a factor of 1.5 or so - I don't see why, given that memory is "the main bottleneck" most of the time, this could possibly be consistent with 64-bit architectures being faster. So basically I don't understand what's really going on.
cheers Miller
On Mon, Feb 02, 2015 at 04:25:18PM +0000, Jonathan Wilkes wrote:
Hi Miller,What do you think is causing that performance increase on the version of Pd that is compiled for the 64-bit architecture? -Jonathan
One other question: would you accept patches for Pd Vanilla that make it _possible_ to compile with t_float at double-precision (something Pd Vanilla cannot currently do)? That would give the Pd Vanilla user the option to compile to double-precision if they wish, which IIUC is the whole point of t_float in the first place. (Plus Vanilla users would get the small performance increase in the relevant tilde classes.)
You'd still compile, distribute, and support Vanilla for t_float at single-precision. Same for external developers.
-Jonathan On Monday, February 2, 2015 11:49 AM, Miller Puckette msp@ucsd.edu wrote:
What I've heard is that the 64-bit instruction set has wider bit fields for specifying registers, so that you can have many more of them. (The 386 had two or three I think; the 64 bit machines have dozens, depending how you count.) So one saves steps reading and writing to/from memory.
OTOH, since all pointers have to be 64 bits, one uses more memory as a whole, perhaps by a factor of 1.5 or so - I don't see why, given that memory is "the main bottleneck" most of the time, this could possibly be consistent with 64-bit architectures being faster. So basically I don't understand what's really going on.
cheers Miller
On Mon, Feb 02, 2015 at 04:25:18PM +0000, Jonathan Wilkes wrote:
Hi Miller,What do you think is causing that performance increase on the version of Pd that is compiled for the 64-bit architecture? -Jonathan
More than that - I'm hoping to look at Katja's version and adopt the changes, whether or not there turns out to be a set of formatted diffs available anywhere...
cheers M
On Mon, Feb 02, 2015 at 06:34:54PM +0000, Jonathan Wilkes via Pd-list wrote:
One other question: would you accept patches for Pd Vanilla that make it _possible_ to compile with t_float at double-precision (something Pd Vanilla cannot currently do)? That would give the Pd Vanilla user the option to compile to double-precision if they wish, which IIUC is the whole point of t_float in the first place. (Plus Vanilla users would get the small performance increase in the relevant tilde classes.)
You'd still compile, distribute, and support Vanilla for t_float at single-precision. Same for external developers.
-Jonathan On Monday, February 2, 2015 11:49 AM, Miller Puckette msp@ucsd.edu wrote:
What I've heard is that the 64-bit instruction set has wider bit fields for specifying registers, so that you can have many more of them. (The 386 had two or three I think; the 64 bit machines have dozens, depending how you count.) So one saves steps reading and writing to/from memory.
OTOH, since all pointers have to be 64 bits, one uses more memory as a whole, perhaps by a factor of 1.5 or so - I don't see why, given that memory is "the main bottleneck" most of the time, this could possibly be consistent with 64-bit architectures being faster. So basically I don't understand what's really going on.
cheers Miller
On Mon, Feb 02, 2015 at 04:25:18PM +0000, Jonathan Wilkes wrote:
Hi Miller,What do you think is causing that performance increase on the version of Pd that is compiled for the 64-bit architecture? -Jonathan
Â
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sounds like a good plan to me. -Jonathan
On Monday, February 2, 2015 1:58 PM, Miller Puckette <msp@ucsd.edu> wrote:
More than that - I'm hoping to look at Katja's version and adopt the changes, whether or not there turns out to be a set of formatted diffs available anywhere...
cheers M
On Mon, Feb 02, 2015 at 06:34:54PM +0000, Jonathan Wilkes via Pd-list wrote:
One other question: would you accept patches for Pd Vanilla that make it _possible_ to compile with t_float at double-precision (something Pd Vanilla cannot currently do)? That would give the Pd Vanilla user the option to compile to double-precision if they wish, which IIUC is the whole point of t_float in the first place. (Plus Vanilla users would get the small performance increase in the relevant tilde classes.)
You'd still compile, distribute, and support Vanilla for t_float at single-precision. Same for external developers.
-Jonathan On Monday, February 2, 2015 11:49 AM, Miller Puckette msp@ucsd.edu wrote:
What I've heard is that the 64-bit instruction set has wider bit fields for specifying registers, so that you can have many more of them. (The 386 had two or three I think; the 64 bit machines have dozens, depending how you count.) So one saves steps reading and writing to/from memory.
OTOH, since all pointers have to be 64 bits, one uses more memory as a whole, perhaps by a factor of 1.5 or so - I don't see why, given that memory is "the main bottleneck" most of the time, this could possibly be consistent with 64-bit architectures being faster. So basically I don't understand what's really going on.
cheers Miller
On Mon, Feb 02, 2015 at 04:25:18PM +0000, Jonathan Wilkes wrote:
Hi Miller,What do you think is causing that performance increase on the version of Pd that is compiled for the 64-bit architecture? -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
A set of 'double precision' diffs is on Pd-double github as the patch files were applied in a single commit on vanilla 0.43 (in 2011):
https://github.com/pd-projects/pd-double/commit/982ad1aa1a82b9bcd29c5b6a6e6b...
The patch set may need some modifications and additions to make it work for Pd 0.46, but more important, the following was still left to be done:
- graceful handling of binary incompatibility between core <>
externals of different precision
make it work for Windows too
type-specify t_float literals consistently throughout the code
My focus was to make Pd work in double precision builds while at the same time preserving all functionality and performance in single precision builds. For Linux and OSX on Intel this was tested OK. Nowadays one would include ARM platforms in the tests. Unlike Intel, ARM isn't so fond of doubles, therefore it's extra important to type-specify all t_float literals to avoid unintended conversions.
Regarding binary incompatibility between builds of different precision, this is a serious problem which can't be resolved under the quick-and-easy approach of specifying t_float at compile time. I would therefore suggest that double precision binaries should not be distributed until we have at least some method to prevent loading externals of the wrong precision. In the meantime, the curious could build double precision from source for evaluation, at their own risk.
Whether the benefits of double precision will outweigh the dangers, is impossible to say because the benefits vary with the purpose someone has for using Pd. When working on Pd-double in 2011 I was interested in 'scientific' applications of Pd like impulse response measurement, where double precision is crucial in some calculations. My current focus is more on live performance and I've never felt a need for doubles in this realm. Still I would be happy to help out with doublyfication of Pd 0.46. Shouldn't we have freedom of precision?
By the way here's a video about precision in Pd, with the latter part showing double precision in action:
https://www.youtube.com/watch?v=93632nc8LVs
Katja
On Mon, Feb 2, 2015 at 7:58 PM, Miller Puckette msp@ucsd.edu wrote:
More than that - I'm hoping to look at Katja's version and adopt the changes, whether or not there turns out to be a set of formatted diffs available anywhere...
cheers M
On Mon, Feb 02, 2015 at 06:34:54PM +0000, Jonathan Wilkes via Pd-list wrote:
One other question: would you accept patches for Pd Vanilla that make it _possible_ to compile with t_float at double-precision (something Pd Vanilla cannot currently do)? That would give the Pd Vanilla user the option to compile to double-precision if they wish, which IIUC is the whole point of t_float in the first place. (Plus Vanilla users would get the small performance increase in the relevant tilde classes.)
The diffs are helpful - I would probably want to go and re-do all the edits by hand to be sure I understand everything. A couple of things probably will need tweaking to get it all up to date too.
The binary compatibility problem needs careful thought. I think the ugliest issue is that for Macintosh, the fat binary format can't very easily hold two versions of the same extern, same architecture, but different float types - so there would have to be d_fat with 32-bit and IA64, 32-bit-float versions (as now) and yet another extent (.d_double?) to hold the 64-bit-double version in a separate file. Yuck....
But all doable.
cheers Miller
On Tue, Feb 03, 2015 at 06:16:39PM +0100, katja wrote:
A set of 'double precision' diffs is on Pd-double github as the patch files were applied in a single commit on vanilla 0.43 (in 2011):
https://github.com/pd-projects/pd-double/commit/982ad1aa1a82b9bcd29c5b6a6e6b...
The patch set may need some modifications and additions to make it work for Pd 0.46, but more important, the following was still left to be done:
- graceful handling of binary incompatibility between core <>
externals of different precision
make it work for Windows too
type-specify t_float literals consistently throughout the code
My focus was to make Pd work in double precision builds while at the same time preserving all functionality and performance in single precision builds. For Linux and OSX on Intel this was tested OK. Nowadays one would include ARM platforms in the tests. Unlike Intel, ARM isn't so fond of doubles, therefore it's extra important to type-specify all t_float literals to avoid unintended conversions.
Regarding binary incompatibility between builds of different precision, this is a serious problem which can't be resolved under the quick-and-easy approach of specifying t_float at compile time. I would therefore suggest that double precision binaries should not be distributed until we have at least some method to prevent loading externals of the wrong precision. In the meantime, the curious could build double precision from source for evaluation, at their own risk.
Whether the benefits of double precision will outweigh the dangers, is impossible to say because the benefits vary with the purpose someone has for using Pd. When working on Pd-double in 2011 I was interested in 'scientific' applications of Pd like impulse response measurement, where double precision is crucial in some calculations. My current focus is more on live performance and I've never felt a need for doubles in this realm. Still I would be happy to help out with doublyfication of Pd 0.46. Shouldn't we have freedom of precision?
By the way here's a video about precision in Pd, with the latter part showing double precision in action:
https://www.youtube.com/watch?v=93632nc8LVs
Katja
On Mon, Feb 2, 2015 at 7:58 PM, Miller Puckette msp@ucsd.edu wrote:
More than that - I'm hoping to look at Katja's version and adopt the changes, whether or not there turns out to be a set of formatted diffs available anywhere...
cheers M
On Mon, Feb 02, 2015 at 06:34:54PM +0000, Jonathan Wilkes via Pd-list wrote:
One other question: would you accept patches for Pd Vanilla that make it _possible_ to compile with t_float at double-precision (something Pd Vanilla cannot currently do)? That would give the Pd Vanilla user the option to compile to double-precision if they wish, which IIUC is the whole point of t_float in the first place. (Plus Vanilla users would get the small performance increase in the relevant tilde classes.)
Hi,
On 03/02/15 18:37, Miller Puckette wrote:
The binary compatibility problem needs careful thought. I think the ugliest issue is that for Macintosh, the fat binary format can't very easily hold two versions of the same extern, same architecture, but different float types - so there would have to be d_fat with 32-bit and IA64, 32-bit-float versions (as now) and yet another extent (.d_double?) to hold the 64-bit-double version in a separate file. Yuck....
I guess extra extensions would be needed for the other OS too.
What about making it mandatory for double precision externals to define a specially named symbol? Then Pd could check for the existence (and value if it exists) of this symbol before deciding whether it's safe to run the setup function. If the symbol doesn't exist, Pd should assume it's using 32bit float, and if Pd is using 64bit float it should refuse to load it.
Something like this for external sources (untested):
----8<---- #include "m_pd.h"
#ifdef PD_DOUBLE extern int myextern_fp = 64; #else extern int myextern_fp = 32; #endif
extern void myextern_setup(void) { ... } ----8<----
with approriate C preprocessor macro magic in "m_pd.h", it could simplify to something more like this:
----8<---- #inlude "m_pd.h"
PD_DECLARE_FP(myextern)
extern void myextern_setup(void) { ... } ----8<----
Which is just one extra line for each setup function, and makes it easy to see in the source that an external has been adapted to be compatible with both pd-float and pd-double.
On Tue, Feb 03, 2015 at 06:16:39PM +0100, katja wrote:
By the way here's a video about precision in Pd, with the latter part showing double precision in action:
Very nice!
Claude
Le 29/01/2015 18:36, Alexandre Torres Porres a écrit :
more that 7 digit but less than 8 digits
...
so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3")
I don't get it. More than 7 decimal digits but less than 8 decimal digits?
yes about 7.22 as Claude pointed : log(2^24-1) 2^24-1 is the max value coded in 23bit, log(x) compute the number of digit of a number. unfortunately, the result is not an integer.
How does that work? In practice, is it 7 or 8?
in practice, number are rounded to the closest value that can be represented in this format.
forget about the comma : the max number that can be represented without exponent is 2^24-1 (max value of 23bits) i.e 16777215 in this case, 8 correct digits if you add 1, it should be 16777216, but that need 24 bit, and it's not possible in a float. so it's noted 1677722 * 10^1 ...
In the example we see that 4/3 == 1.33333333 (8 "3") - so it's 8 decimal digits...
better to say a 9 digit number.
I have a work around using expr. Just put the number in parenthesis.
Try [expr 4./3 == (1.33333333)] (8 "3")
but the thing is that this is also true - [expr 4./3 == (1.3333333)] - also equal to 7 "3"
7 "3", mean 8 digits number: max precision of a float-> no surprise.
cheers c
cheers
2015-01-29 14:58 GMT-02:00 Cyrille Henry <ch@chnry.net mailto:ch@chnry.net>:
hello, ok, claude was faster to answer, but since i already write my mail, i send it anyway... pd internal resolution is float32. (i.e, 23 bit, so a bit less than 17 millions, i.e more that 7 digit but less than 8 digits) pd graphical representation is 6 digits so, 4/3 =! 1.33333 but 4/3 == 1.33333333 (8 "3") even if both are represented with the same number of 3... this is a generic problem of computer float. the only odd thing concerning pd is that number are also saved with 6 digit. (so precision can be lost when a patch is saved) try the attachment patch. then save the patch, and open it back, and see that precision is lost. (I have to modifies the patch as text file to have this behaviors, but you can also have the save precision when creating an object... until you save/load the patch) you can also have a look on the top right of the patch: a weird effect of float precision... cheers c Le 29/01/2015 17:17, Alexandre Torres Porres a écrit : Well, thanks everyone. And now for some related issues. Pd can only represent up to 6 significant digits, so they say. For example, in a message, you can have a number with up to 5 decimal places, like: -5.29314e+12 but it does have a better internal resolution, if you compare 4 / 3 to 1.33333 you'll see 4 / 3 is higher ( try [expr 4./3 > 1.33333] and check). So, what's this internal resolution? And why can't you have the same resolution in a message? thanks 2015-01-28 16:06 GMT-02:00 Martin Peach <chakekatzil@gmail.com <mailto:chakekatzil@gmail.com> <mailto:chakekatzil@gmail.com <mailto:chakekatzil@gmail.com>>__>: On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> wrote: Le 28/01/2015 17:47, Alexandre Torres Porres a écrit : > it's a limitation of 32 bit float I thought so, but same happens when I use the new Pd Vanilla 64 bits... this mean that it's compiled for 64 bit CPU, not that float are store on 64 bits Also last time I checked, Pd saves floats by first printing them to 6 digit precision, so they have even less range than a 'float' type. You could use an object made with pdlua to manipulate large floating-point numbers, as there is no(?) limit to the size of a float in lua. Martin _________________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/__listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
-
Alexandre Torres Porres -
Claude Heiland-Allen -
Cyrille Henry -
IOhannes m zmölnig -
Jonathan Wilkes -
katja -
Martin Peach -
Miller Puckette -
patrice colet -
Rivoire David