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

[katja]

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

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. A non-decimal ASCII format instead, would make
existing patches unreadable.

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.

Katja