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 murdoch.dun...@gmail.com. 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 > >>

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 ar

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 s

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 h

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 compactifi

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

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)

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 =

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

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

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

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,in

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

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

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

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 ; r-help@r-project.org *Subject:* Re: [R] BUG:

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

vision/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,

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

> *To:* Duncan Murdoch > *Cc:* Leo Mada ; r-help@r-project.org < > r-help@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 mat

Re: [R] BUG: atan(1i) / 5 = NaN+Infi ?

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 ; r-help@r-project.org Subject: Re: [R] BUG: atan(1i) / 5

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

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

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

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

Thank you Ivan, Yes I meant `panel.first`. I fumbled the title and the examples, but the end result is the same: ``` # Works with(mtcars, plot(wt, mpg, panel.first = { arrows(3, 15, 4, 30) })) # Doesn't work plot(mpg ~ wt, data = mtcars, panel.first = { arrows(3, 15, 4, 30) }) ``` I sa

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

В Fri, 05 Jul 2024 14:35:40 +0300 "Erez Shomron" пишет: > This works as expected: > with(mtcars, plot(wt, mpg, plot.first = { > plot.window(range(wt), range(mpg)) > arrows(3, 15, 4, 30) > })) I think you meant panel.first, not plot.first. At least I cannot find any mention of plot.first

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

Thanks for your answer. Should I report in Bugzilla at least so it's tracked? I can point that the issue is with line 6 of the function body: ``` dots <- lapply(m$..., eval, md, eframe) ``` I assume the intention was to evaluate the arguments with the context of data passed to the function.

Re: [R] Bug? plot.formula does need support plot.first / plot.last param in plot.default

That definitely looks like a bug, but not one that anyone will be eager to fix. It's very old code that tried to be clever, and that's the hardest kind of code to fix. Remember Kernighan's Law: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you

Re: [R] Bug with writeClipboard in {utils}

В Thu, 20 Jun 2024 18:39:34 +0300 Ivan Krylov via R-help пишет: > > Is there a way to test this patch or will there soon be a published > > patched R version available for download? > > Not directly. Now that the bug is fixed in R-devel (thanks Tomas!), a Windows build of the development vers

Re: [R] Bug with writeClipboard in {utils}

ished patched R version available for download? Thank you again Tanguy BARTHELEMY De : Ivan Krylov Envoyé : mercredi 19 juin 2024 16:07 À : r-help@r-project.org Cc : Barthelemy Tanguy Objet : Re: [R] Bug with writeClipboard in {utils} « Ce courriel provient

Re: [R] Bug with writeClipboard in {utils}

ELEMY De : Rui Barradas Envoyé : mercredi 19 juin 2024 19:26 À : Barthelemy Tanguy; r-help@r-project.org Objet : Re: [R] Bug with writeClipboard in {utils} « Ce courriel provient d’un expéditeur extérieur à l’Insee. Compte tenu du contexte de menace cyber actuel il convient d

Re: [R] Bug with writeClipboard in {utils}

В Thu, 20 Jun 2024 13:21:38 + Barthelemy Tanguy пишет: > Is there a way to test this patch or will there soon be a published > patched R version available for download? Not directly. If you're willing to follow the partially manual process yourself, the instructions at [1] describe how to do

Re: [R] Bug with writeClipboard in {utils}

BARTHELEMY De : Rui Barradas Envoyé : mercredi 19 juin 2024 19:26 À : Barthelemy Tanguy; r-help@r-project.org Objet : Re: [R] Bug with writeClipboard in {utils} « Ce courriel provient d’un expéditeur extérieur à l’Insee. Compte tenu du contexte de menace cyber actuel il convi

Re: [R] Bug with writeClipboard in {utils}

Às 11:12 de 18/06/2024, Barthelemy Tanguy via R-help escreveu: Hello, I'm encountering what seems to be a bug when using the `writeClipboard()` function in the R {utils} package. When I try to copy text to the clipboard, I notice that I get extra characters when I try to paste it (by hand with

