On 2011-09-10 13:46, Mathieu Bouchard wrote:
On Sat, 10 Sep 2011, Martin Peach wrote:
Which other ways are you thinking about, apart from something that behaves more or less like strtof ?
OK, for example an object that converts names of numbers to floats: or binary to float: or imaginary numbers: or even some kind of [expr] that takes symbolic input: None of the above would work properly with a default symbol-to-float method. Each needs to parse its input according to its own specific meaning-space.
So what's the problem with having an implicit cast that does the strtof that people want in 99,99 % of the cases, and still be able to use explicit means to convert things like MCMLXXVIII to float in whichever way you like ?
Nothing.
It's not about all-encompassing conversions, it's about defaults.
If you say so. I was just saying that the default should avoid the all-encompassing conversion and not try second-guessing the users' intentions. It's probably safe to have Pd convert a symbol to a float by default iff there is no symbol method and there is a float method. Trying to interpret every possible string as a float would add huge amount of bloat and delay to core Pd.
Martin