[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