> > 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 <[email protected]>: > > > 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 <[email protected] <mailto: >> [email protected]>>: >> >> 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 < >> [email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> >> 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 < >> [email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>>: >> >> 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 < >> [email protected] <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>__>: >> >> On Wed, Jan 28, 2015 at 12:00 PM, Cyrille >> Henry <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto: >> [email protected]>>> 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 >> >> ______________________________ >> ___________________ >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/__listinfo/pd-list < >> http://lists.puredata.info/listinfo/pd-list> >> >> >> >> >> >> >> >>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
