http://artengine.ca/pureunity/
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/pureunity/
A very interesting and very useful project. Especially the part:
"However sometimes we want to make sure that our math is accurate enough. Many algorithms are data-recursive: each computation uses previous results. Many of those algorithms have chaotic and/or unstable behaviours, which means that the inaccuracies may skyrocket instead of fading out."
is very handy sometimes.
For example the physical modelling patches I did (as a-*.pd in svn://footils.org/pd/msd/trunk/phys) have to use this kind of recursive operations a lot and the current implementation becomes unstable much faster than pmpd or msd do. I would really like to find out why. Do I assume correctly, that Pd is using the same precision floats (32-bit floating point) in messages as they would be used, when I declare something t_float in a C-external? Somehow I have the impression, that message-float-computations in Pd aren't as precise as t_float computations in externals. However I cannot prove it yet ...
Ciao
On Sun, 1 Jan 2006, Frank Barknecht wrote:
For example the physical modelling patches I did (as a-*.pd in svn://footils.org/pd/msd/trunk/phys) have to use this kind of recursive operations a lot and the current implementation becomes unstable much faster than pmpd or msd do. I would really like to find out why.
It depends on how you solve the differential equations. In discrete methods, you don't make dx (also known as h) tend towards 0, and so you have to pick a value of dx, and apparently the sign of dx matters in the stability, but I don't remember why.
Do I assume correctly, that Pd is using the same precision floats (32-bit floating point) in messages as they would be used, when I declare something t_float in a C-external?
Yes, it's all the same 1+23+8=32 bits, 23 being the size of the mantissa, guaranteeing a rounding by at most pow(2,-24) times the value.
Somehow I have the impression, that message-float-computations in Pd aren't as precise as t_float computations in externals. However I cannot prove it yet ...
There is no difference like that. However, in Pd, there's a big difference between the precision of binary floating-point and decimal floating-point, and this affects [print], [netsend], the *.pd format, etc. You may lose 5 or 6 bits by converting to decimal floating-point.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 1 Jan 2006, Frank Barknecht wrote:
For example the physical modelling patches I did (as a-*.pd in svn://footils.org/pd/msd/trunk/phys) have to use this kind of recursive operations a lot and the current implementation becomes unstable much faster than pmpd or msd do. I would really like to find out why.
It depends on how you solve the differential equations. In discrete methods, you don't make dx (also known as h) tend towards 0, and so you have to pick a value of dx, and apparently the sign of dx matters in the stability, but I don't remember why.
I'm actually using the same algorithm as pmpd and both my patches and pmpd assume h==1 to simplify calculations (the "real" h or delta-t(ime) actually is specified from outside using a driving [metro]). Still pmpd seems to become unstable much later than my system. It doesn't matter too much, because in practice, one would of course use pmpd and not an abstractions based system for this taks, still it makes me wonder, where the cause of this error is.
Somehow I have the impression, that message-float-computations in Pd aren't as precise as t_float computations in externals. However I cannot prove it yet ...
There is no difference like that. However, in Pd, there's a big difference between the precision of binary floating-point and decimal floating-point, and this affects [print], [netsend], the *.pd format, etc. You may lose 5 or 6 bits by converting to decimal floating-point.
Is filtering out a float from a list with a message as [$1( also such a conversion, that looses precision?
Ciao
On Sun, 1 Jan 2006, Frank Barknecht wrote:
I'm actually using the same algorithm as pmpd and both my patches and pmpd assume h==1 to simplify calculations (the "real" h or delta-t(ime) actually is specified from outside using a driving [metro]).
Then I dunno... what if you try h==-1 ?
Is filtering out a float from a list with a message as [$1( also such a conversion, that looses precision?
No it doesn't, because $1 is then a A_DOLLAR, which gets evaluated directly to the value of the first argument in the t_canvasenvironment. It doesn't need to go through binbuf_eval again, fortunately...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada