2018-05-09 15:15 GMT-03:00 Martin Peach <chakekatzil@gmail.com>:
On Wed, May 9, 2018 at 1:13 PM, Alexandre Torres Porres <porres@gmail.com> wrote:

2018-05-09 13:53 GMT-03:00 Martin Peach <chakekatzil@gmail.com>:

I just tried this in Max6:
[pow 2] with a negative input gives a correct positive result.
[pow 0.5] with negative input sets a floatnumberbox to 'nan',

yeah, but try it with [pow~] in max, you'll see that it will filter it out and make it output "0", in the same way I was telling you about the other signal objects that can generate inf/nan (I gave the example of atanh~). Currently, it seems only signal bitwise operator objects in max can potentially create inf/nan, and they have a [bitsafe~] object to deal with that (one which we also cloned for cyclone).

It makes sense for signal objects to give zero, to avoid giant spikes in the audio, but control objects are not only used for audio, they ought to give something more truthful, maybe just post an error message to the console if there is no trapping mechanism that can be constructed in a patch.

I get your reasoning, but this should expand to all of pd objects for consistency, perhaps even have a way to select nan/inf... anyway... in any case, this is not only a concern on how to update pow/pow~, there should be a parallel and more general discussion about this, right? As far as updating pow/pow~ goes, my suggestion/fix fits the current way Pd handles this sort of thing.

 
2018-05-09 14:14 GMT-03:00 Jonathan Wilkes <jancsika@yahoo.com>:
And how about [pow~]-- what does it do in Max?
 
I hope you got my other message that responded to this question. Just so it is clear, my current Pull Request gives the exact same behaviour of pow~ in Max.