Re: [R] Bug with writeClipboard in {utils}

В Tue, 18 Jun 2024 10:12:04 + Barthelemy Tanguy via R-help пишет: > #> [1] "plot(AirPassengers)" "⤀攀" > #> [1] "plot(AirPassengers)" "\u0a00" > #> [1] "plot(AirPassengers)" "\xed\xb0\x80ư" Thanks for showing an example! I was able to reproduce it both with R-4.3.1 on Windows 7 and with a fr

Re: [R] Bug report for package foreign anf functon write.foreign

I haven’t used this function in a long time, but it sounds like the issue is the format names for the formats catalog, not the variable names. You might try the haven package as it can create SAS datasets directly, although there are limitations (I think). > On Jun 6, 2024, at 4:45 AM, Julien J

Re: [R] Bug in print for data frames?

It's still kind of weird; embedded 2-column data frames print differently than 1-column ones: > d <- data.frame(a=1, b=I(data.frame(d=1,e=2))) > d a b.d b.e 1 1 1 2 > str(d) 'data.frame': 1 obs. of 2 variables: $ a: num 1 $ b:Classes 'AsIs' and 'data.frame': 1 obs. of 2 variables:

Re: [R] Bug in print for data frames?

В Wed, 25 Oct 2023 09:18:26 +0300 "Christian Asseburg" пишет: > > str(x) > 'data.frame': 1 obs. of 3 variables: > $ A: num 1 > $ B: num 1 > $ C:'data.frame': 1 obs. of 1 variable: > ..$ A: num 1 > > Why does the print(x) not show "C" as the name of the third element? Interesting

Re: [R] Bug in print for data frames?

Dear R users! Thank you for your excellent replies. I didn't know that the print.data.frame expands matrix-like values in this way. Why doesn't it call the column in my example C.A? I understand that something like that happens when the data.frame in position three has multiple columns. But your

Re: [R] Bug in print for data frames?

er 26, 2023 6:43 AM To: Christian Asseburg ; r-help@r-project.org Subject: Re: [R] Bug in print for data frames? [External Email] Às 07:18 de 25/10/2023, Christian Asseburg escreveu: Hi! I came across this unexpected behaviour in R. First I thought it was a bug in the assignment operator <- but

Re: [R] Bug in print for data frames?

ect.org Subject: Re: [R] Bug in print for data frames? [External Email] Às 07:18 de 25/10/2023, Christian Asseburg escreveu: > Hi! I came across this unexpected behaviour in R. First I thought it was a > bug in the assignment operator <- but now I think it's maybe a bug in the way

Re: [R] Bug in print for data frames?

Às 07:18 de 25/10/2023, Christian Asseburg escreveu: Hi! I came across this unexpected behaviour in R. First I thought it was a bug in the assignment operator <- but now I think it's maybe a bug in the way data frames are being printed. What do you think? Using R 4.3.1: x <- data.frame(A = 1

Re: [R] Bug in print for data frames?

On 25/10/2023 2:18 a.m., Christian Asseburg wrote: Hi! I came across this unexpected behaviour in R. First I thought it was a bug in the assignment operator <- but now I think it's maybe a bug in the way data frames are being printed. What do you think? Using R 4.3.1: x <- data.frame(A = 1,

Re: [R] Bug in print for data frames?

I would say this is not an error, but I think what you wrote isn't what you intended to do anyway. y[1] is a data.frame which contains only the first column of y, which you assign to x$C, so now x$C is a data.frame. R allows data.frame to be plain vectors as well as matrices and data.frames, basi

Re: [R] Bug in internal 'tar' implementation?

Or directly to bugs.r-project.org . It definitely looks to me like a bug. Instructions for bug reports are here: https://www.r-project.org/bugs.html . David might need to set up a Bugzilla account according to those instructions before reporting. Duncan Murdoch On 31/01/2023 1:40 p.m., Ber

Re: [R] Bug in internal 'tar' implementation?

