Hi,
Just realised putting a negative number into the [pow] object outputs '0'?!?
For example if I do:
[-1 ( | [pow 2]
it returns 0, where I would expect it to return 1.
Is this a known limitation or bug? Are there any work arounds if I want a variable power?
(I'm running Pd 0.44.1 on OS X Mountain Lion)
Thanks, Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-22 14:19, Joe White wrote:
Hi,
Just realised putting a negative number into the [pow] object outputs '0'?!?
For example if I do:
[-1 ( | [pow 2]
it returns 0, where I would expect it to return 1.
Is this a known limitation or bug?
it's most likely a feature that tries to protect you from things like:
[-1( | [pow 0.5] |
Are there any work arounds if I want a variable power?
urgh, i had hoped to never have to tell people to use [expr], but there you go:
[-1
|
[pack 0 2]
|
[expr pow($f1, $f2)]
|
[1\
vbmdf IOhannes
Is this a known limitation or bug?
it's most likely a feature that tries to protect you from things like: [-1( | [pow 0.5] |
Ahh yeah makes sense.
I'm not sure why but I always feel uneasy using [expr], maybe because of libpd :)
[expr] does handle (-1)^0.5 with a NaN output though. Would it be possible to add this to [pow] as well? Something like for negative base values, non-integer exponent values would return NaN?
Additionally for [pow] to output '0' seems wrong, because that is definitely not the answer. I've never seen NaN output elsewhere so I'm assuming [expr] outputs a symbol and not some Pd defined NaN type (maybe?).
Thanks for the reply IOhannes!
Cheers, Joe
On 22 April 2013 13:30, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-22 14:19, Joe White wrote:
Hi,
Just realised putting a negative number into the [pow] object outputs '0'?!?
For example if I do:
[-1 ( | [pow 2]
it returns 0, where I would expect it to return 1.
Is this a known limitation or bug?
it's most likely a feature that tries to protect you from things like:
[-1( | [pow 0.5] |
Are there any work arounds if I want a variable power?
urgh, i had hoped to never have to tell people to use [expr], but there you go:
[-1
| [pack 0 2] | [expr pow($f1, $f2)] | [1\vbmdf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF1LW8ACgkQkX2Xpv6ydvRWDgCffaIHH1qXGqFYLlt1iiJQFW5Q OdEAnR8WVw+zxRKd8LWjVo95daJ/Aq6Y =PbB6 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you think about it negative exponents require a completely different algorithm that is discontinuous with the one for positives. Instead of multiplying you divide n times.
You can take advantage of
b^-n = 1/b^n
Use a [moses] and two [pow], where the negative branch then has its reciprocal, or use [abs] and [sgn] to flip the negative ones through a reciprocal.
cheers, Andy
On Mon, Apr 22, 2013 at 03:07:43PM +0100, Joe White wrote:
Is this a known limitation or bug?
it's most likely a feature that tries to protect you from things like: [-1( | [pow 0.5] |
Ahh yeah makes sense.
I'm not sure why but I always feel uneasy using [expr], maybe because of libpd :)
[expr] does handle (-1)^0.5 with a NaN output though. Would it be possible to add this to [pow] as well? Something like for negative base values, non-integer exponent values would return NaN?
Additionally for [pow] to output '0' seems wrong, because that is definitely not the answer. I've never seen NaN output elsewhere so I'm assuming [expr] outputs a symbol and not some Pd defined NaN type (maybe?).
Thanks for the reply IOhannes!
Cheers, Joe
On 22 April 2013 13:30, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-22 14:19, Joe White wrote:
Hi,
Just realised putting a negative number into the [pow] object outputs '0'?!?
For example if I do:
[-1 ( | [pow 2]
it returns 0, where I would expect it to return 1.
Is this a known limitation or bug?
it's most likely a feature that tries to protect you from things like:
[-1( | [pow 0.5] |
Are there any work arounds if I want a variable power?
urgh, i had hoped to never have to tell people to use [expr], but there you go:
[-1
| [pack 0 2] | [expr pow($f1, $f2)] | [1\vbmdf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF1LW8ACgkQkX2Xpv6ydvRWDgCffaIHH1qXGqFYLlt1iiJQFW5Q OdEAnR8WVw+zxRKd8LWjVo95daJ/Aq6Y =PbB6 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 04/22/2013 04:07 PM, Joe White wrote:
Would it be possible to add this to [pow] as well? Something like for negative base values, non-integer exponent values would return NaN?
bien sur, it would be easy to add this. the thing is, do we really want that? having NaN's somewhere in your computation will have all the results become NaN, including any signals. NaN-signals don't sound good.
Additionally for [pow] to output '0' seems wrong, because that is definitely not the answer. I've never seen NaN output elsewhere so I'm assuming [expr] outputs a symbol and not some Pd defined NaN type (maybe?).
no. the output is a number of the value NaN (which gets displayed as NaN, but this doesn't mean it a symbol ,just like "1e-8" is not a symbol either...usually)
fmgar IOhannes
Disclaimer: I don't feel too strongly about this because I realised my original calculation was wrong anyway, however...
If you think about it negative exponents require a completely
different algorithm that is discontinuous with the one for positives. Instead of multiplying you divide n times.
For sure, but we're talking about negative bases, additionally negative exponents are already handled correctly by [pow].
bien sur, it would be easy to add this.
the thing is, do we really want that? having NaN's somewhere in your computation will have all the results become NaN, including any signals. NaN-signals don't sound good.
There are many things I can do in Pd that don't sound good, I've bust my ears and headphones/speakers too many times to know that :) I would argue that yes (I personally) would want that. If the calculation is wrong, then it's my fault. Also, this is in reference to a message object that's being used for a graph calculation. Receiving '0' was confusing.
the output is a number of the value NaN (which gets displayed as NaN, but
this doesn't mean it a symbol ,just like "1e-8" is not a symbol either...usually)
Good to know, thanks!
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? Obviously [expr] is a good solution but still the fact that [pow] acts differently feels non-intuitive.
Cheers, Joe
On 22 April 2013 21:43, IOhannes zmölnig zmoelnig@iem.at wrote:
On 04/22/2013 04:07 PM, Joe White wrote:
Would it be possible to add this to [pow] as well? Something like for negative base values, non-integer exponent values would return NaN?
bien sur, it would be easy to add this. the thing is, do we really want that? having NaN's somewhere in your computation will have all the results become NaN, including any signals. NaN-signals don't sound good.
Additionally for [pow] to output '0' seems wrong, because that is definitely not the answer. I've never seen NaN output elsewhere so I'm assuming [expr] outputs a symbol and not some Pd defined NaN type (maybe?).
no. the output is a number of the value NaN (which gets displayed as
NaN, but this doesn't mean it a symbol ,just like "1e-8" is not a symbol either...usually)
fmgar IOhannes
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-23 11:50, Joe White wrote:
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have?
the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0)
fgmasdr IOhannes
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See:
https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-23 11:50, Joe White wrote:
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have?
the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0)
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yep. It's damaging to have NaN's propagating around in Pd. [pow] having a single output means that you only want real values. The result is not a real number-I think the result should just be set to 0 (perhaps 1 depending on what the worst usage case is). Would it be better to have pow just output the real part of the complex number, generated from:
(-1*base)^exp*e^(pi*exp*i) Which is (-1*base)^exp*cos(pi*exp) when base is a negative number
this assumes the standard branch cut in complex analysis: -1=e^(pi*i) and not e^(3*pi*i) or any other
Chuck On Apr 23, 2013 9:11 PM, "Ivica Ico Bukvic" ico@vt.edu wrote:
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See:
https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf
Of
IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-23 11:50, Joe White wrote:
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have?
the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0)
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Forgot to copy list.
From: Ivica Ico Bukvic [mailto:ico@vt.edu] Sent: Tuesday, April 23, 2013 11:15 PM To: 'Charles Z Henry' Subject: RE: [PD] Negative input numbers for [pow] return 0
Yes, the proposed patch generates 0 when imaginary numbers are involved and issues warning on the console with ability to track the error.
From: Charles Z Henry [mailto:czhenry@gmail.com] Sent: Tuesday, April 23, 2013 10:39 PM To: Ivica Ico Bukvic Cc: pd-list; IOhannes m zmoelnig Subject: Re: [PD] Negative input numbers for [pow] return 0
Yep. It's damaging to have NaN's propagating around in Pd. [pow] having a single output means that you only want real values. The result is not a real number-I think the result should just be set to 0 (perhaps 1 depending on what the worst usage case is). Would it be better to have pow just output the real part of the complex number, generated from:
(-1*base)^exp*e^(pi*exp*i) Which is (-1*base)^exp*cos(pi*exp) when base is a negative number
this assumes the standard branch cut in complex analysis: -1=e^(pi*i) and not e^(3*pi*i) or any other
Chuck
On Apr 23, 2013 9:11 PM, "Ivica Ico Bukvic" ico@vt.edu wrote:
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See:
https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-23 11:50, Joe White wrote:
Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have?
the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0)
fgmasdr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-24 04:10, Ivica Ico Bukvic wrote:
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values,
we call those NaNs.
"the implementation would be trivial" implied "if you are ready to deal with NaNs".
On 2013-04-24 05:15, Ivica Ico Bukvic wrote:
Yes, the proposed patch generates 0 when imaginary numbers are involved and issues warning on the console with ability to track the error.
in which the original behaviour is probably "better", as the result won't start jumping widely between real values and zero.
it seems like i have somehow turned into a defender of the current behaviour of [pow]. i'd rather not (that is: personally i'd rather not have too many constructs built into Pd that seemingly make life easier and protect people from doing stupid things)
rtfgmqawe IOhannes
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See:
https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3
I think Ivica's proposal is a great solution. Still output 0 for any NaNs but report it to the user so they are aware.
On 24 April 2013 09:50, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-24 04:10, Ivica Ico Bukvic wrote:
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values,
we call those NaNs.
"the implementation would be trivial" implied "if you are ready to deal with NaNs".
On 2013-04-24 05:15, Ivica Ico Bukvic wrote:
Yes, the proposed patch generates 0 when imaginary numbers are involved and issues warning on the console with ability to track the error.
in which the original behaviour is probably "better", as the result won't start jumping widely between real values and zero.
it seems like i have somehow turned into a defender of the current behaviour of [pow]. i'd rather not (that is: personally i'd rather not have too many constructs built into Pd that seemingly make life easier and protect people from doing stupid things)
rtfgmqawe IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF3nNYACgkQkX2Xpv6ydvRlTACePiG5HlLocgfVXtKa/cursSDJ vwoAnA0vk+WEYN0iDjD1amwaPFciJzRn =DfXc -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Charles Z Henry -
IOhannes m zmoelnig -
IOhannes zmölnig
-
Ivica Ico Bukvic -
Joe White