Weird behaviour with arctan2(complex,complex). Take a look at this: In [11]: numpy.arctan2(1.,1.) Out[11]: 0.785398163397 In [12]: numpy.arctan2(1j,1j) --------------------------------------------------------------------------- exceptions.AttributeError Traceback (most recent call last) AttributeError: 'complex' object has no attribute 'arctan2' same error for: In [13]: numpy.arctan2(1j,1.) In [14]: numpy.arctan2(1.,1j) But arctan2 is defined for complex arguments, as far as Octave knows :-) : octave:7> atan2(1,1) ans = 0.78540 octave:8> atan2(1j,1j) ans = 0 octave:9> atan2(1j,1) ans = 0 octave:10> atan2(1,1j) ans = 1.5708 bug or wanted behaviour? Lorenzo.
I'll take a stab at this one; if I miss the mark, people, please chime in. What's "strange" here is not numpy's behavior but octave's (IMO). Remember that, over R, arctan is used in two different ways: one is simply as a map from (-inf, inf) -> (-pi/2,pi/2) - here, let's call that invtan; the other is as a means to determine "the angle" (conventionally taken to be between -pi and pi) of a point in the plane - but since, for example, tan(pi/4) = tan(-3pi/4) (and in general tan(x) = tan(x-pi)) to uniquely determine said angle, we need to keep track of and take into account the quadrant in which the point lies; this is (the only reason) why arctan2 is a function of two arguments, one representing the abscissa, the other the ordinate of the point. But when the argument is complex (arctan2, as the inverse of the tangent function, *is* a valid function on C), this geometric use no longer makes sense, so there's really no reason to implement arctan2(z,w), z, w complex. If for some reason, e.g., uniformity of algorithmic expression - I don't see any (simple) way to preserve uniformity of code expression - as near as I can tell, you're going to have to implement an if/else if you need to allow for the invtan of two complex arguments - you need to handle arctan2(z,w), implement it as arctan(w/z):
import numpy numpy.arctan(1j/1j) (0.78539816339744828+0j)
DG lorenzo bolla wrote:
Weird behaviour with arctan2(complex,complex). Take a look at this:
In [11]: numpy.arctan2(1.,1.) Out[11]: 0.785398163397
In [12]: numpy.arctan2(1j,1j) --------------------------------------------------------------------------- exceptions.AttributeError Traceback (most recent call last)
AttributeError: 'complex' object has no attribute 'arctan2'
same error for:
In [13]: numpy.arctan2(1j,1.) In [14]: numpy.arctan2(1.,1j)
But arctan2 is defined for complex arguments, as far as Octave knows :-) :
octave:7> atan2(1,1) ans = 0.78540 octave:8> atan2(1j,1j) ans = 0 octave:9> atan2(1j,1) ans = 0 octave:10> atan2(1,1j) ans = 1.5708
bug or wanted behaviour? Lorenzo. ------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
From http://documents.wolfram.com/mathematica/functions/ArcTan "If x or y is complex, then ArcTan[x, y] gives . When , ArcTan[x, y] gives
You make your point, but I would expect a behaviour similar to Mathematica or Matlab. the number such that and ." Lorenzo. On 4/29/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
I'll take a stab at this one; if I miss the mark, people, please chime in.
What's "strange" here is not numpy's behavior but octave's (IMO). Remember that, over R, arctan is used in two different ways: one is simply as a map from (-inf, inf) -> (-pi/2,pi/2) - here, let's call that invtan; the other is as a means to determine "the angle" (conventionally taken to be between -pi and pi) of a point in the plane - but since, for example, tan(pi/4) = tan(-3pi/4) (and in general tan(x) = tan(x-pi)) to uniquely determine said angle, we need to keep track of and take into account the quadrant in which the point lies; this is (the only reason) why arctan2 is a function of two arguments, one representing the abscissa, the other the ordinate of the point. But when the argument is complex (arctan2, as the inverse of the tangent function, *is* a valid function on C), this geometric use no longer makes sense, so there's really no reason to implement arctan2(z,w), z, w complex. If for some reason, e.g., uniformity of algorithmic expression - I don't see any (simple) way to preserve uniformity of code expression - as near as I can tell, you're going to have to implement an if/else if you need to allow for the invtan of two complex arguments - you need to handle arctan2(z,w), implement it as arctan(w/z):
import numpy numpy.arctan(1j/1j) (0.78539816339744828+0j)
DG
lorenzo bolla wrote:
Weird behaviour with arctan2(complex,complex). Take a look at this:
In [11]: numpy.arctan2(1.,1.) Out[11]: 0.785398163397
In [12]: numpy.arctan2(1j,1j)
---------------------------------------------------------------------------
exceptions.AttributeError Traceback (most recent call last)
AttributeError: 'complex' object has no attribute 'arctan2'
same error for:
In [13]: numpy.arctan2(1j,1.) In [14]: numpy.arctan2(1.,1j)
But arctan2 is defined for complex arguments, as far as Octave knows :-) :
octave:7> atan2(1,1) ans = 0.78540 octave:8> atan2(1j,1j) ans = 0 octave:9> atan2(1j,1) ans = 0 octave:10> atan2(1,1j) ans = 1.5708
bug or wanted behaviour? Lorenzo. ------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Far be it from me to challenge the mighty Wolfram, but I'm not sure that using the *formula* for calculating the arctan of a *single* complex argument from its real and imaginary parts makes any sense if x and/or y are themselves complex (in particular, does Lim(formula), as the imaginary part of complex x and/or y approaches zero, approach arctan2(realpart(x), realpart(y)?) - without going to the trouble to determine it one way or another, I'd be surprised if "their" continuation of the arctan2 function from RxR to CxC is (a. e.) continuous (not that I know for sure that "mine" is...). DG lorenzo bolla wrote:
You make your point, but I would expect a behaviour similar to Mathematica or Matlab.
From http://documents.wolfram.com/mathematica/functions/ArcTan <http://documents.wolfram.com/mathematica/functions/ArcTan> "If x or y is complex, then ArcTan[x , y] gives . When , ArcTan[x, y] gives the number such that and ."
Lorenzo.
On 4/29/07, *David Goldsmith* < David.L.Goldsmith@noaa.gov <mailto:David.L.Goldsmith@noaa.gov>> wrote:
I'll take a stab at this one; if I miss the mark, people, please chime in.
What's "strange" here is not numpy's behavior but octave's (IMO). Remember that, over R, arctan is used in two different ways: one is simply as a map from (-inf, inf) -> (-pi/2,pi/2) - here, let's call that invtan; the other is as a means to determine "the angle" (conventionally taken to be between -pi and pi) of a point in the plane - but since, for example, tan(pi/4) = tan(-3pi/4) (and in general tan(x) = tan(x-pi)) to uniquely determine said angle, we need to keep track of and take into account the quadrant in which the point lies; this is (the only reason) why arctan2 is a function of two arguments, one representing the abscissa, the other the ordinate of the point. But when the argument is complex (arctan2, as the inverse of the tangent function, *is* a valid function on C), this geometric use no longer makes sense, so there's really no reason to implement arctan2(z,w), z, w complex. If for some reason, e.g., uniformity of algorithmic expression - I don't see any (simple) way to preserve uniformity of code expression - as near as I can tell, you're going to have to implement an if/else if you need to allow for the invtan of two complex arguments - you need to handle arctan2(z,w), implement it as arctan(w/z):
>>> import numpy >>> numpy.arctan(1j/1j) (0.78539816339744828+0j)
DG
lorenzo bolla wrote: > Weird behaviour with arctan2(complex,complex). > Take a look at this: > > In [11]: numpy.arctan2(1.,1.) > Out[11]: 0.785398163397 > > In [12]: numpy.arctan2 (1j,1j) > --------------------------------------------------------------------------- > exceptions.AttributeError Traceback (most > recent call last) > > AttributeError: 'complex' object has no attribute 'arctan2' > > same error for: > > In [13]: numpy.arctan2(1j,1.) > In [14]: numpy.arctan2(1.,1j) > > But arctan2 is defined for complex arguments, as far as Octave knows :-) : > > octave:7> atan2(1,1) > ans = 0.78540 > octave:8> atan2(1j,1j) > ans = 0 > octave:9> atan2(1j,1) > ans = 0 > octave:10> atan2(1,1j) > ans = 1.5708 > > bug or wanted behaviour? > Lorenzo. > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> > http://projects.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> http://projects.scipy.org/mailman/listinfo/numpy-discussion <http://projects.scipy.org/mailman/listinfo/numpy-discussion>
------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On 29/04/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
Far be it from me to challenge the mighty Wolfram, but I'm not sure that using the *formula* for calculating the arctan of a *single* complex argument from its real and imaginary parts makes any sense if x and/or y are themselves complex (in particular, does Lim(formula), as the imaginary part of complex x and/or y approaches zero, approach arctan2(realpart(x), realpart(y)?) - without going to the trouble to determine it one way or another, I'd be surprised if "their" continuation of the arctan2 function from RxR to CxC is (a. e.) continuous (not that I know for sure that "mine" is...).
Well, yes, in fact, theirs is continuous, and in fact analytic, except along the branch cuts (which they describe). Formulas almost always yield continuous functions apart from easy-to-recognize cases. (This can be made into a specific theorem if you're determined.) Their formula is a pretty reasonable choice, given that it's not at all clear what arctan2 should mean for complex arguments. But for numpy it's tempting to simply throw an exception (which would catch quite a few programmer errors that would otherwise manifest as nonsense numbers). Still, I suppose defining it on the complex numbers in a way that is continuous close to the real plane allows people to put in almost-real complex numbers and get out pretty much the answer they expect. Does anyone have an application for which they need arctan2 of, say, (1+i,1-i)? Anne
me! I have two cases. 1. I need that arctan2(1+0.00000001j,1-0.000001j) gives something close to arctan2(1,1): any decent analytic prolungation will do! 2. if someone of you is familiar with electromagnetic problems, in particular with Snell's law, will recognize that in case of total internal reflection<http://en.wikipedia.org/wiki/Total_internal_reflection>the wavevector tangential to the interface is real, while the normal one is purely imaginary: hence the angle of diffraction is still given by arctan2(k_tangent, k_normal), that, as in Matlab or Octave, should give pi/2 (that physically means no propagation -- total internal reflection, as said). L. On 4/30/07, Anne Archibald <peridot.faceted@gmail.com> wrote:
On 29/04/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
Far be it from me to challenge the mighty Wolfram, but I'm not sure that using the *formula* for calculating the arctan of a *single* complex argument from its real and imaginary parts makes any sense if x and/or y are themselves complex (in particular, does Lim(formula), as the imaginary part of complex x and/or y approaches zero, approach arctan2(realpart(x), realpart(y)?) - without going to the trouble to determine it one way or another, I'd be surprised if "their" continuation of the arctan2 function from RxR to CxC is (a. e.) continuous (not that I know for sure that "mine" is...).
Well, yes, in fact, theirs is continuous, and in fact analytic, except along the branch cuts (which they describe). Formulas almost always yield continuous functions apart from easy-to-recognize cases. (This can be made into a specific theorem if you're determined.)
Their formula is a pretty reasonable choice, given that it's not at all clear what arctan2 should mean for complex arguments. But for numpy it's tempting to simply throw an exception (which would catch quite a few programmer errors that would otherwise manifest as nonsense numbers). Still, I suppose defining it on the complex numbers in a way that is continuous close to the real plane allows people to put in almost-real complex numbers and get out pretty much the answer they expect. Does anyone have an application for which they need arctan2 of, say, (1+i,1-i)?
Anne _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
lorenzo bolla wrote:
me! I have two cases.
1. I need that arctan2(1+0.00000001j,1-0.000001j) gives something close to arctan2(1,1): any decent analytic prolungation will do!
This is the foreseeable use case described by Anne. In any event, I stand not only corrected, but embarrassed (for numpy): Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as N >>> complex(0,1) 1j >>> N.arctan(1) 0.78539816339744828 >>> N.arctan(complex(0,1)) Warning: invalid value encountered in arctan (nannanj) I agree that arctan should be implemented for _at least_ *one* complex argument... DG
1. if someone of you is familiar with electromagnetic problems, in particular with Snell's law, will recognize that in case of total internal reflection <http://en.wikipedia.org/wiki/Total_internal_reflection> the wavevector tangential to the interface is real, while the normal one is purely imaginary: hence the angle of diffraction is still given by arctan2(k_tangent, k_normal), that, as in Matlab or Octave, should give pi/2 (that physically means no propagation -- total internal reflection, as said).
L.
On 4/30/07, *Anne Archibald* <peridot.faceted@gmail.com <mailto:peridot.faceted@gmail.com>> wrote:
On 29/04/07, David Goldsmith <David.L.Goldsmith@noaa.gov <mailto:David.L.Goldsmith@noaa.gov>> wrote: > Far be it from me to challenge the mighty Wolfram, but I'm not sure that > using the *formula* for calculating the arctan of a *single* complex > argument from its real and imaginary parts makes any sense if x and/or y > are themselves complex (in particular, does Lim(formula), as the > imaginary part of complex x and/or y approaches zero, approach > arctan2(realpart(x), realpart(y)?) - without going to the trouble to > determine it one way or another, I'd be surprised if "their" > continuation of the arctan2 function from RxR to CxC is (a. e.) > continuous (not that I know for sure that "mine" is...).
Well, yes, in fact, theirs is continuous, and in fact analytic, except along the branch cuts (which they describe). Formulas almost always yield continuous functions apart from easy-to-recognize cases. (This can be made into a specific theorem if you're determined.)
Their formula is a pretty reasonable choice, given that it's not at all clear what arctan2 should mean for complex arguments. But for numpy it's tempting to simply throw an exception (which would catch quite a few programmer errors that would otherwise manifest as nonsense numbers). Still, I suppose defining it on the complex numbers in a way that is continuous close to the real plane allows people to put in almost-real complex numbers and get out pretty much the answer they expect. Does anyone have an application for which they need arctan2 of, say, (1+i,1-i)?
Anne _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> http://projects.scipy.org/mailman/listinfo/numpy-discussion
------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On 4/30/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
lorenzo bolla wrote:
me! I have two cases.
1. I need that arctan2(1+0.00000001j,1-0.000001j) gives something close to arctan2(1,1): any decent analytic prolungation will do!
This is the foreseeable use case described by Anne.
In any event, I stand not only corrected, but embarrassed (for numpy):
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import numpy as N >>> complex(0,1) 1j >>> N.arctan(1) 0.78539816339744828 >>> N.arctan(complex(0,1)) Warning: invalid value encountered in arctan (nannanj)
I agree that arctan should be implemented for _at least_ *one* complex argument...
It is, you should look at that error a bit more carefully... -tim (hint what is arctan(0+1j)?) DG
1. if someone of you is familiar with electromagnetic problems, in particular with Snell's law, will recognize that in case of total internal reflection <http://en.wikipedia.org/wiki/Total_internal_reflection> the wavevector tangential to the interface is real, while the normal one is purely imaginary: hence the angle of diffraction is still given by arctan2(k_tangent, k_normal), that, as in Matlab or Octave, should give pi/2 (that physically means no propagation -- total internal reflection, as said).
L.
On 4/30/07, *Anne Archibald* <peridot.faceted@gmail.com <mailto:peridot.faceted@gmail.com>> wrote:
On 29/04/07, David Goldsmith <David.L.Goldsmith@noaa.gov <mailto:David.L.Goldsmith@noaa.gov>> wrote: > Far be it from me to challenge the mighty Wolfram, but I'm not sure that > using the *formula* for calculating the arctan of a *single* complex > argument from its real and imaginary parts makes any sense if x and/or y > are themselves complex (in particular, does Lim(formula), as the > imaginary part of complex x and/or y approaches zero, approach > arctan2(realpart(x), realpart(y)?) - without going to the trouble
to
> determine it one way or another, I'd be surprised if "their" > continuation of the arctan2 function from RxR to CxC is (a. e.) > continuous (not that I know for sure that "mine" is...).
Well, yes, in fact, theirs is continuous, and in fact analytic,
except
along the branch cuts (which they describe). Formulas almost always yield continuous functions apart from easy-to-recognize cases. (This can be made into a specific theorem if you're determined.)
Their formula is a pretty reasonable choice, given that it's not at all clear what arctan2 should mean for complex arguments. But for numpy it's tempting to simply throw an exception (which would catch quite a few programmer errors that would otherwise manifest as nonsense numbers). Still, I suppose defining it on the complex numbers in a way that is continuous close to the real plane allows people to put in almost-real complex numbers and get out pretty much the
answer
they expect. Does anyone have an application for which they need arctan2 of, say, (1+i,1-i)?
Anne _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> http://projects.scipy.org/mailman/listinfo/numpy-discussion
------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- //=][=\\ tim.hochberg@ieee.org
(hint what is arctan(0+1j)?)
Well, at the risk of embarrassing myself, using arctan(x+iy) = I get: arctan(0+1i) = -i*log((0+i*1)/sqrt(0^2 + 1^2)) = -i*log(i/1) = -i*log(i) = -i*log(exp(i*pi/2)) = -i*i*pi/2 = pi/2... Is there some reason I'm forgetting (e.g., a branch cut convention or something) why this is wrong? DG
On 4/30/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
(hint what is arctan(0+1j)?)
Well, at the risk of embarrassing myself, using arctan(x+iy) = I get:
arctan(0+1i) = -i*log((0+i*1)/sqrt(0^2 + 1^2)) = -i*log(i/1) = -i*log(i) = -i*log(exp(i*pi/2)) = -i*i*pi/2 = pi/2...
Is there some reason I'm forgetting (e.g., a branch cut convention or something) why this is wrong?
Oops. It may well be OK, I answered too fast (I'd explain my thinking, but ti would be embarassing). However, I believe atan works in general for complex numbers but it may well have a problem for this specific case. I should look at this more closely though since the behaviour near zero does seem a little odd. No time right now, but maybe later today. DG
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- //=][=\\ tim.hochberg@ieee.org
Timothy Hochberg wrote:
On 4/30/07, *David Goldsmith* <David.L.Goldsmith@noaa.gov <mailto:David.L.Goldsmith@noaa.gov>> wrote:
> (hint what is arctan(0+1j)?) > Well, at the risk of embarrassing myself, using arctan(x+iy) = I get:
arctan(0+1i) = -i*log((0+i*1)/sqrt(0^2 + 1^2)) = -i*log(i/1) = -i*log(i) = -i*log(exp(i*pi/2)) = -i*i*pi/2 = pi/2...
Is there some reason I'm forgetting (e.g., a branch cut convention or something) why this is wrong?
Oops. It may well be OK, I answered too fast (I'd explain my thinking, but ti would be embarassing).
Was it: "pi/2 is outside the range of arctan"? (No worries: I thought of this too when I saw what value fell out of the formula, but then, it's outside the range of the *real-valued* function, but clearly it's not outside the range of the *complex-valued* function.) DG
However, I believe atan works in general for complex numbers but it may well have a problem for this specific case.
I should look at this more closely though since the behaviour near zero does seem a little odd. No time right now, but maybe later today.
DG _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> http://projects.scipy.org/mailman/listinfo/numpy-discussion
--
//=][=\\
tim.hochberg@ieee.org <mailto:tim.hochberg@ieee.org> ------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
hold on, david. the formula I posted previously from wolfram is ArcTan[x,y] with x or y complex: its the same of arctan2(x,y). arctan is another function (even though arctan2(y,x) should be "a better" arctan(y/x)). the correct formula for y = arctan(x), with any x (real or complex), should be (if I still can play with sin and cos...): y = arctan(x) = 1/(2j) * log((1j-x)/(1j+x)) [ you can get it doing: y = arctan(x) --> x = tan(y) = sin(x)/cos(x) = -1j * (exp(1j*y)-exp(-1j*y))/(exp(1j*y)+exp(-1j*y); then let z = exp(1j*y) and solve in z.] I've tested the formula and it seems ok for different inputs (I've checked that tan(arctan(x)) == x): --------------------------- octave:56> x = 1; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.0000 octave:57> x = 1j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = -0 + 1i octave:58> x = 2j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.8369e-16 + 2.0000e+00i octave:59> x = 1+2j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.0000 + 2.0000i --------------------------- hth, L. On 4/30/07, David Goldsmith <David.L.Goldsmith@noaa.gov> wrote:
(hint what is arctan(0+1j)?)
Well, at the risk of embarrassing myself, using arctan(x+iy) = I get:
arctan(0+1i) = -i*log((0+i*1)/sqrt(0^2 + 1^2)) = -i*log(i/1) = -i*log(i) = -i*log(exp(i*pi/2)) = -i*i*pi/2 = pi/2...
Is there some reason I'm forgetting (e.g., a branch cut convention or something) why this is wrong?
DG _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
hold on, david. the formula I posted previously from wolfram is ArcTan[x,y] with x or y complex: its the same of arctan2(x,y). arctan is another function (even though arctan2(y,x) should be "a better" arctan(y/x)).
the correct formula for y = arctan(x), with any x (real or complex), should be (if I still can play with sin and cos...):
y = arctan(x) = 1/(2j) * log((1j-x)/(1j+x)) After a little algebra, they're the same formula (as they must be; hint: "rationalize" the denominator inside the log and bring the 1/2 inside
lorenzo bolla wrote: the log, making it a square root, and finally, rewrite 1/i as -i); I have to run my kid to school right now, but if you want me to flesh this out, reply and I'll type it out and send it when I get back.. DG
[ you can get it doing: y = arctan(x) --> x = tan(y) = sin(x)/cos(x) = -1j * (exp(1j*y)-exp(-1j*y))/(exp(1j*y)+exp(-1j*y); then let z = exp(1j*y) and solve in z.]
I've tested the formula and it seems ok for different inputs (I've checked that tan(arctan(x)) == x): --------------------------- octave:56> x = 1; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.0000 octave:57> x = 1j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = -0 + 1i octave:58> x = 2j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.8369e-16 + 2.0000e+00i octave:59> x = 1+2j; tan(1/2/1j*log((1j-x)/(1j+x))) ans = 1.0000 + 2.0000i ---------------------------
hth, L.
On 4/30/07, *David Goldsmith* <David.L.Goldsmith@noaa.gov <mailto:David.L.Goldsmith@noaa.gov>> wrote:
> (hint what is arctan(0+1j)?) > Well, at the risk of embarrassing myself, using arctan(x+iy) = I get:
arctan(0+1i) = -i*log((0+i*1)/sqrt(0^2 + 1^2)) = -i*log(i/1) = -i*log(i) = -i*log(exp(i*pi/2)) = -i*i*pi/2 = pi/2...
Is there some reason I'm forgetting (e.g., a branch cut convention or something) why this is wrong?
DG _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org <mailto:Numpy-discussion@scipy.org> http://projects.scipy.org/mailman/listinfo/numpy-discussion
------------------------------------------------------------------------
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
Anne Archibald -
David Goldsmith -
lorenzo bolla -
Timothy Hochberg