2018-05-09 15:15 GMT-03:00 Martin Peach <[email protected]>: > On Wed, May 9, 2018 at 1:13 PM, Alexandre Torres Porres <[email protected]> > wrote: > >> >> 2018-05-09 13:53 GMT-03:00 Martin Peach <[email protected]>: >> >>> >>>> 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 <[email protected]>: > 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.
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
