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