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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
