[PD-dev] Tabread/write on array bigger than 16777216 points

[IOhannes m zmoelnig]

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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dotsACgkQkX2Xpv6ydvTWowCeMropR81hvv4g5nm0YpE7MWXu
bJcAoMo1GpTHB5rYgrgImYW0MbyvTx4d
=Q0Eo
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110713/9ea649eb/attachment.bin>