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