[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:


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:


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   

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.



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