From:
hans@at.or.atTo:
martin.peach@sympatico.caDate: Tue, 6 Sep 2011 15:57:32 -0400
CC:
pd-list@iem.atSubject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file
> Date: Tue, 6 Sep 2011 08:12:15 +0200
> From:
fbar@footils.org> To:
hans@at.or.at> CC:
pd-list@iem.at> Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file
>
> Hi,
>
> On Mon, Sep 05, 2011 at 02:34:30PM -0400, Hans-Christoph Steiner wrote:
> >
> > Then having the patch rely on the "error: float: no method for
> > 'symbol'" error that is normally generated in that case.
>
> Well, it prints an error because there *is* an error in the patch. The
> author should never have converted a float to a symbol and expect to
> still do float calculations with it.
>
Yes, I think it ought to be up to the external to implement its own symbol-to-float converter since there is no universally valid way of doing it.
The same pattern will have different meanings in different context and Pd can't be expected to know what is expected in a specific case.
Martin
That sounds like a recipe for disaster, then we end up with multiple, incompatible ways of doing this. I don't think anyone is proposing that symbols like "four" get converted to 4, but only symbols like 43, 5.22, -234, etc. Things that can be directly converted from a char* to a float with a standard function.
I think someone might well want to make an external that can take 'four' as 4. Or a symbol '4+2' that would become a float 6.0.
And obviously Pd should not be doing that all the time because most of the time that is not the right thing to do.
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.
Otherwise the user would have to manually convert the number (which is conventionally given in hexadecimal form) into a bunch of decimal numbers small enough to be represented as float and then the external would combine them internally.
Martin