Hello all,
I want to develop a serie of externals that allow to use tables bigger than 2^24 points. After a few missed attempt (redefining PDFLOATTYPE, using double inside the objects...) i think i have managed two working externals [tabread_double] and [tabwrite_double] that use two float to point an integer : n = f1 + 2^24*f2.
Before going further (tabread~, tabread4,...) I wanted to know if someone has already done something similar or if you have advices on names and behavior. I've chosen to have compatibility with existing object, simply adding one inlet on the right that set f2.
If it's the first serie of external for that i'll try to add that on the svn in a few weeks. best, n
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 14:20, Nicolas Montgermont wrote:
Before going further (tabread~, tabread4,...) I wanted to know if someone has already done something similar or if you have advices on names and behavior.
i think thomas musil did something like a "double precision table library" once, using the same approach. i simultaneously worked on the problem with the totally different approach of making Pd "double precision" aware.
thomas is on holidays right now (won't be back before august), and i would be interested in what failed to work when using PD_FLOATTYPE=double.
fgmasdr IOhannes
Le 13/07/11 14:29, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 14:20, Nicolas Montgermont wrote:
Before going further (tabread~, tabread4,...) I wanted to know if someone has already done something similar or if you have advices on names and behavior.
i think thomas musil did something like a "double precision table library" once, using the same approach.
can i find it on the svn?
i simultaneously worked on the problem with the totally different approach of making Pd "double precision" aware.
thomas is on holidays right now (won't be back before august), and i would be interested in what failed to work when using PD_FLOATTYPE=double.
I use #define PD_FLOATTYPE double before including m_pd.h in an external.
it compiles but it occurred to me that i have to recompile Pd with the same definition to test it, that was not what i searched cause i prefer to use "standard" pd and to add externals.
with the [tabread_double] paradigm, it'll work regarding any floattype of the Pd used. otoh, im' not sure i can manage transparent operation keeping the precision i want, i mean building an abstraction that takes as an input a float that can be bigger than 2^24 and that automaticcaly use tabread_double or tabwrite_double the good way. Maybe i'll need to do a special + - or % / or >> << to achieve that. mmm tricky n
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 15:30, Nicolas Montgermont wrote:
Le 13/07/11 14:29, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 14:20, Nicolas Montgermont wrote:
Before going further (tabread~, tabread4,...) I wanted to know if someone has already done something similar or if you have advices on names and behavior.
i think thomas musil did something like a "double precision table library" once, using the same approach.
can i find it on the svn?
i simultaneously worked on the problem with the totally different approach of making Pd "double precision" aware.
thomas is on holidays right now (won't be back before august), and i would be interested in what failed to work when using PD_FLOATTYPE=double.
I use #define PD_FLOATTYPE double before including m_pd.h in an external.
it compiles but it occurred to me that i have to recompile Pd with the same definition to test it,
yes, you need a Pd that is compiled with "PD_FLOATTYPE double"
that was not what i searched cause i prefer to use "standard" pd and to add externals.
the idea is to make "double" the standard for Pd in the future. if nobody spents time for that it will never happen.
with the [tabread_double] paradigm, it'll work regarding any floattype of the Pd used. otoh, im' not sure i can manage transparent operation keeping the precision i want, i mean building an abstraction that takes as an input a float that can be bigger than 2^24 and that automaticcaly use tabread_double or tabwrite_double the good way. Maybe i'll need to do a special + - or % / or >> << to achieve that.
if you want transparent operation, than you need to make Pd "double aware", in which case it comes for free.
though it appears to me that we are talking about different things. could it be that you are talking about the "values" in the table (y-axis)? i was mainly concerned about the "indices" of the table (x-axis), where it becomes impossible to index a value sample-accurately once it is >1e9.
the reason why tables won't store very large and very small values are denormals (i think); the idea is to prevent such values from occuring in the signal chain as they would induce a performance penalty. since [table] can be easily converted to a signal, it simply prevents these values to get in. if you don't need the full range between 1e-24 and 1e+24, than you should consider scaling your values appropriately before storing them in tables.
if you are indeed talking about indices, then i would like to invite you to come here and share with me some of your yottabyte modules.
fmasdr IOhannes
Le 13/07/11 15:51, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 15:30, Nicolas Montgermont wrote:
Le 13/07/11 14:29, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 14:20, Nicolas Montgermont wrote:
Before going further (tabread~, tabread4,...) I wanted to know if someone has already done something similar or if you have advices on names and behavior.
i think thomas musil did something like a "double precision table library" once, using the same approach.
can i find it on the svn?
i simultaneously worked on the problem with the totally different approach of making Pd "double precision" aware.
thomas is on holidays right now (won't be back before august), and i would be interested in what failed to work when using PD_FLOATTYPE=double.
I use #define PD_FLOATTYPE double before including m_pd.h in an external.
it compiles but it occurred to me that i have to recompile Pd with the same definition to test it,
yes, you need a Pd that is compiled with "PD_FLOATTYPE double"
that was not what i searched cause i prefer to use "standard" pd and to add externals.
the idea is to make "double" the standard for Pd in the future.
That is definitely a good thing :)
if nobody spents time for that it will never happen.
That is sure. The point is that this problem has happen to me very often the past few months and I was searching a workaround and not a definitive solution. I think this is a major limitation for many people and so i tried to find a way to have this possible. I am not aware of all the developments of the 0.43 version is this planned to be include soon? let me know if i can help (mainly compiling on osx)
with the [tabread_double] paradigm, it'll work regarding any floattype of the Pd used. otoh, im' not sure i can manage transparent operation keeping the precision i want, i mean building an abstraction that takes as an input a float that can be bigger than 2^24 and that automaticcaly use tabread_double or tabwrite_double the good way. Maybe i'll need to do a special + - or % / or>> << to achieve that.
i finally manage something that is a dedicated counter for double precision. it can work everywhere. see attached.
if you want transparent operation, than you need to make Pd "double aware", in which case it comes for free.
...
if you are indeed talking about indices, then i would like to invite you to come here and share with me some of your yottabyte modules.
Not sure what you want. The code for this double float inlets solution is not in the svn, cause i have not worked on it for a while and i'm afraid of breaking the autobuilds. but you can find it attached (standard makefile) all is about using "long" instead of "int" if you want the code i tested with PD_FLOATTYPE double it was simply the code of the float object with this definition as a starting line. n
On Wed, Jul 13, 2011 at 3:51 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
the idea is to make "double" the standard for Pd in the future. if nobody spents time for that it will never happen.
I'd like to help with this if I can (with only fragmentary knowledge of Pd core code I must say). I recall looking at the options to compile Pd with type double, but running into union tabfudge and UNITBIT32 which are used by rather central Pd objects like [osc~] and [phasor~]. I did not fully grasp the working of this clever type punning hack, but assumed it cannot be translated to type double rightaway. Is it true that this trick is crucial for computational speed of [osc~] & co, and must an equivalent routine still be developed (if possible at all)? Or are there other, more important bottlenecks to solve?
Katja
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-13 19:31, katja wrote:
On Wed, Jul 13, 2011 at 3:51 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
the idea is to make "double" the standard for Pd in the future. if nobody spents time for that it will never happen.
I'd like to help with this if I can (with only fragmentary knowledge of Pd core code I must say). I recall looking at the options to compile Pd with type double, but running into union tabfudge and UNITBIT32 which are used by rather central Pd objects like [osc~] and [phasor~]. I did not fully grasp the working of this clever type punning hack, but assumed it cannot be translated to type double rightaway. Is it true that this trick is crucial for computational speed of [osc~] & co, and must an equivalent routine still be developed (if possible at all)? Or are there other, more important bottlenecks to solve?
i think this is the main showstopper right now. the type punning tricks used to be crucial (i assume), but nowadays the speed gain should be rather low (at least according to some tests we did).
i would suggest to come up with a generic implementatin of those objects, do benchmarking and if needed (and possible) provide an alternative optimized solution (in addition to the generic one)
fgmadsr IOhannes
On Wed, Jul 13, 2011 at 7:38 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
i think this is the main showstopper right now. the type punning tricks used to be crucial (i assume), but nowadays the speed gain should be rather low (at least according to some tests we
did).
A double precision Pd is high on my wishlist, and if the union tabfudge thing is the main showstopper, then it's certainly worthwhile to put effort in it. I'm often running into precision issues with Pd, not only by lack of an integer type for indexes but also in the case of signal data. In some cases I write a new external instead of a patch for this reason, which is a pity. I'll do as you say, first write and test a generic alternative with straightforward implementation, then try to optimize.
Katja