[PD] pow/pow~ and negative input, a fix proposal

Jonathan Wilkes jancsika at yahoo.com
Wed May 9 19:14:25 CEST 2018

> On Wednesday, May 9, 2018, 12:55:59 PM EDT, Martin Peach <chakekatzil at gmail.com> wrote: 
 On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres <porres at gmail.com> wrote:

You know, now that you the inability to deal with nan/inf in pd, such as in [select] came up, it makes total sense to avoid them in Pd and I can see where that comes from.
By the way, filtering out nan/inf is quite common in Max for audio signals, and in cyclone we needed to check that in objects like the trig functions (for instance  cyclone/atanh~ outputs 0 for input values <= -1 or >=1). And the case for doing that in audio signals is strong, as people say inf/nan is not good if it reaches your speakers and stuff.

I was still unsure about why doing that for cnotrol numbers as well, but what's the point in generating them if your system doesn't handle it well, right? In the case of [pow], "0" is a good limit value to clip your output, it makes sense since you can't get negative numbers but you can reach 0!

> 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', but [print]s the value '-1.#IND00'.> In max, neither of these works in a [sel].
And how about [pow~]-- what does it do in Max?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180509/97f0526b/attachment-0001.html>

More information about the Pd-list mailing list