Just because we are at it.
On w32 I can have long tables but I cant get values beyond 16777216 using [tabread].
Also a simple counter stops there, printing with [makefilename %d]:
print: symbol 16777213
print: symbol 16777214
print: symbol 16777215
print: symbol 16777216
print: symbol 16777216
print: symbol 16777216
print: symbol 16777216
print: symbol 16777216
Is this also happening on 64bit Pd/OS?
Mensaje telepatico asistido por maquinas.
From: Pd-list <pd-list-bounces@lists.iem.at> on behalf of IOhannes m zmölnig <zmoelnig@iem.at>
Sent: Monday, February 27, 2017 10:13 PM
To: pd-list@lists.iem.at
Subject: Re: [PD] soundfiler alternative?
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
>>
>> well, [table] stores the samples as floating point (taking 4 bytes
>> per
>> sample; and 8 byte on 64bit systems)
>
> Why is that? And why does it only apply to arrays and not to all other
> number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things,
including numbers and data structures.
since data-structures are stored by reference, a data element in the
table must be able to hold a (void*) pointer, which - on 64bit systems -
takes 8 bytes.
the actual numbers stored in these fields are still only single
precision numbers.
> Seems like there
> are still some advantages in use Pd on 32-bit architectures.
which?
>
> Unfortunately, dealing with largish tables has its complications two
> which I thought is exactly because everything is stored as 32bit float,
> even on 64bit systems.
well, this depends on what you actually do with the tables.
afaiu, the OP was happy with the using tables, only the data-loading was
causing dropouts.
so the problems with data precision do not apply here.
fgmdasr
IOhannes