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