Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On Fri, Sep 13, 2024 at 1:10 PM Duncan Murdoch wrote: > [You don't often get email from [email protected]. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > Caution: External email. > On 2024-09-13 8:53 a.m., Jonathan Dushoff wrote: > >> Message: 4 > >> Date: Thu, 12 Sep 2024 11:21:02 -0400 > >> From: Duncan Murdoch > >> That's not the correct formula, is it? I think the result should be x * > >> Conj(y) / Mod(y)^2 . > > Correct, sorry. And thanks. > >> So that would involve * and > >> / , not just real arithmetic. > > Not an expert, but I don't see it. Conj and Mod seem to be numerically > > straightforward real-like operations. We do those, and then multiply > > one complex number by one real quotient. > Are you sure? We aren't dealing with real numbers and complex numbers > here, we're dealing with those sets extended with infinities and other > weird things. Definitely not sure, just thought I would suggest it as a possibility. > So for example if y is some kind of infinite complex number, then 1/y > should come out to zero, and if x is finite, the final result of x/y > should be zero. > But if we evaluate x/y as (x / Mod(y)^2) * Conj(y), won't we get a NaN > from zero times infinity? Yes, and it's not trivial to work around, so probably not worth it. Thanks, __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On 2024-09-13 8:53 a.m., Jonathan Dushoff wrote: Message: 4 Date: Thu, 12 Sep 2024 11:21:02 -0400 From: Duncan Murdoch That's not the correct formula, is it? I think the result should be x * Conj(y) / Mod(y)^2 . Correct, sorry. And thanks. So that would involve * and / , not just real arithmetic. Not an expert, but I don't see it. Conj and Mod seem to be numerically straightforward real-like operations. We do those, and then multiply one complex number by one real quotient. Are you sure? We aren't dealing with real numbers and complex numbers here, we're dealing with those sets extended with infinities and other weird things. I think the formula I gave assumes no infinities. So for example if y is some kind of infinite complex number, then 1/y should come out to zero, and if x is finite, the final result of x/y should be zero. But if we evaluate x/y as (x / Mod(y)^2) * Conj(y), won't we get a NaN from zero times infinity? I imagine someone has thought about all these edge cases. Maybe they're discussed in one of the standards that Richard referenced. Duncan Murdoch __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> Message: 4 > Date: Thu, 12 Sep 2024 11:21:02 -0400 > From: Duncan Murdoch > That's not the correct formula, is it? I think the result should be x * > Conj(y) / Mod(y)^2 . Correct, sorry. And thanks. > So that would involve * and > / , not just real arithmetic. Not an expert, but I don't see it. Conj and Mod seem to be numerically straightforward real-like operations. We do those, and then multiply one complex number by one real quotient. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> Richard O'Keefe > on Sat, 7 Sep 2024 02:40:29 +1200 writes: > G.5.1 para 2 can be found in the C17 standard -- I > actually have the final draft not the published standard. Ok. Thank you. A direct hopefully stable link to that final draft's Appendix G seems to be https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2310.pdf#chapter.14 which is good to have available. > It's in earlier standards, I just didn't check earlier > standards. Complex arithmetic was not in the first C > standard (C89) but was in C99. indeed, currently we only require C11 for R. A longer term solution that we (the R core team) will probably look into is to start making use of current C standards for complex arithmetic. As mentioned, all this was not yet available when R started and already came with complex numbers as base type It may (or may not, I'm not the expert) be a bit challenging trying to remain back compatible (e.g. with save complex number R objects) and still use C standard complex headers ... But mid to long term I guess that would be the way to go. Martin > The complex numbers do indeed form a field, and Z*W > invokes an operation in that field when Z and W are both > complex numbers. Z*R and R*Z, where R is > real-but-not-complex, is not that field operation; it's > the scalar multiplication from the vector spec view. > One way to characterise the C and Ada view is that real > numbers x can be viewed as (x,ZERO!!!) and imaginary > numbers y*i can be viewed as (ZERO!!!, y) where ZERO!!! is > a real serious HARD zero, not an IEEE +epsilon or > -epsilon, In fact this is important for getting "sign of > zero" right. x + (u,v) = (x+u, v) *NOT* (x+u, v+0) and > this does matter in IEEE arithmetic. > R is of course based on S, and S was not only designed > before C got complex numbers, but before there was an IEEE > standard with things like NaN, Inf, and signed zeros But > there *is* an IEEE standard now, and even IBM mainframes > offer IEEE-compliant arithmetic, so worrying about the > sign of zero etc is not something we can really overlook > these days. > You are of course correct that the one-point > compactification of the complex numbers involves adjoining > just one infinity and that whacking IEEE infinities into > complex numbers does not give you anything mathematically > interesting (unless you count grief and vexation as > "interesting" (:-)). Since R distinguishes between 0+Infi > and NaN+Infi, it's not clear that the one-point > compactification has any relevance to what R does. And > it's not just an unexpected NaN; with all numbers finite > you can get zeros with the wrong sign. (S having been > designed before the sign of zero was something you needed > to be aware of.) > For what it's worth, the ISO "Language Independent > Arithmetic" standard, part 3, defines separate real, > imaginary, and complex types, and defines x*(z,w) to be > (x*z, x*w) directly, just like C and Ada. So it is quite > clear that R does not currently conform to LIA-3. LIA-3 > (ISO/IEC 10967-3:2006) is the nearest we have to a > definition of what "right" answers are for floating-point > complex arithmetic, and what R does cannot be called > "right" by that definition. But of course R doesn't claim > conformance to any part of the LIA standard. > Whether the R community *want* R and C to give the same > answers is not for me to say. I can only say that *I* > found it reassuring that C gave the expected answers when > R did not, or, to put it another way, disconcerting that R > did not agree with C (or LIA-3). Thank you. Indeed, I'd like the idea to consider LIA standards as much as (sensibly) possible. Martin > What really annoys me is that I wrote an entire technical > report on (some of the) problems with complex arithmetic, > and this whole "just treat x as (x, +0.0)" thing > completely failed to occur to me as something anyone might > do. > On Fri, 6 Sept 2024 at 20:37, Martin Maechler > wrote: >> >> > Richard O'Keefe > on Fri, 6 Sep 2024 17:24:07 >> +1200 writes: >> >> > The thing is that real*complex, complex*real, and >> complex/real are not > "complex arithmetic" in the >> requisite sense. >> >> > The complex numbers are a vector space over the reals, >> >> Yes, but they _also_ are field (and as others have argued >> mathematically only have one infinity point), and I think >> here we are fighting with which definition should take >> precedence here. The English Wikipedia page is even more >> extensive and precise, >> https://en.wikipedia.org/wiki/Complex_number (line >> breaking by me): >> >> " The complex numbers form a rich structure that is
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
It seems to me that the documentation of R's complex class & R's atan function do not tell us what to expect, so (as others have suggested), some additional notes are needed. I think that mathematically atan(1i) should be NA_complex_, but R seems not to use any mathematically standard compactification of the complex plane (and I'm not sure that IEEE does either). Incidentally, the signature of the complex constructor is confusing. complex(1L) returns zero, but complex(1L, argument=theta) is an element of the unit circle. The defaults suggest ambiguous results in case only length.out is specified, and you have to read a parenthesis in the details to figure out what will happen. Even then, the behaviour in my example is not spelled out (although it is suggested by negative inference). Moreover, the real & imaginary parts are ignored if either modulus or argument is provided, and I don't see that this is explained at all. R's numeric (& IEEE's floating-point types) seem to approximate a multi-point compactification of the real line. +Inf & -Inf fill out the approximation to the extended real line, and NaN, NA_real_ & maybe some others handle some cases in which the answer does not live in the extended real line. (I'm not digging into bit patterns here. I suspect that there are several versions of NaN, but I hope that they all behave the same way.) The documentation suggests that a complex scalar in R is just a pair of numeric scalars, so we are not dealing with the Riemann sphere or any other usually-studied extension of the complex plane. Since R distinguishes various complex infinities (and seems to allow any combination of numeric values in real & imaginary parts), the usual mathematical answer for atan(1i) may no longer be relevant. The tangent function has an essential singularity at complex infinity (the compactification point in the Riemann sphere, which I consider the natural extension for the study of meromorphic functions, for example making the tangent function well defined on the whole plane), so the usual extension of the plane does not give us an answer for atan(1i). However, another possible extension is the Cartesian square of the extended real line, and in that extension continuity suggests that tan(x + Inf*1i) = 1i and tan(x - Inf*1i) = -1i (for x real & finite). That is the result from R's tan function, and it explains why atan(1i) in R is not NA or NaN. The specific choice of pi/4 + Inf*1i puzzled me at first, but I think it's related to the branch-cut rules given in the documentation. The real part of atan((1+.Machine$double.eps)*1i) is pi/2, and the real part of atan((1-.Machine$double.eps)*1i) is zero, and someone apparently decided to average those for atan(1i). TL;DR: The documentation needs more details, and I don't really like the extended complex plane that R implemented, but within that framework the answers for atan(1i) & atan(-1i) make sense. Regards, Jorgen Harmse. [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
G.5.1 para 2 can be found in the C17 standard -- I actually have the final draft not the published standard. It's in earlier standards, I just didn't check earlier standards. Complex arithmetic was not in the first C standard (C89) but was in C99. The complex numbers do indeed form a field, and Z*W invokes an operation in that field when Z and W are both complex numbers. Z*R and R*Z, where R is real-but-not-complex, is not that field operation; it's the scalar multiplication from the vector spec view. One way to characterise the C and Ada view is that real numbers x can be viewed as (x,ZERO!!!) and imaginary numbers y*i can be viewed as (ZERO!!!, y) where ZERO!!! is a real serious HARD zero, not an IEEE +epsilon or -epsilon, In fact this is important for getting "sign of zero" right. x + (u,v) = (x+u, v) *NOT* (x+u, v+0) and this does matter in IEEE arithmetic. R is of course based on S, and S was not only designed before C got complex numbers, but before there was an IEEE standard with things like NaN, Inf, and signed zeros But there *is* an IEEE standard now, and even IBM mainframes offer IEEE-compliant arithmetic, so worrying about the sign of zero etc is not something we can really overlook these days. You are of course correct that the one-point compactification of the complex numbers involves adjoining just one infinity and that whacking IEEE infinities into complex numbers does not give you anything mathematically interesting (unless you count grief and vexation as "interesting" (:-)). Since R distinguishes between 0+Infi and NaN+Infi, it's not clear that the one-point compactification has any relevance to what R does. And it's not just an unexpected NaN; with all numbers finite you can get zeros with the wrong sign. (S having been designed before the sign of zero was something you needed to be aware of.) For what it's worth, the ISO "Language Independent Arithmetic" standard, part 3, defines separate real, imaginary, and complex types, and defines x*(z,w) to be (x*z, x*w) directly, just like C and Ada. So it is quite clear that R does not currently conform to LIA-3. LIA-3 (ISO/IEC 10967-3:2006) is the nearest we have to a definition of what "right" answers are for floating-point complex arithmetic, and what R does cannot be called "right" by that definition. But of course R doesn't claim conformance to any part of the LIA standard. Whether the R community *want* R and C to give the same answers is not for me to say. I can only say that *I* found it reassuring that C gave the expected answers when R did not, or, to put it another way, disconcerting that R did not agree with C (or LIA-3). What really annoys me is that I wrote an entire technical report on (some of the) problems with complex arithmetic, and this whole "just treat x as (x, +0.0)" thing completely failed to occur to me as something anyone might do. On Fri, 6 Sept 2024 at 20:37, Martin Maechler wrote: > > > Richard O'Keefe > > on Fri, 6 Sep 2024 17:24:07 +1200 writes: > > > The thing is that real*complex, complex*real, and complex/real are not > > "complex arithmetic" in the requisite sense. > > > The complex numbers are a vector space over the reals, > > Yes, but they _also_ are field (and as others have argued mathematically only > have one infinity point), > and I think here we are fighting with which definition should > take precedence here. > The English Wikipedia page is even more extensive and precise, > https://en.wikipedia.org/wiki/Complex_number (line breaking by me): > > " The complex numbers form a rich structure that is simultaneously > - an algebraically closed field, > - a commutative algebra over the reals, and > - a Euclidean vector space of dimension two." > > our problem "of course" is that we additionally add +/- Inf for > the reals and for storage etc treating them as a 2D vector space > over the reals is "obvious". > > > and complex*real and real*complex are vector*scalar and scalar*vector. > > For example, in the Ada programming language, we have > > function "*" (Left, Right : Complex) return Complex; > > function "*" (Left : Complex; Right : Real'Base) return Complex; > > function "*" (Left : Real'Base; Right : Complex) return Complex; > > showing that Z*R and Z*W involve *different* functions. > > > It's worth noting that complex*real and real*complex just require two > > real multiplications, > > no other arithmetic operations, while complex*complex requires four > > real multiplications, > > an addition, and a subtraction. So implementing complex*real by > > conventing the real > > to complex is inefficient (as well as getting the finer points of IEEE > > arithmetic wrong). > > I see your point. > > > As for complex division, getting that *right* in floating-point is > > fiendishly difficult (there are > > lots of algorithms out there and the majority of them have serious > flaws)
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> Duncan Murdoch
> on Fri, 6 Sep 2024 05:54:23 -0400 writes:
> On 2024-09-06 12:44 a.m., Richard O'Keefe wrote:
>> I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 +
>> infinity i)/5 = (0 + infinity i).
>> Here's what I get in C:
>> (0,1) = (0, 1)
>> atan((0,1)) = (0, inf)
>> atan((0,1))/5 = (0, inf)
>>
>> Note the difference between I*infinity = (0,1)*infinity =
>> (0*infinity,1*infinity) = (NaN,infinity)
>> and (0,infinity)/5 = (0/5,infinity/5) = (0,infinity).
>> The former involves multiplying 0 by infinity, which yields NaN.
>> The latter does not.
>>
>>> complex(1,0,Inf)*2
>> [1] NaN+Infi
>> There is no good reason for this. 0*2 is 0, not NaN.
>>
>> In IEEE arithmetic, multiplying or dividing a complex number by a real
number is
>> NOT the same as multiplying or dividing by the complex version of that
>> real number.
>> (0,Inf) * 2= (0*2, Inf*2) = (0, Inf).
>> (0,Inf) * (2,0) = (0*2 - Inf*0, 0*0 + Inf*2) = (NaN, Inf).
>>
>> There really truly is a bug here, and it is treating R*Z, Z*R, and Z/R
>> as if they were
>> the same as W*Z, Z*W, and Z/W where W = complex(1,R,0).
> I would only disagree with the statement above by distinguishing between
> a "bug" (where R is not behaving as documented) and a "design flaw"
> (where it is behaving as documented, but the behaviour is undesirable).
> I think this is a design flaw rather than a bug.
> The distinction is important: if it is a design flaw, then a change is
> harder, because users who rely on the behaviour deserve more help in
> adapting than those who rely on a bug. Bugs should be fixed. Design
> flaws need thinking about, and sometimes shouldn't be fixed.
> On the other hand, I was unable to find documentation saying that the
> current behaviour is intended, so I could be wrong.
> Duncan Murdoch
I agree 100% (with Duncan).
I've now also carefully read ?Arithmetic and ?complex
and could not find docu explicitly documenting the current
behavior, in the context of complex arithmetic not even
mentioning the "overall principle" used very often in R to
1. coerce to common type
2. then compute with that "pure type"
In ?complex, we have the (last sentence of the first) 'Note:'
---> For ‘+’ and ‘-’, R's own handling works strictly “coordinate wise”.
now, implicitly that implies that {+, -} are the only
ops/functions where coordinate-wise arithmetic is used/applied
and hence could it be _stretched_ to say that for
* and / coordinate wise does not always apply,
in our case not even when it would make sense, i.e., when one of
the two operands is real (in the '/' case, it must be the 2nd operand)
and hence 2d-vector space arithmetic
should be applied naturally.
It is still true that this must be considered a design flaw
rather than a bug, even if only because the above "overall
principle" is predominant and tought very often when teaching R.
In this case, I do think we should look into the consequences of
indeed distinguishing
*
* and
/
from their respective current {1. coerce to complex, 2. use complex arith}
arithmetic.
Hence, thanks a lot for bringing this up, to Leo Mada and
notably to Richard O'Keefe for providing context, notably wrt
to C standards {which I'd want to follow mostly, but not
always ... but I'm not opening that now}...
Martin
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On 2024-09-06 12:44 a.m., Richard O'Keefe wrote: I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + infinity i)/5 = (0 + infinity i). Here's what I get in C: (0,1) = (0, 1) atan((0,1)) = (0, inf) atan((0,1))/5 = (0, inf) Note the difference between I*infinity = (0,1)*infinity = (0*infinity,1*infinity) = (NaN,infinity) and (0,infinity)/5 = (0/5,infinity/5) = (0,infinity). The former involves multiplying 0 by infinity, which yields NaN. The latter does not. complex(1,0,Inf)*2 [1] NaN+Infi There is no good reason for this. 0*2 is 0, not NaN. In IEEE arithmetic, multiplying or dividing a complex number by a real number is NOT the same as multiplying or dividing by the complex version of that real number. (0,Inf) * 2 = (0*2, Inf*2) = (0, Inf). (0,Inf) * (2,0) = (0*2 - Inf*0, 0*0 + Inf*2) = (NaN, Inf). There really truly is a bug here, and it is treating R*Z, Z*R, and Z/R as if they were the same as W*Z, Z*W, and Z/W where W = complex(1,R,0). I would only disagree with the statement above by distinguishing between a "bug" (where R is not behaving as documented) and a "design flaw" (where it is behaving as documented, but the behaviour is undesirable). I think this is a design flaw rather than a bug. The distinction is important: if it is a design flaw, then a change is harder, because users who rely on the behaviour deserve more help in adapting than those who rely on a bug. Bugs should be fixed. Design flaws need thinking about, and sometimes shouldn't be fixed. On the other hand, I was unable to find documentation saying that the current behaviour is intended, so I could be wrong. Duncan Murdoch On Fri, 6 Sept 2024 at 10:12, Bert Gunter wrote: Perhaps Inf*1i [1] NaN+Infi clarifies why it is *not* a bug. (Boy, did that jog some long dusty math memories :-) ) -- Bert On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch wrote: On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: Dear R Users, Is this desired behaviour? I presume it's a bug. atan(1i) # 0+Infi tan(atan(1i)) # 0+1i atan(1i) / 5 # NaN+Infi There's no need to involve atan() and tan() in this: > (0+Inf*1i)/5 [1] NaN+Infi Why do you think this is a bug? Duncan Murdoch __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> Richard O'Keefe > on Fri, 6 Sep 2024 17:24:07 +1200 writes: > The thing is that real*complex, complex*real, and complex/real are not > "complex arithmetic" in the requisite sense. > The complex numbers are a vector space over the reals, Yes, but they _also_ are field (and as others have argued mathematically only have one infinity point), and I think here we are fighting with which definition should take precedence here. The English Wikipedia page is even more extensive and precise, https://en.wikipedia.org/wiki/Complex_number (line breaking by me): " The complex numbers form a rich structure that is simultaneously - an algebraically closed field, - a commutative algebra over the reals, and - a Euclidean vector space of dimension two." our problem "of course" is that we additionally add +/- Inf for the reals and for storage etc treating them as a 2D vector space over the reals is "obvious". > and complex*real and real*complex are vector*scalar and scalar*vector. > For example, in the Ada programming language, we have > function "*" (Left, Right : Complex) return Complex; > function "*" (Left : Complex; Right : Real'Base) return Complex; > function "*" (Left : Real'Base; Right : Complex) return Complex; > showing that Z*R and Z*W involve *different* functions. > It's worth noting that complex*real and real*complex just require two > real multiplications, > no other arithmetic operations, while complex*complex requires four > real multiplications, > an addition, and a subtraction. So implementing complex*real by > conventing the real > to complex is inefficient (as well as getting the finer points of IEEE > arithmetic wrong). I see your point. > As for complex division, getting that *right* in floating-point is > fiendishly difficult (there are > lots of algorithms out there and the majority of them have serious flaws) > and woefully costly. > It's not unfair to characterise implementing complex/real > by conversion to complex and doing complex/complex as a > beginner's bungle. ouch! ... but still I tend to acknowledge your point, incl the "not unfair" .. > There are good reasons why "double", "_Imaginary double", and "_Complex double" > are distinct types in standard C (as they are in Ada), interesting. OTOH, I think standard C did not have strict standards about complex number storage etc in the mid 1990s when R was created. > and the definition of multiplication > in G.5.1 para 2 is *direct* (not via complex*complex). I see (did not know about) -- where can we find 'G.5.1 para 2' > Now R has its own way of doing things, and if the judgement of the R > maintainers is > that keeping the "convert to a common type and then operate" model is > more important > than getting good answers, well, it's THEIR language, not mine. Well, it should also be the R community's language, where we, the R core team, do most of the "base" work and also emphasize guaranteeing long term stability. Personally, I think that "convert to a common type and then operate" is a good rule and principle in many, even most places and cases, but I hate it if humans should not be allowed to break good rules for even better reasons (but should rather behave like algorithms ..). This may well be a very good example of re-considering. As mentioned above, e.g., I was not aware of the C language standard being so specific here and different than what we've been doing in R. > But let's not pretend > that the answers are *right* in any other sense. I think that's too strong -- Jeff's computation (just here below) is showing one well defined sense of "right" I'd say. (Still I know and agree theInf * 0 |--> NaN rule *is* sometimes undesirable) > On Fri, 6 Sept 2024 at 11:07, Jeff Newmiller via R-help > wrote: >> >> atan(1i) -> 0 + Inf i >> complex(1/5) -> 0.2 + 0i >> atan(1i) -> (0 + Inf i) * (0.2 + 0i) -> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i >> infinity times zero is undefined -> 0 + 0i + Inf i + NaN * i^2 -> 0 + 0i + Inf i - NaN -> NaN + Inf i >> >> I am not sure how complex arithmetic could arrive at another answer. >> >> I advise against messing with infinities... use atan2() if you don't actually need complex arithmetic. >> >> On September 5, 2024 3:38:33 PM PDT, Bert Gunter wrote: >> >> complex(real = 0, imaginary = Inf) >> >[1] 0+Infi >> > >> >> Inf*1i >> >[1] NaN+Infi >> > >> >>> complex(real = 0, imaginary = Inf)/5 >> >[1] NaN+Infi >> > >> >See the Note in ?complex for the explanation, I think. Duncan can correct >> >if I'm wrong. >> > >> >-- Bert [...] Martin -- Martin Maechler ETH Zurich and R Core team __ [email protected] maili
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
The thing is that real*complex, complex*real, and complex/real are not "complex arithmetic" in the requisite sense. The complex numbers are a vector space over the reals, and complex*real and real*complex are vector*scalar and scalar*vector. For example, in the Ada programming language, we have function "*" (Left, Right : Complex) return Complex; function "*" (Left : Complex; Right : Real'Base) return Complex; function "*" (Left : Real'Base; Right : Complex) return Complex; showing that Z*R and Z*W involve *different* functions. It's worth noting that complex*real and real*complex just require two real multiplications, no other arithmetic operations, while complex*complex requires four real multiplications, an addition, and a subtraction. So implementing complex*real by conventing the real to complex is inefficient (as well as getting the finer points of IEEE arithmetic wrong). As for comple division, getting that *right* in floating-point is fiendishly difficult (there are lots of algorithms out there and the majority of them have serious flaws) and woefully costly. It's not unfair to characterise implementing complex/real by conversion to complex and doing complex/complex as a beginner's bungle. There are good reasons why "double", "_Imaginary double", and "_Complex double" are distinct types in standard C (as they are in Ada), and the definition of multiplication in G.5.1 para 2 is *direct* (not via complex*complex). Now R has its own way of doing things, and if the judgement of the R maintainers is that keeping the "convert to a common type and then operate" model is more important than getting good answers, well, it's THEIR language, not mine. But let's not pretend that the answers are *right* in any other sense. On Fri, 6 Sept 2024 at 11:07, Jeff Newmiller via R-help wrote: > > atan(1i) -> 0 + Inf i > complex(1/5) -> 0.2 + 0i > atan(1i) -> (0 + Inf i) * (0.2 + 0i) > -> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i > infinity times zero is undefined > -> 0 + 0i + Inf i + NaN * i^2 > -> 0 + 0i + Inf i - NaN > -> NaN + Inf i > > I am not sure how complex arithmetic could arrive at another answer. > > I advise against messing with infinities... use atan2() if you don't actually > need complex arithmetic. > > On September 5, 2024 3:38:33 PM PDT, Bert Gunter > wrote: > >> complex(real = 0, imaginary = Inf) > >[1] 0+Infi > > > >> Inf*1i > >[1] NaN+Infi > > > >>> complex(real = 0, imaginary = Inf)/5 > >[1] NaN+Infi > > > >See the Note in ?complex for the explanation, I think. Duncan can correct > >if I'm wrong. > > > >-- Bert > > > >On Thu, Sep 5, 2024 at 3:20 PM Leo Mada wrote: > > > >> Dear Bert, > >> > >> These behave like real divisions/multiplications: > >> complex(re=Inf, im = Inf) * 5 > >> # Inf+Infi > >> complex(re=-Inf, im = Inf) * 5 > >> # -Inf+Infi > >> > >> The real division / multiplication should be faster and also is well > >> behaved. I was expecting R to do the real division/multiplication on a > >> complex number. Which R actually does for these very particular cases; but > >> not when only Im(x) is Inf. > >> > >> Sincerely, > >> > >> Leonard > >> > >> -- > >> *From:* Bert Gunter > >> *Sent:* Friday, September 6, 2024 1:12 AM > >> *To:* Duncan Murdoch > >> *Cc:* Leo Mada ; [email protected] < > >> [email protected]> > >> *Subject:* Re: [R] BUG: atan(1i) / 5 = NaN+Infi ? > >> > >> Perhaps > >> > >> > Inf*1i > >> [1] NaN+Infi > >> > >> clarifies why it is *not* a bug. > >> (Boy, did that jog some long dusty math memories :-) ) > >> > >> -- Bert > >> > >> On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch > >> wrote: > >> > >> On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > >> > Dear R Users, > >> > > >> > Is this desired behaviour? > >> > I presume it's a bug. > >> > > >> > atan(1i) > >> > # 0+Infi > >> > > >> > tan(atan(1i)) > >> > # 0+1i > >> > > >> > atan(1i) / 5 > >> > # NaN+Infi > >> > >> There's no need to involve atan() and tan() in this: > >> > >> > (0+Inf*1i)/5 > >> [1] NaN+Infi > >> > >> Why do you think this is a bug? > >> > >> Du
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + infinity i)/5 = (0 + infinity i). Here's what I get in C: (0,1) = (0, 1) atan((0,1)) = (0, inf) atan((0,1))/5 = (0, inf) Note the difference between I*infinity = (0,1)*infinity = (0*infinity,1*infinity) = (NaN,infinity) and (0,infinity)/5 = (0/5,infinity/5) = (0,infinity). The former involves multiplying 0 by infinity, which yields NaN. The latter does not. > complex(1,0,Inf)*2 [1] NaN+Infi There is no good reason for this. 0*2 is 0, not NaN. In IEEE arithmetic, multiplying or dividing a complex number by a real number is NOT the same as multiplying or dividing by the complex version of that real number. (0,Inf) * 2 = (0*2, Inf*2) = (0, Inf). (0,Inf) * (2,0) = (0*2 - Inf*0, 0*0 + Inf*2) = (NaN, Inf). There really truly is a bug here, and it is treating R*Z, Z*R, and Z/R as if they were the same as W*Z, Z*W, and Z/W where W = complex(1,R,0). On Fri, 6 Sept 2024 at 10:12, Bert Gunter wrote: > > Perhaps > > > Inf*1i > [1] NaN+Infi > > clarifies why it is *not* a bug. > (Boy, did that jog some long dusty math memories :-) ) > > -- Bert > > On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch > wrote: > > > On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > > > Dear R Users, > > > > > > Is this desired behaviour? > > > I presume it's a bug. > > > > > > atan(1i) > > > # 0+Infi > > > > > > tan(atan(1i)) > > > # 0+1i > > > > > > atan(1i) / 5 > > > # NaN+Infi > > > > There's no need to involve atan() and tan() in this: > > > > > (0+Inf*1i)/5 > > [1] NaN+Infi > > > > Why do you think this is a bug? > > > > Duncan Murdoch > > > > __ > > [email protected] mailing list -- To UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide > > https://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > > > > [[alternative HTML version deleted]] > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> x <- complex(imag = Inf) > x [1] 0+Infi > x*1 [1] NaN+Infi > x+0 [1] 0+Infi R does the addition and subtraction "coordinatewise"; the C library handles everything else. This results in 2 different ways the point at infinity is printed. (Correction requested if this is wrong) Bert On Thu, Sep 5, 2024 at 4:07 PM Jeff Newmiller via R-help < [email protected]> wrote: > atan(1i) -> 0 + Inf i > complex(1/5) -> 0.2 + 0i > atan(1i) -> (0 + Inf i) * (0.2 + 0i) > -> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i > infinity times zero is undefined > -> 0 + 0i + Inf i + NaN * i^2 > -> 0 + 0i + Inf i - NaN > -> NaN + Inf i > > I am not sure how complex arithmetic could arrive at another answer. > > I advise against messing with infinities... use atan2() if you don't > actually need complex arithmetic. > > On September 5, 2024 3:38:33 PM PDT, Bert Gunter > wrote: > >> complex(real = 0, imaginary = Inf) > >[1] 0+Infi > > > >> Inf*1i > >[1] NaN+Infi > > > >>> complex(real = 0, imaginary = Inf)/5 > >[1] NaN+Infi > > > >See the Note in ?complex for the explanation, I think. Duncan can correct > >if I'm wrong. > > > >-- Bert > > > >On Thu, Sep 5, 2024 at 3:20 PM Leo Mada wrote: > > > >> Dear Bert, > >> > >> These behave like real divisions/multiplications: > >> complex(re=Inf, im = Inf) * 5 > >> # Inf+Infi > >> complex(re=-Inf, im = Inf) * 5 > >> # -Inf+Infi > >> > >> The real division / multiplication should be faster and also is well > >> behaved. I was expecting R to do the real division/multiplication on a > >> complex number. Which R actually does for these very particular cases; > but > >> not when only Im(x) is Inf. > >> > >> Sincerely, > >> > >> Leonard > >> > >> -- > >> *From:* Bert Gunter > >> *Sent:* Friday, September 6, 2024 1:12 AM > >> *To:* Duncan Murdoch > >> *Cc:* Leo Mada ; [email protected] < > >> [email protected]> > >> *Subject:* Re: [R] BUG: atan(1i) / 5 = NaN+Infi ? > >> > >> Perhaps > >> > >> > Inf*1i > >> [1] NaN+Infi > >> > >> clarifies why it is *not* a bug. > >> (Boy, did that jog some long dusty math memories :-) ) > >> > >> -- Bert > >> > >> On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch > > >> wrote: > >> > >> On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > >> > Dear R Users, > >> > > >> > Is this desired behaviour? > >> > I presume it's a bug. > >> > > >> > atan(1i) > >> > # 0+Infi > >> > > >> > tan(atan(1i)) > >> > # 0+1i > >> > > >> > atan(1i) / 5 > >> > # NaN+Infi > >> > >> There's no need to involve atan() and tan() in this: > >> > >> > (0+Inf*1i)/5 > >> [1] NaN+Infi > >> > >> Why do you think this is a bug? > >> > >> Duncan Murdoch > >> > >> __ > >> [email protected] mailing list -- To UNSUBSCRIBE and more, see > >> https://stat.ethz.ch/mailman/listinfo/r-help > >> PLEASE do read the posting guide > >> https://www.R-project.org/posting-guide.html > >> and provide commented, minimal, self-contained, reproducible code. > >> > >> > > > > [[alternative HTML version deleted]] > > > >__ > >[email protected] mailing list -- To UNSUBSCRIBE and more, see > >https://stat.ethz.ch/mailman/listinfo/r-help > >PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > >and provide commented, minimal, self-contained, reproducible code. > > -- > Sent from my phone. Please excuse my brevity. > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On 2024-09-05 6:12 p.m., Leo Mada wrote:
Dear Duncan,
Here is also the missing information:
R version 4.4.1 (2024-06-14 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 10 x64 (build 19045)
Regarding the results:
atan(1i)
# 0+Infi
Re(atan(1i))
# 0
Im(atan(1i))
# Inf
0 + Inf i is a valid complex number:
tan(atan(1i))
# 0+1i
Inf / 5
# Inf
Note: atan(1i) / 5 should have generated 0 + Inf * 1i; even the explicit
complex number fails:
complex(re=0, im = Inf) / 5
# NaN+Infi
complex(re=Inf, im = Inf) / 5
# Inf+Infi
I presume that R tries to do the complex division, although the real
division is well defined.
I imagine that what happens is that when one operand is complex, both
are coerced to complex and the operation is carried out. I had assumed
this was documented in ?complex, but I don't see it there. Maybe it
should be.
If you want z/5 to be carried out using the correct mathematical
approach, you'll probably have to define it yourself. For example,
CxByReal <- function(num, denom) {
if (is.complex(denom)) stop("this is for a real denominator!")
complex(real = Re(num)/denom, imaginary = Im(num)/denom)
}
CxByReal(complex(real=0, imaginary=Inf), 5)
# [1] 0+Infi
Duncan Murdoch
Sincerely,
Leonard
*From:* Duncan Murdoch
*Sent:* Friday, September 6, 2024 12:40 AM
*To:* Leo Mada ; [email protected]
*Subject:* Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote:
Dear R Users,
Is this desired behaviour?
I presume it's a bug.
atan(1i)
# 0+Infi
tan(atan(1i))
# 0+1i
atan(1i) / 5
# NaN+Infi
There's no need to involve atan() and tan() in this:
> (0+Inf*1i)/5
[1] NaN+Infi
Why do you think this is a bug?
Duncan Murdoch
__
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
atan(1i) -> 0 + Inf i complex(1/5) -> 0.2 + 0i atan(1i) -> (0 + Inf i) * (0.2 + 0i) -> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i infinity times zero is undefined -> 0 + 0i + Inf i + NaN * i^2 -> 0 + 0i + Inf i - NaN -> NaN + Inf i I am not sure how complex arithmetic could arrive at another answer. I advise against messing with infinities... use atan2() if you don't actually need complex arithmetic. On September 5, 2024 3:38:33 PM PDT, Bert Gunter wrote: >> complex(real = 0, imaginary = Inf) >[1] 0+Infi > >> Inf*1i >[1] NaN+Infi > >>> complex(real = 0, imaginary = Inf)/5 >[1] NaN+Infi > >See the Note in ?complex for the explanation, I think. Duncan can correct >if I'm wrong. > >-- Bert > >On Thu, Sep 5, 2024 at 3:20 PM Leo Mada wrote: > >> Dear Bert, >> >> These behave like real divisions/multiplications: >> complex(re=Inf, im = Inf) * 5 >> # Inf+Infi >> complex(re=-Inf, im = Inf) * 5 >> # -Inf+Infi >> >> The real division / multiplication should be faster and also is well >> behaved. I was expecting R to do the real division/multiplication on a >> complex number. Which R actually does for these very particular cases; but >> not when only Im(x) is Inf. >> >> Sincerely, >> >> Leonard >> >> ------------------ >> *From:* Bert Gunter >> *Sent:* Friday, September 6, 2024 1:12 AM >> *To:* Duncan Murdoch >> *Cc:* Leo Mada ; [email protected] < >> [email protected]> >> *Subject:* Re: [R] BUG: atan(1i) / 5 = NaN+Infi ? >> >> Perhaps >> >> > Inf*1i >> [1] NaN+Infi >> >> clarifies why it is *not* a bug. >> (Boy, did that jog some long dusty math memories :-) ) >> >> -- Bert >> >> On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch >> wrote: >> >> On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: >> > Dear R Users, >> > >> > Is this desired behaviour? >> > I presume it's a bug. >> > >> > atan(1i) >> > # 0+Infi >> > >> > tan(atan(1i)) >> > # 0+1i >> > >> > atan(1i) / 5 >> > # NaN+Infi >> >> There's no need to involve atan() and tan() in this: >> >> > (0+Inf*1i)/5 >> [1] NaN+Infi >> >> Why do you think this is a bug? >> >> Duncan Murdoch >> >> __ >> [email protected] mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide >> https://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> >> > > [[alternative HTML version deleted]] > >__ >[email protected] mailing list -- To UNSUBSCRIBE and more, see >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide https://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code. -- Sent from my phone. Please excuse my brevity. __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
> complex(real = 0, imaginary = Inf) [1] 0+Infi > Inf*1i [1] NaN+Infi >> complex(real = 0, imaginary = Inf)/5 [1] NaN+Infi See the Note in ?complex for the explanation, I think. Duncan can correct if I'm wrong. -- Bert On Thu, Sep 5, 2024 at 3:20 PM Leo Mada wrote: > Dear Bert, > > These behave like real divisions/multiplications: > complex(re=Inf, im = Inf) * 5 > # Inf+Infi > complex(re=-Inf, im = Inf) * 5 > # -Inf+Infi > > The real division / multiplication should be faster and also is well > behaved. I was expecting R to do the real division/multiplication on a > complex number. Which R actually does for these very particular cases; but > not when only Im(x) is Inf. > > Sincerely, > > Leonard > > -- > *From:* Bert Gunter > *Sent:* Friday, September 6, 2024 1:12 AM > *To:* Duncan Murdoch > *Cc:* Leo Mada ; [email protected] < > [email protected]> > *Subject:* Re: [R] BUG: atan(1i) / 5 = NaN+Infi ? > > Perhaps > > > Inf*1i > [1] NaN+Infi > > clarifies why it is *not* a bug. > (Boy, did that jog some long dusty math memories :-) ) > > -- Bert > > On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch > wrote: > > On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > > Dear R Users, > > > > Is this desired behaviour? > > I presume it's a bug. > > > > atan(1i) > > # 0+Infi > > > > tan(atan(1i)) > > # 0+1i > > > > atan(1i) / 5 > > # NaN+Infi > > There's no need to involve atan() and tan() in this: > > > (0+Inf*1i)/5 > [1] NaN+Infi > > Why do you think this is a bug? > > Duncan Murdoch > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > > [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
Dear Bert, These behave like real divisions/multiplications: complex(re=Inf, im = Inf) * 5 # Inf+Infi complex(re=-Inf, im = Inf) * 5 # -Inf+Infi The real division / multiplication should be faster and also is well behaved. I was expecting R to do the real division/multiplication on a complex number. Which R actually does for these very particular cases; but not when only Im(x) is Inf. Sincerely, Leonard From: Bert Gunter Sent: Friday, September 6, 2024 1:12 AM To: Duncan Murdoch Cc: Leo Mada ; [email protected] Subject: Re: [R] BUG: atan(1i) / 5 = NaN+Infi ? Perhaps > Inf*1i [1] NaN+Infi clarifies why it is *not* a bug. (Boy, did that jog some long dusty math memories :-) ) -- Bert On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch mailto:[email protected]>> wrote: On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > Dear R Users, > > Is this desired behaviour? > I presume it's a bug. > > atan(1i) > # 0+Infi > > tan(atan(1i)) > # 0+1i > > atan(1i) / 5 > # NaN+Infi There's no need to involve atan() and tan() in this: > (0+Inf*1i)/5 [1] NaN+Infi Why do you think this is a bug? Duncan Murdoch __ [email protected]<mailto:[email protected]> mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
Perhaps > Inf*1i [1] NaN+Infi clarifies why it is *not* a bug. (Boy, did that jog some long dusty math memories :-) ) -- Bert On Thu, Sep 5, 2024 at 2:48 PM Duncan Murdoch wrote: > On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > > Dear R Users, > > > > Is this desired behaviour? > > I presume it's a bug. > > > > atan(1i) > > # 0+Infi > > > > tan(atan(1i)) > > # 0+1i > > > > atan(1i) / 5 > > # NaN+Infi > > There's no need to involve atan() and tan() in this: > > > (0+Inf*1i)/5 > [1] NaN+Infi > > Why do you think this is a bug? > > Duncan Murdoch > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: Dear R Users, Is this desired behaviour? I presume it's a bug. atan(1i) # 0+Infi tan(atan(1i)) # 0+1i atan(1i) / 5 # NaN+Infi There's no need to involve atan() and tan() in this: > (0+Inf*1i)/5 [1] NaN+Infi Why do you think this is a bug? Duncan Murdoch __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?
What version of R are you using and on what platform? I get: > atan(1i) [1] 0.7853982+Infi > atan(1i)/5 [1] NaN+Infi on: R version 4.4.1 (2024-06-14) Platform: aarch64-apple-darwin20 Running under: macOS Sonoma 14.6.1 -- Bert On Thu, Sep 5, 2024 at 1:23 PM Leo Mada via R-help wrote: > Dear R Users, > > Is this desired behaviour? > I presume it's a bug. > > atan(1i) > # 0+Infi > > tan(atan(1i)) > # 0+1i > > atan(1i) / 5 > # NaN+Infi > > There were some changes in handling of complex numbers. But it looks like > a bug. > > Sincerely, > > Leonard > > > [[alternative HTML version deleted]] > > __ > [email protected] mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide > https://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > [[alternative HTML version deleted]] __ [email protected] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
