Hi, I'm basically reviving a discussion I found on the list archive from 5 years ago, see: https://lists.puredata.info/pipermail/pd-list/2013-04/102279.html
Not much came out of it besides the assumption this could be a concern to prevent inf/nan results!
As in:
[-1( |[pow 0.5] |
I can see that, because we have other examples like that in Pd, like log/log~ outputing -1000 for <= 0 inputs.
But still, that's not a good reason to prevent something like:
[-1 ( |[pow 2]
So I did a Pull Request where I still make it output "0" when pow/pow~ would give 'inf' or 'nan' but still allow us to calculate the power of negative numbers. Here it is: https://github.com/pure-data/pure-data/pull/356 (In another commit, 'm also proposing log to behave like log~ anyway)
I come to the list to query if anyone thinks there might be a concern in expanding the behaviour of pow/pow~
I personally cannot think of any use case where someone relies on pow(-1, 2) generating "0", it just seems wrong to me (i.e. a bug) and allowing it to do that wouldn't break things.
cheers
On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres porres@gmail.com wrote:
... I personally cannot think of any use case where someone relies on pow(-1, 2) generating "0", it just seems wrong to me (i.e. a bug) and allowing it to do that wouldn't break things.
Maybe add another outlet for the imaginary part?
Martin
2018-05-08 18:05 GMT-03:00 Martin Peach chakekatzil@gmail.com:
On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres porres@gmail.com wrote:
... I personally cannot think of any use case where someone relies on pow(-1, 2) generating "0", it just seems wrong to me (i.e. a bug) and allowing it to do that wouldn't break things.
Maybe add another outlet for the imaginary part?
but simply pow(-1, 2) does not generate an imaginary part, right?
well, maybe expanding this to give you complex numbers is stretching a bit. This only uses the pow function from math.c, but that doesn't give you a complex number as the result of something like pow(-2, 3.3), it gives you just 'nan' instead, like what you get from [expr pow(-2, 3.3)]. Making this an object that outputs a complex number requires more surgery and expansion, and I don't really know if we need this in the built in object of [pow], maybe an external?
The question is more of what to do about the inf/nan that comes out, seems the original and general concern in Pd is to turn them into "0", so I did it.
And my deep frustration and motivation is simply that I can't do something like pow(-1, 2) instead of wanting a comex number output... and for that I'm forced to use [expr] instead, but I just don't see the point.
On Tue, May 8, 2018 at 9:28 PM, Alexandre Torres Porres porres@gmail.com wrote:
2018-05-08 18:05 GMT-03:00 Martin Peach chakekatzil@gmail.com:
On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres <porres@gmail.com
wrote:
... I personally cannot think of any use case where someone relies on pow(-1, 2) generating "0", it just seems wrong to me (i.e. a bug) and allowing it to do that wouldn't break things.
Maybe add another outlet for the imaginary part?
but simply pow(-1, 2) does not generate an imaginary part, right?
Right, sorry I was thinking of pow(-1, 0.5). pow(-1,2) should give 1.
Useful if you wanted to make a parabolic waveform in a table or something like that. And I think pow(-1, 0.5) should give a 'NaN' instead of 0 if we're sticking to Real numbers. 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? So ideally this:
[-1{ | [pow 0.5] | [sel NaN] | |
would emit a bang from the left outlet.
Martin
2018-05-08 23:18 GMT-03:00 Martin Peach chakekatzil@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.
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@gmail.com:
2018-05-08 23:18 GMT-03:00 Martin Peach chakekatzil@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.
On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres porres@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].
Martin
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).
but [print]s the value '-1.#IND00'.
are you on windows?
In max, neither of these works in a [sel].
yep, so it'd make sense to avoid them
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.
but [print]s the value '-1.#IND00'.
are you on windows?
Yes. What does max print on a Mac?
Martin
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.
On Wednesday, May 9, 2018, 12:55:59 PM EDT, Martin Peach chakekatzil@gmail.com wrote:
On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres porres@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? -Jonathan
-
Alexandre Torres Porres -
Jonathan Wilkes -
Martin Peach