On Mon, Apr 9, 2012 at 6:14 PM, Hans-Christoph Steiner hans@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