[PD] no pd?? WTF ????

[João Pais]

>> and you're only talking about the aesthetical/workflow features. to  
>> bring up
>> a subject that I am paying attention only now, try out to see how high  
>> you go
>> with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in  
>> max5
>> (the coming up of Pd double precision will help this, but it's a work  
>> Katja
>> is doing alone).
>
> There's a big difference between decimal precision as printed on screen
> and in text files and [netsend], and binary precision used in most other
> situations.
>
> Pd is able to think of numbers bigger than a million, but won't print a
> million plus one. It is able to if you force it to, using less than ideal
> tools such as [makefilename] that creates one symbol each time, or
> [#sprintf] that makes you a float list of ascii codes.
>
> Neither binary nor decimal representation is more precise than the other,
> it's just that their precision never matches exactly. 20 bits is slightly
> less than 6 decimals, whereas 16 decimals is slightly more than 53 bits.
> Thus you can only preserve precision by using slightly too many digits,
> otherwise you'll have too few.
>
> I don't know what max5 does, but the only practical float sizes in the
> main processor are 24 bits and 53 bits. (this assumes that the most
> significant bit is not recorded because it's always one)
>
>> Which means, for example, in max you have more resolution than Pd to  
>> control
>> the playback of large arrays with precision (up to 2147483647,
>
> that's 31 bits. From 0 to 2147483647, you have 2147483648 numbers, which
> is pow(2,31) exactly (aka 1<<31), if it didn't overflow. the 32nd bit is
> the sign. That's using integers. I bet that you can't have integer
> signals. Can you ? Otherwise, you're stuck at the same limit as Pd...
> though Pd42 does offer a workaround as a 2nd inlet in [tabread~].
>
> Does Max offer that 2nd inlet ?

don't know, can't even find out which object corresponds to tabread4~


> BTW : in floats, pd can exactly represent powers of two up to pow(2,127).
> Powers of two are represented exactly in binary. They just won't be
> printed exactly in decimal by default, but [makefilename %f] can print
> «symbol 170141183460469231731687303715884105728.000000» accurately. The
> float format stops working just before getting to pow(2,128). But for
> [tabread~] you need contiguous integers, and that stops at 16777216, and
> for [tabread4~] you need at least some fractions to make it useful at all
> (contiguous sixteenths stop at 1048576, for example). So, your power-of-2
> example is misleading in another way.

I already have an abstraction in pd to automatically set the offset to  
play segments with tabread4~. But if I need e.g. to play indices 100000000  
to 100000111, which are read from an array, and then rescaled in the  
meantime, how is it possible to keep precision using symbol-tricks? The  
2nd inlet doesn't help me much, if the numbers going inside are still  
wrong.

Or, a concrete question: my table has 15312000 samples (5m19s at 48K). You  
mean that if I want to play from index 15311000 to 15312019, (these values  
are read from a file and stored in an array, and also quantized in the  
way), the precision will be correct, just will be printed wrongly in the  
atom boxes?