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

2018-05-09 15:15 GMT-03:00 Martin Peach : > On Wed, May 9, 2018 at 1:13 PM, Alexandre Torres Porres > wrote: > >> >> 2018-05-09 13:53 GMT-03:00 Martin Peach : >> >>> I just tried this in Max6: >>> [pow 2] with a negative input

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

On Wed, May 9, 2018 at 1:13 PM, Alexandre Torres Porres wrote: > > 2018-05-09 13:53 GMT-03:00 Martin Peach : > >> >>> 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

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

> On Wednesday, May 9, 2018, 12:55:59 PM EDT, Martin Peach > wrote: On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres 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

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

2018-05-09 13:53 GMT-03:00 Martin Peach : > >> 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

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

On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres 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

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

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

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

2018-05-08 23:18 GMT-03:00 Martin Peach : > 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

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

On Tue, May 8, 2018 at 9:28 PM, Alexandre Torres Porres wrote: > 2018-05-08 18:05 GMT-03:00 Martin Peach : > >> On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres > > wrote: >> >>> ... >>> I personally cannot think of any use case

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

2018-05-08 18:05 GMT-03:00 Martin Peach : > On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres > 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)

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

On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres 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

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

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