If you think about it negative exponents require a completely
different algorithm that is discontinuous with the one for
positives. Instead of multiplying you divide n times.
For sure, but we're talking about negative bases, additionally negative exponents are already handled correctly by [pow].
bien sur, it would be easy to add this.
the thing is, do we really want that?
having NaN's somewhere in your computation will have all the results become NaN, including any signals.
NaN-signals don't sound good.
There are many things I can do in Pd that don't sound good, I've bust my ears and headphones/speakers too many times to know that :)
I would argue that yes (I personally) would want that. If the calculation is wrong, then it's my fault. Also, this is in reference to a message object that's being
used for a graph calculation. Receiving '0' was confusing.
the output is a number of the value NaN (which gets displayed as NaN, but this doesn't mean it a symbol ,just like "1e-8" is not a symbol either...usually)
Good to know, thanks!
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? Obviously [expr] is a good solution but still the fact that [pow] acts differently feels non-intuitive.