similar to: R 2.12.2 is released

> 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 <leo.mada at syonic.eu> wrote: > Dear Bert, > > These behave like real divisions/multiplications: >

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:

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.

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

Thank you, Robert for raising this here ! >>>>> Robert McGehee >>>>> on Thu, 21 Mar 2019 20:56:19 +0000 writes: > R developers, > Seems I get a bad result ("%#4.0-1e" in particular) when trying to use prettyNum digits=0 with scientific notation. I tried on both my Linux box and on an online R evaluator and saw the same problem, so

>>>>> peter dalgaard >>>>> on Fri, 22 Mar 2019 17:30:19 +0100 writes: > FWIW, it doesn't seem to be happening on Mac OS: >> format(2^30, digits=0) > [1] "1.e+09" >> prettyNum(12345.6, digits=0) > [1] "1.e+04" > A glibc misfeature? It seems (and note we are talking about format.default()

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 :

FWIW, it doesn't seem to be happening on Mac OS: > format(2^30, digits=0) [1] "1.e+09" > prettyNum(12345.6, digits=0) [1] "1.e+04" A glibc misfeature? -pd > On 22 Mar 2019, at 10:10 , Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > Thank you, Robert for raising this here ! > >>>>>> Robert McGehee

Dear developeRs, I've searched the documentation, FAQ, and mailing lists, but haven't found the answer(*) to the following: When should one specify LazyLoad, LazyData, and ZipData? And what is the default if they are left unspecified? (*)Except that 1) If the package you are writing uses the methods package, specify LazyLoad: yes, and 2) The optional ZipData field controls whether the

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

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 <murdoch.duncan at gmail.com> 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. > >

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

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

R developers, Seems I get a bad result ("%#4.0-1e" in particular) when trying to use prettyNum digits=0 with scientific notation. I tried on both my Linux box and on an online R evaluator and saw the same problem, so it's not limited to my box at least. I see the problem in both R 3.5.3 and R 3.3.2. options(scipen=-100) prettyNum(1, digits=0) [1] "%#4.0-1e" prettyNum(2,

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]]

Under R-1.5.0 on Solaris 2.6: R> prettyNum(123456789, big.mark=",") [1] ",123,456,789" and that bad behavior (leading comma) spills into formatC as well: R> formatC(123456789, digits=0, format="f", big.mark=",") [1] ",123,456,789" Looks to me like a bug in src/library/base/R/format.R, in function prettyNum: B.[i.big] <-

Full_Name: Henric Nilsson Version: 2.2.0 (2005-06-20 r34776) OS: Windows 2000 Submission from: (NULL) (213.115.23.26) The help page for `weighted.residuals' states that the function can be used with both `lm' and `glm' objects. However, it's unclear what's meant by the following passage "Weighted residuals are the usual residuals Ri, multiplied by wi^0.5, where wi are

Hi! If I use format() on numeric vector, na.encode argument does not have any e= ffect. This was reported before: - https://stat.ethz.ch/pipermail/r-help/2007-October/143881.html - http://tolstoy.newcastle.edu.au/R/e2/devel/06/09/0360.html It works for other (say character) classes! > format(c("a", NA), na.encode=3DTRUE) [1] "a " "NA" >

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,

Hi -- I'm looking for alternatives to regex for a fairly simply 'reformatting' problem. Alternatives only because a lot of folks have trouble parsing/interpreting regex expressions, and I'm looking for suggestions for something more 'transparent'. Here is an example of what I'm trying to do. Take the following string, which I call x, and for each character in the