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 > > >