[PD] why does PD round numbers? (in tables, in messageboxes, etc)

[IOhannes m zmölnig]

On 04/09/12 20:06, katja wrote:
> On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steiner<hans at at.or.at>  wrote:
>
>> We could still store numbers as ASCII and not lose precision.  For example, we could store the actual bits as base64 or hex.  Let's say it'll store 64-bits to have one number format for both single and double precision.  Using base64, there would have to be 32 characters to support 64 bits.

yes; but a binary format is much easier to implement. it takes exactly 8 
bytes to represent any double precision number. always.

>>
>> While we are at it, it would be good to make the comments totally unparsed, so that things like +14322342342 (phone numbers) or 1. (numbered lists) don't get converted by Pd's type system.  Comments do not need to be parsed into types, they should just be treated as UTF-8 text.

oh yes.

>>
>
> For a storage format to accommodate single and double precision
> numbers, I would suggest %.14lg. This is a generous format - even if
> it truncates some bits from double precision it is sufficient for all
> practical purposes in Pd. This is already tested in a way. I used the
> format in Pd-double, and patches saved from Pd-double load without
> problem in regular Pd.

Pd's text2atom converter is rather generous and accepts loads of things, 
including higher precision numbers and symbols with spaces.
it is the atom2text converter that makes all the trouble.

> A non-decimal ASCII format instead, would make
> existing patches unreadable.

right; i think this is also the reason why Pd doesn't do any binary 
storage/transmission: it makes debugging so easy if you can actually 
understand what is going on without an assembler book besides the keyboard.

>
> Not sure though how to separate code for representation and storage.
> In the IEM gui's there is a separate line doing the conversion for
> representation, while storage is achieved via binbuf_addv(), which in
> the end calls atom_text() which does the conversion. But for object
> boxes and Pd's built-in numbox, I could not identify separate
> conversion routines for representation and storage. Changing the
> format in atom_text() did it all, if I remember well. With format
> %.14lg, that would make a problem for object boxes in the single
> precision case.

i think a good start would be to let pd-gui decide how to properly 
display a number.


the major drawback i see right now is, that raising the number of bytes 
used to transmit a single number will make table updates even more costy 
than they already are.

so i still think that a way to transmit/save/load numbers in binary form 
would be the easiest way; something like "d:0x400921fb54442d18" (at a 
pre-defined endianness for all platforms) rather than "3.1415926".

mfgasrd
IOhannes