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

Martin Peach chakekatzil at gmail.com
Wed May 9 18:53:47 CEST 2018

On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres <porres at gmail.com>

> 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].

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180509/8994ea12/attachment.html>

More information about the Pd-list mailing list