Martin Peach chakekatzil at gmail.com
Thu Jan 29 18:47:49 CET 2015

```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 at 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 at 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
>>
>> 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 at gmail.com <mailto:
>>> chakekatzil at gmail.com>>:
>>>
>>>     On Wed, Jan 28, 2015 at 12:00 PM, Cyrille Henry <ch at chnry.net
>>> <mailto:ch at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>>>     UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150129/dbe46c33/attachment.html>
-------------- next part --------------
#N canvas 270 262 895 300 10;
#X obj 135 86 lpi;
#X obj 125 112 print >>>;
#X obj 135 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X floatatom 135 159 15 0 0 0 - - -;
#X msg 154 219 3.141592653589793115997963468544185161590576171875000000000000000000000000000000000000000000000000000
;
#X obj 154 191 prepend set;
#X symbolatom 180 142 80 0 0 0 - - -;
#X text 668 142 <-symbol;
#X text 235 160 <-float;
#X text 155 64 bang for pi;
#X text 196 112 <- post;
#X connect 0 0 1 0;
#X connect 0 0 3 0;
#X connect 0 1 5 0;
#X connect 0 1 6 0;
#X connect 2 0 0 0;
#X connect 5 0 4 0;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lpi.pd_lua
Type: application/octet-stream
Size: 580 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150129/dbe46c33/attachment.obj>
```