search for: syonic

> 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: > 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 expec...

...i > >> 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: >> complex(re=Inf, im = Inf) * 5 >> # Inf+Infi >> complex(re=-Inf, im = Inf) * 5 >> # -Inf+Infi >> >> The real division / multiplication should be faster an...

...oes for these very particular cases; but not when only Im(x) is Inf. Sincerely, Leonard ________________________________ From: Bert Gunter <bgunter.4567 at gmail.com> Sent: Friday, September 6, 2024 1:12 AM To: Duncan Murdoch <murdoch.duncan at gmail.com> Cc: Leo Mada <leo.mada at syonic.eu>; r-help at r-project.org <r-help at r-project.org> 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 <mu...

...ger than Cutoff, sorting Cutoff is the expensive part e.g O(nlog2(n) for Quicksort (n = length Cutoff). I believe looping is O(n^2). Jeff's approach using findInterval may be faster. Of course implementation details matter. -- Bert On Mon, Oct 16, 2023 at 4:41?AM Leonard Mada <leo.mada at syonic.eu> wrote: > > Dear Jason, > > The code could look something like: > > dummyData = data.frame(Tract=seq(1, 10, by=1), > Pct = c(0.05,0.03,0.01,0.12,0.21,0.04,0.07,0.09,0.06,0.03), > Totpop = c(4000,3500,4500,4100,3900,4250,5100,4700,4950,4800)) > > # Defin...

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

...> >>> 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: > >> complex(re=Inf, im = Inf) * 5 > >> # Inf+Infi > >> complex(re=-Inf, im = Inf) * 5 > >> # -Inf+Infi > >> > >> The...

Dear Akshay, The best response was given by Andrew. "{...}" is not a closure. This is unusual for someone used to C-type languages. But I will try to explain some of the rationale. In the case that "{...}" was a closure, then external variables would need to be explicitly declared before the closure (in order to reuse those values): intermediate = c() { ??? intermediate

...1] 0+Infi Duncan Murdoch > > Sincerely, > > Leonard > > ------------------------------------------------------------------------ > *From:* Duncan Murdoch <murdoch.duncan at gmail.com> > *Sent:* Friday, September 6, 2024 12:40 AM > *To:* Leo Mada <leo.mada at syonic.eu>; r-help at r-project.org > <r-help at r-project.org> > *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. >> &gt...

? Sat, 1 Jun 2024 16:16:23 +0000 Leo Mada via R-help <r-help at r-project.org> ?????: > When highlighting pdf-documents with Microsoft Edge, the bounding box > is sometimes misplaced, and quite ugly so. It also lacks the ability > to draw lines or arrows. > > On the other hand, I did not get used to Acrobat Reader: it usually > involves much more effort to add specific

Dear Jason, The code could look something like: dummyData = data.frame(Tract=seq(1, 10, by=1), ?? ?Pct = c(0.05,0.03,0.01,0.12,0.21,0.04,0.07,0.09,0.06,0.03), ?? ?Totpop = c(4000,3500,4500,4100,3900,4250,5100,4700,4950,4800)) # Define the cutoffs # - allow for duplicate entries; by = 0.03; # by = 0.01; cutoffs <- seq(0, 0.20, by = by) # Create a new column with cutoffs dummyData$Cutoff

Dear Shadee, If you have a data.frame with the following columns: n = 100; # population size x = data.frame( ??????Sex = sample(c("M","F"), n, T), ??????Country = sample(c("AA", "BB", "US"), n, T), ??????Income = as.factor(sample(1:3, n, T)) ) # Dummy variable ONE = rep(1, nrow(x)) r = aggregate(ONE ~ Sex + Income + Country, length, data = x)

Dear Rich, It depends how the data is generated. Although I am not an expert in ecology, I can explain it based on a biomedical example. Certain variables are generated geometrically (exponentially), e.g. MIC or Titer. MIC = Minimum Inhibitory Concentration for bacterial resistance Titer = dilution which still has an effect, e.g. serially diluting blood samples; Obviously, diluting the

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