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

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 :

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()

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

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

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

Thank you, Marttila and Ivan, As the original author of prettyNum() {etc ..}, I will commit such a bug fix to R-devel (and probably port it to R 4.5.0 patched) quite soon (but not yet today). Best regards, Martin Maechler >>>>> Ivan Krylov via R-devel >>>>> on Fri, 23 May 2025 17:14:57 +0300 writes: > ? Fri, 23 May 2025 11:47:33 +0000 >

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

? Fri, 23 May 2025 11:47:33 +0000 Marttila Mikko via R-devel <r-devel at r-project.org> ?????: > When called with a numeric vector, the `replace.zero` argument is > disregarded. > > > prettyNum(0, zero.print = "- ", replace.zero = TRUE) > [1] "-" > Warning message: > In .format.zeros(x, zero.print, replace = replace.zero) : >

Thanks for the contribution Mikko! For testing future patches, you can actually do it right in the web browser, thanks to Heather Turner's R Dev Container, see instructions here https://contributor.r-project.org/r-dev-env/container_setup/ Best Toby On Mon, May 26, 2025 at 6:28?PM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Thank you, Marttila and Ivan, > > As

Tim, The purpose of the `replace.zero` argument is to allow longer replacements. See for example the behaviour with a character vector input: > prettyNum("0", zero.print = "- ", replace.zero = TRUE) [1] "- " I'm pretty sure this is a bug, and have now posted the relevant details on r-devel. A fix would be below. Best, Mikko diff --git

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

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 list, I'd like to report a bug in `prettyNum()`. When called with a numeric vector, the `replace.zero` argument is disregarded. > prettyNum(0, zero.print = "- ", replace.zero = TRUE) [1] "-" Warning message: In .format.zeros(x, zero.print, replace = replace.zero) : 'zero.print' is truncated to fit into formatted zeros; consider 'replace=TRUE' A