This post should probably go to R-devel rather than here. -- Bert On Tue, Jan 31, 2023 at 9:47 AM David Engster wrote: > I think I found a bug in the internal implementation of 'tar', but > before bothering the R maintainers, I was advised to ask here to make > sure I'm not missing something. >

Re: [R] Bug in R-Help Archives?

, 2023 10:15 AM To: Ivan Krylov Cc: R-help Mailing List Subject: Re: [R] Bug in R-Help Archives? Às 07:36 de 27/01/2023, Ivan Krylov escreveu: > On Fri, 27 Jan 2023 13:01:39 +0530 > Deepayan Sarkar wrote: > >> From looking at the headers in John Sorkin's mail, my guess is that h

Re: [R] Bug in R-Help Archives?

Às 07:36 de 27/01/2023, Ivan Krylov escreveu: On Fri, 27 Jan 2023 13:01:39 +0530 Deepayan Sarkar wrote: From looking at the headers in John Sorkin's mail, my guess is that he just replied to the other thread rather than starting a fresh email, and in his attempts to hide that, was outsmarted

Re: [R] Bug in R-Help Archives?

Às 07:31 de 27/01/2023, Deepayan Sarkar escreveu: From looking at the headers in John Sorkin's mail, my guess is that he just replied to the other thread rather than starting a fresh email, and in his attempts to hide that, was outsmarted by Outlook. This is based on references to domains such

Re: [R] Bug in R-Help Archives?

Every email thread (mailing list or not) gets a hidden identifier that is used to identify that thread. It is not that Outlook outsmarted John... any email program would have done the same. John... please don't reply to existing posts with a new subject... many mailing list users may be using t

Re: [R] Bug in R-Help Archives?

On Fri, 27 Jan 2023 13:01:39 +0530 Deepayan Sarkar wrote: > From looking at the headers in John Sorkin's mail, my guess is that he > just replied to the other thread rather than starting a fresh email, > and in his attempts to hide that, was outsmarted by Outlook. That's 100% correct. The starti

Re: [R] Bug in R-Help Archives?

>From looking at the headers in John Sorkin's mail, my guess is that he just replied to the other thread rather than starting a fresh email, and in his attempts to hide that, was outsmarted by Outlook. This is based on references to domains such as yahoo.com, dcn.davis.ca.us, and precheza.cz in th

Re: [R] Bug in R-Help Archives?

Às 06:39 de 27/01/2023, Rui Barradas escreveu: Hello, When consulting the R-Help Archives today I've noticed that the thread Pipe operator started by John Sorkin, Tue Jan 3 17:48:30 CET 2023 is under another thread, R Certification started by Mukesh Ghanshyamdas Lekhrajani. Isn't this a b

Re: [R] Bug in packages.

On Wed, 13 Jul 2022 16:19:59 -0400 Charles-Édouard Giguère wrote: > Is there a mechanism to report a bug in someone package? I plan to > email the author, but I was wondering if there is an official way > like the issue function in github. Try running bug.report(package='...'). It should either

Re: [R] Bug in packages.

https://www.r-project.org/bugs.html for info on bug reporting. Bert On Wed, Jul 13, 2022 at 1:49 PM Charles-Édouard Giguère wrote: > > Hello everyone, > Is there a mechanism to report a bug in someone package? I plan to email the > author, but I was wondering if there is an official way like t

Re: [R] Bug in R-install -- sysdata.rda

On Mon, 21 Mar 2022 11:33:36 + Manu goswami wrote: > It's really a maze just getting any sort of developer related help > for r. I am still not able to understand where to post what. We don't have an "R administration" mailing list, so R-devel se

Re: [R] Bug in R-install -- sysdata.rda

Please don't post to multiple lists at once... this is widely frowned on by many mailing lists. If you simply read the Posting Guide it will inform you that you should post questions "related to compiling" on r-devel. I also recommend that you read the R Administration and Installation manual,

Re: [R] Bug in R-install -- sysdata.rda

Dear R Developers, Building R from source has never been straight forward but now it has become impossible. Even when one compiles and links all files Still below error is stopping completing build process. This certainly is deplorably mischievous. Please support to resolve immediately. Cygwin

