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

Alexandre Torres Porres porres at gmail.com
Wed May 9 16:38:56 CEST 2018


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!

cheers

2018-05-08 23:36 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

>
> 2018-05-08 23:18 GMT-03:00 Martin Peach <chakekatzil at gmail.com>:
>
>> I think pow(-1, 0.5) should give a 'NaN' instead of 0 if we're sticking
>> to Real numbers.
>>
>
> I don't mind the nan/inf output either, but it's not up to me... I'm just
> guessing there's such a concern in avoiding them, as with [log]/[log~], or
> even when you do [/ 0]! The fact is that Pd internal math objects have this
> thing already, you know, and it's not like preventing negative numbers was
> some accident, it was quite intentional, so I'm trying to meet half way
> instead of just proposing we should change everything and just deal with
> nan/inf.
>
>
>> I'm not sure if something like [select NaN Inf -Inf] works in Pd. It
>> doesn't give any error on creation but how to generate the input?
>>
>
> It doesn't work, I tried with [expr pow(-1, 0.5)], which generates nan in
> this case... by the way, I guess if people care about nans, then they can
> just adopt the expr version. The expr object, while we're at it, allows you
> to check if a number is a nan or inf with the isnan($f1) / isinf($f1)
> functions - then you can feed it to a select object. So you have this
> situation already in Pd with expr that better deals with this kind of math
> already, which is a poin that maybe we shouldn't mess too much with
> [pow]/[pow~] apart from letting them compute negative numbers that make
> sense.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180509/3a15adf3/attachment.html>


More information about the Pd-list mailing list