[PD] FW: Negative input numbers for [pow] return 0

[Ivica Ico Bukvic]

Forgot to copy list.

 

From: Ivica Ico Bukvic [mailto:ico at 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 at 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 at 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 at iem.at [mailto:pd-list-bounces at iem.at] On Behalf Of
> IOhannes m zmoelnig
> Sent: Tuesday, April 23, 2013 6:21 AM
> To: pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list


_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130423/b74d0061/attachment.htm>