[PD] more about float limitation
Alexandre Torres Porres
porres at gmail.com
Sun Feb 1 18:05:06 CET 2015
>
> 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 at 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 at gmail.com <mailto:
>> chakekatzil at 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 at gmail.com <mailto:porres at 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 at gmail.com
>> <mailto:chakekatzil at 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 at gmail.com <mailto: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
>> <mailto: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 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 at gmail.com <mailto:chakekatzil at gmail.com> <mailto:
>> 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> <mailto: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>
>> <mailto: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 <
>> http://lists.puredata.info/listinfo/pd-list>
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150201/c562f828/attachment.html>
More information about the Pd-list
mailing list