Re: [R] bug in Windows implementation of nlme::groupedData

Dear Melissa, It seems strange to me that your code would work on any platform (it doesn't on my Mac) because the data frame you create shouldn't contain a matrix named "X" but rather columns including those originating from X. To illustrate: > X <- matrix(1:12, 4, 3) > colnames(X) <- c("a",

Re: [R] Bug in list.files(full.names=T)

I've tried a bunch of different R versions, I can't seem to replicate what you described. Here's the code I used: R.pattern <- paste0("^R-", .standard_regexps()$valid_R_system_version, "$") x <- list.files(dirname(R.home()), pattern = R.pattern, full.names = TRUE) x <- x[file.info(x, extra_cols =

Re: [R] Bug in list.files(full.names=T)

> grep(value=TRUE, invert=TRUE, "$", strsplit(Sys.getenv("PATH"), ";")[[1]]) [1] "C:\\rtools40\\usr\\bin" [2] "C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath" [3] "C:\\Program Files\\ImageMagick-7.0.11-Q16-HDRI" [4] "C:\\WINDOWS\\system32" [5] "C:\\WINDOWS" [6] "C:\\WINDOWS

Re: [R] Bug in list.files(full.names=T)

> Bill Dunlap > on Mon, 20 Dec 2021 08:40:04 -0800 writes: >> >> > Why would one ever *add* a final unneeded path separator, >> > unless one wanted it? >> > Good question, but it is common for Windows installer programs to add a > terminal backslash to PATH

Re: [R] Bug in list.files(full.names=T)

> > > Why would one ever *add* a final unneeded path separator, > > unless one wanted it? > Good question, but it is common for Windows installer programs to add a terminal backslash to PATH entries. E.g., on my Windows laptop I get > grep(value=TRUE, "$", strsplit(Sys.getenv("PATH")

Re: [R] Bug in list.files(full.names=T)

t regards, Mario Reutter [[alternative HTML version deleted]] -------------- Message: 3 Date: Sun, 19 Dec 2021 07:24:06 -0500 From: Duncan Murdoch To: Mario Reutter , r-help@r-project.org Subject: Re: [R] Bug in list.files(full.names

Re: [R] Bug in list.files(full.names=T)

> Martin Maechler > on Mon, 20 Dec 2021 09:46:23 +0100 writes: > Mario Reutter > on Sat, 18 Dec 2021 15:55:37 +0100 writes: >> Dear everybody, >> I'm a researcher in the field of psychology and a >> passionate R user. After having updated to the newest >

Re: [R] Bug in list.files(full.names=T)

> Mario Reutter > on Sat, 18 Dec 2021 15:55:37 +0100 writes: > Dear everybody, > I'm a researcher in the field of psychology and a > passionate R user. After having updated to the newest > version, I experienced a problem with list.files() if the > parameter full.

Re: [R] Bug in list.files(full.names=T)

I don't know the answer to your question, but I see the same behaviour on MacOS, e.g. list.files("./") includes ".//R" in the results on my system. Both "./R" and ".//R" are legal ways to express that path on MacOS, so it's not a serious bug, but it does look ugly. Duncan Murdoch On 18/12/20

Re: [R] Bug? Index output of C functions R_qsort_I and R_qsort_int_I is not modified

1 2 3 4 [[2]] [1] 0 0 0 0 [[3]] [1] 4 but > .C("mysort2i",4:1,1:4,4L) [[1]] [1] 1 2 3 4 [[2]] [1] 4 3 2 1 [[3]] [1] 4 From: Bill Dunlap Sent: 16 April 2021 04:50 To: Evangelos Evangelou Cc: r-help@r-project.org Subject: Re: [R] Bug? Index outpu

Re: [R] Bug? Index output of C functions R_qsort_I and R_qsort_int_I is not modified

R_ext/Utils.h:void R_qsort_int_I(int *iv, int *II, int i, int j); The last 2 arguments are int, not int*. .C() passes pointers to vectors so you cannot call this function directly from .C(). -Bill On Thu, Apr 15, 2021 at 3:15 PM Evangelos Evangelou via R-help < r-help@r-project.org> wrote: > H

Re: [R] bug or just me

Hi Martin, This is a known bug. Definitely related to Ubuntu (debian), libopenblas and possibly specific hardware. Here's a bug report on the Debian list https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961725 Best, Eric On Sun, May 31, 2020 at 4:38 AM Bert Gunter wrote: > No clue. > > Worke

Re: [R] bug or just me

No clue. Worked fine in R 4.0.0 I would try updating R.Maybe your BLAS got corrupted. Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Sat, May 30, 2020 at 5:57

Re: [R] Bug in function arguments autocomplete and ellipsis?

Dear All, Thanks for clarifying this. Now I know that this is expected behavior, and will try to place … before the rest of the arguments. Stay home and stay safe! -Roman > 2020. 5. 9. 오전 1:24, Bert Gunter 작성: > > The R > Language Definition [[alternative HTML version deleted]] ___

Re: [R] Bug in function arguments autocomplete and ellipsis?

It would help if you consulted the docs, in this case, **The R Language Definition** and, in particular, 4.3.2 on argument matching. I won't repeat what it is there, but I believe it will suffice to dispel your confusion. Bert Gunter "The trouble with having an open mind is that people keep comi

Re: [R] Bug in function arguments autocomplete and ellipsis?

On 07/05/2020 3:46 a.m., Roman Olson wrote: Dear All, I am wondering whether function arguments autocomplete causes a bug when additional ellipsis arguments are used. Example: a = function(robot) { cat(robot, "\n") } a(r=5) prints 5, meaning that r is autocompleted to “robot”. Not sure

Re: [R] Bug (?): file.copy() erases 'from' file if the "to" file already exists and is a symlinked file

However, notice that cat doesn't protect you in the same way: Peters-iMac:tst pd$ echo stuff > A Peters-iMac:tst pd$ ln -s A B Peters-iMac:tst pd$ ls -l total 8 -rw-r--r-- 1 pd staff 6 Sep 13 15:20 A lrwxr-xr-x 1 pd staff 1 Sep 13 15:20 B -> A Peters-iMac:tst pd$ cp A B cp: B and A are ident

Re: [R] Bug in R 3.6.0?

> Morgan Morgan > on Mon, 29 Apr 2019 21:42:36 +0100 writes: > Hi, > I am using the R 3.6.0 on windows. The issue that I report below does not > exist with previous version of R. > In order to reproduce the error you must install a package of your choice > from sou

Re: [R] Bug in R 3.6.0?

Hello, I have exactly the same problem when I install one of my own packages: Error in tools:::.read_description(file) : file 'DESCRIPTION' does not exist Calls: suppressPackageStartupMessages ... withCallingHandlers -> .getRequiredPackages -> -> Exécution arrêtée ERROR: lazy loading failed

Re: [R] Bug (?): reading binary files in Windows 10

Ah wow, that answers many questions, thanks! On Thu, Dec 6, 2018 at 4:41 PM Jeff Newmiller wrote: > AFAIK this receiver-side responsibility to specify the text/binary status > of the file is particularly a problem with the "ftp://"; protocol because > it does not use MIME file encoding (which "h

Re: [R] Bug (?): reading binary files in Windows 10

AFAIK this receiver-side responsibility to specify the text/binary status of the file is particularly a problem with the "ftp://"; protocol because it does not use MIME file encoding (which "http://"; uses). MIME allows the sending end of the connection to communicate whether the file is text or

Re: [R] Bug (?): reading binary files in Windows 10

On 06/12/2018 7:45 AM, Kate Stone wrote: Hello r-help, Could you help me determine whether this is an R bug or not? I've been trying to read this binary file in R: download.file("ftp://ftp.fieldtriptoolbox.org/pub/fieldtrip/tutorial/preprocessing_erp/s04.eeg","s04.eeg";) and I get a different

Re: [R] Bug (?): reading binary files in Windows 10

Hi, this is what i got, just with base R: > a <- download.file(" ftp://ftp.fieldtriptoolbox.org/pub/fieldtrip/tutorial/preprocessing_erp/s04.eeg ","s04.eeg") probando la URL ' ftp://ftp.fieldtriptoolbox.org/pub/fieldtrip/tutorial/preprocessing_erp/s04.eeg ' Content type 'unknown' length 142773760

Re: [R] Bug (?): reading binary files in Windows 10

Dear Kate, I cannot find your small script, but I downloaded the file using your command line. It has the size of 142773760 bytes (136.2 MB). Hth, Albrecht -- Albrecht Kauffmann alkau...@fastmail.fm Am Do, 6. Dez 2018, um 13:45, schrieb Kate Stone: > Hello r-help, > > Could you help me

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

Nope. This IS a bug: _*The negative auto-correlation mostly disappear when I randomize small samples using the R function '*__*sample*__*'.*_ Please check thoroughly the code of the 1st mail I sent, there should be no difference between the two R functions I wrote to illustrate the bug.

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

I got it ! thanks and sorry for annoying you with that. have a nice day, hugo On 05/10/2018 11:16, Deepayan Sarkar wrote: > On Fri, Oct 5, 2018 at 2:07 PM hmh wrote: >> On 05/10/2018 10:28, Annaert Jan wrote: >>> you discard any time series structure; >> But that is PRECISELY what a call a

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

On Fri, Oct 5, 2018 at 2:07 PM hmh wrote: > > On 05/10/2018 10:28, Annaert Jan wrote: > > you discard any time series structure; > But that is PRECISELY what a call a bug: > There should not be any "time series structure" in the output or rnorm, > runif and so on but there is one. > > rnorm(N,0,1)

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

On 05/10/2018 10:28, Annaert Jan wrote: > you discard any time series structure; But that is PRECISELY what a call a bug: There should not be any "time series structure" in the output or rnorm, runif and so on but there is one. rnorm(N,0,1) should give on average the same output as sample(rnorm(N

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

On 05/10/2018, 09:45, "R-help on behalf of hmh" wrote: Hi, Thanks William for this fast answer, and sorry for sending the 1st mail to r-help instead to r-devel. I noticed that bug while I was simulating many small random walks using c(0,cumsum(rnorm(10))). The

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

Hi, Thanks William for this fast answer, and sorry for sending the 1st mail to r-help instead to r-devel. I noticed that bug while I was simulating many small random walks using c(0,cumsum(rnorm(10))). Then the negative auto-correlation was inducing a muchsmaller space visited by the random w

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

Hi Hugo, I've been able to replicate your bug, including for other distributions (runif, rexp, rgamma, etc) which shouldn't be surprising since they're probably all drawing from the same pseudo-random number generator.  Interestingly, it does not seem to depend on the choice of seed, I am not su

Re: [R] Bug : Autocorrelation in sample drawn from stats::rnorm

Did you take into account that the sample serial correlation coefficient has a bias of approximately -1/T (with T the sample size)? Its variance is approximately 1/T. Jan Annaert -Original Message- From: R-help On Behalf Of hmh Sent: donderdag 4 oktober 2018 12:09 To: R Subject: [R]

Re: [R] [bug] spdep package?

Many thanks for the info. I see the point but I'll think calling the spData would be a cheaper price to pay. If each package one load provide access to their variables things are likely to get messy. I guess many R users would like to control the variables in their global environment. And sinc

Re: [R] [bug] spdep package?

This is intended/expected because the spdep package *depends* on the spData package (see https://cran.r-project.org/web/packages/spdep/), which means that the maintainer of spdep intends also spData to be *attached* whenever spdep is attached.If they would have only imported it, then spData wou

Re: [R] [bug] spdep package?

Helllo, Thanks for the info. I still think these variables should not be loaded when library(spdep) is called. But I'll handle it following your suggestion. Thanks, Jeremie > It turns out that that 'x' comes from the spData package and lives > inside that package (part of its namespace)

Re: [R] [bug] spdep package?

It turns out that that 'x' comes from the spData package and lives inside that package (part of its namespace). > spData::x [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 This is conceptually no different from other objects in package namespace, although we are more used to

Re: [R] Bug report: override stopifnot() ?

On 12/03/2018 2:43 PM, Bert Gunter wrote: Please stop this line of queries/"suggestions/speculations and read the relevant docs **carefully**. For example, from ?"==" "Note Do not use == and != for tests, such as in if expressions, where you must get a single TRUE or FALSE. Unless you are abso

Re: [R] Bug report: override stopifnot() ?

Please stop this line of queries/"suggestions/speculations and read the relevant docs **carefully**. For example, from ?"==" "Note Do not use == and != for tests, such as in if expressions, where you must get a single TRUE or FALSE. Unless you are absolutely sure that nothing unusual can happen,

Re: [R] Bug report: override stopifnot() ?

Hello, I'm sorry that I aswer to my own mail; I forgot to attach the patch. Patch below, Stepan Kasal On Mon, Mar 12, 2018 at 06:53:00PM +0100, Stepan Kasal wrote: > When thinking about it, stopifnot() should really issue a better error > message in this case. Patch attached. But I should per

Re: [R] Bug report: override stopifnot() ?

Hello, On Mon, Mar 12, 2018 at 09:30:59AM -0700, William Dunlap wrote: > Why don't you use >stopifnot( all(m1 == m2) ) > ? good question. Even though I use aseert np.all(m1 == m2) when working with NumPy, I got accustomed to the "handy shortcut" that I can omit all() with R vectors and ma

Re: [R] Bug report: override stopifnot() ?

Why don't you use stopifnot( all(m1 == m2) ) ? Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Mar 12, 2018 at 8:15 AM, Stepan Kasal wrote: > Hello, > I stumbled over a problem: >stopifnot(m1 == m2) > > It works with vector or matrix, but does not work for classes from Matrix > pack

Re: [R] Bug?

I think the help file for apply() warns you that if you give it a data.frame, the data.frame will be converted to a matrix, with X <- as.matrix(X), before FUN is called on its rows or columns. Look at what as.matrix does to your data: since there is a non-numeric column it produces a character mat

Re: [R] Bug in by() function which works for some FUN argument and does not work for others

Dear All, Yes, I certainly now agree with the suggestion of Adrian Dusa for using colMeans in place of mean in the situation that I had reported to r-help. And I am sorry that I did not personally extend my thanks to him. I really wish to thank him for his suggestion, and I do this now. However,

Re: [R] Bug in by() function which works for some FUN argument and does not work for others

> On Apr 16, 2016, at 2:03 AM, Akhilesh Singh > wrote: > > Dear All, > > I have got your core message, that it is my responsibility to determine > whether any particular function in my version of R satisfies the language > requirements at the time of your use. Jim Albert and Maria Rizzo mus

Re: [R] Bug in by() function which works for some FUN argument and does not work for others

Dear All, I have got your core message, that it is my responsibility to determine whether any particular function in my version of R satisfies the language requirements at the time of your use. Jim Albert and Maria Rizzo must have used their code, which was permitted in the R-code of their time (2

Re: [R] Bug in by() function which works for some FUN argument and does not work for others

On 15/04/2016 4:16 AM, Akhilesh Singh wrote: Dear All, Thanks for your help. However, I would like to draw your attention to the following: Actually, I was replicating the Example 2.3, using the dataset "brainsize.txt" given in Section 2.3.3 ("Summarize by group") at page 55, of a famous book "

Re: [R] Bug in by() function which works for some FUN argument and does not work for others

Books don't rewrite themselves retroactively NEWS for 3.0.0 has • mean() for data frames and sd() for data frames and matrices are defunct. and 3.0.0 was released April 3, 2013. A book published in 2012 would likely be based on R 2.13.x or maybe even 2.12.x. So mean(dataframe) wor

  1   2   3   4   >