[PD] (breaking symbols) was Re: find a list of numbers in a text file
Hans-Christoph Steiner
hans at at.or.at
Sun Sep 11 01:27:17 CEST 2011
On Sep 10, 2011, at 3:01 PM, Mathieu Bouchard wrote:
> On Tue, 6 Sep 2011, martin.peach at sympatico.ca wrote:
>
>> The disaster would be if Pd tried to guess what the user intends
>> based on some general idea of what Pd is 'for'. For instance I've
>> been working on an xbee external where I need to specify numbers
>> like 0x0a060123 for the remote address. I do that by interpreting
>> the symbol as a 64-bit integer internally but I would not expect
>> any other external to do this unless it needs to.
>
> The xbee external uses a function that shows that it expects to read
> a symbol where you gave it the 0x0a060123 symbol. Therefore Pd would
> not do any implicit conversion, because it's being requested to give
> a symbol atom as a symbol.
>
> However, if ever 0x0a060123 is to be parsed as a float (that's a
> different issue, actually), then xbee would be getting 168165667
> rounded to 168165664 and then it would be implicitly converted to
> gensym("168165664"). But that's a parser difference, and not a
> difference of implicit type conversions. The solution would be to
> backslash it or doublequote it.
>
> Perhaps it is confusing because we are talking about several related
> propositions at once :
>
> * implicit conversion to replace type mismatch errors
>
> * getting atom_string to write backslashes to files and to
> messageboxes,
> to match what the parser can already do
>
> * modifying both the parser and atom_string, to change the meaning of
> doublequotes
>
> and AFAIK, no-one talked about adding support for aztec numerals or
> parsing «half-dozen» as meaning {A_FLOAT,6}.
I'm thinking now to first try a more python style approach, and have
something like str() and float() rather than automatic conversions. I
implemented this in two objects that are meant to replace [symbol] and
[float], [symbol2] and [float2]. Here's the library:
https://github.com/pd-projects/newtype
There is definitely a universally valid way of converting a symbol to
a float because Pd converts strings to floats both when receiving
floats from the GUI and when reading floats from the .pd file. I
implemented this in a test file and I think it matches Pd's
implementation in every case that I could think of:
https://github.com/pd-projects/newtype/blob/master/test_symbol2float.c
Converting from a float to a symbol in the code is simple, that's just
sprintf(buf, "%g"), its in the code a lot, like in atom_string() and
atom_getsym().
As for all the \ cases, I don't really know how to handle \n, \t, etc.
yet. As for unicode chars, I think we should just support unicode
completely then people put the actual character rather than the \0x234
form. We have full unicode support for a lot of left-to-right
alphabets. Things like Chinese, arabic, etc. have issues with box
sizing, but the characters show up correctly.
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
More information about the Pd-list
mailing list