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

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

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 d’un

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

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’être

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

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

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’être

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

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

[R] Bug with writeClipboard in {utils}

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 CTRL+V or with the `readClipboard()` function from R packages

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

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

Dear all, First of all, I thank you for the creation of the package. I write this message concerning the write.foreign() function from the foreign package and a bug that I discovered. When we want to save our dataset as a .sas file, the limit of variable names character is 8 by default. In SAS

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?

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

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

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

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 =

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,

[R] Bug in print for data frames?

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, B = 2, C = 3) > y <- data.frame(A = 1) > x A B C

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

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.

[R] Bug in internal 'tar' implementation?

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. Fortunately, it can be very easily reproduced on a Linux system. In an empty temporary directory, execute the following code:

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 he

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

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

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

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

[R] Bug in R-Help Archives?

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 bug in the filing system? Thanks to the list

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

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

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

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

I am trying to replicate a semi-parametric analysis described in Harezlak, Jaroslaw, David Ruppert, and Matt P. Wand. Semiparametric regression with R. New York, NY: Springer, 2018. (https://link.springer.com/book/10.1007%2F978-1-4939-8853-2). I can successfully run the analysis, but now I'm

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]

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, "$",

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

LSE, & base::t. Jorgen Harmse. Message: 1 Date: Sat, 18 Dec 2021 15:55:37 +0100 From: Mario Reutter To: r-help@r-project.org Subject: [R] Bug in list.files(full.names=T) Message-ID: Content-Type: text/plain; charset="utf-8" Dear everybody,

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

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

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

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.names is set to TRUE. A path separator "/" is now always appended to path in the output even if path %>%

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

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

Hi all. Reading the documentation of these two functions https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Utility-functions "The ..._I() versions also return the sort.index() vector in I." I can't find anything in the documentation about sort.index(), but I'm guessing that I is the

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

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

[R] bug or just me

Hi, Is this a bug or just me doing something stupid? solve(m) never returns and eats 100% CPU. > sessionInfo() R version 3.6.3 (2020-02-29) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04 LTS Matrix products: default BLAS:

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

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

[R] Bug in function arguments autocomplete and ellipsis?

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 if this is normal behavior, but this does not

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

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

If file.copy() is used to replace a symlinked file, it erases the original file and does not copy the file. The original file is lost. > version _ platform x86_64-apple-darwin15.6.0 arch x86_64 os darwin15.6.0

[R] Bug in "==" with empty data frames

Hi The following code results in an error: ### > x <- data.frame(x = integer(0), y = integer(0)) > x == x Error in matrix(if (is.null(value)) logical() else value, nrow = nr, dimnames = list(rn, : length of 'dimnames' [2] not equal to array extent > ### I would expect that

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

Re: [R] Bug in R 3.6.0?

ng failed for package 'RRegArch' Best, Ollivier -Message d'origine- De : R-help De la part de Morgan Morgan Envoyé : lundi 29 avril 2019 22:43 À : r-help@r-project.org Objet : [R] Bug in R 3.6.0? Hi, I am using the R 3.6.0 on windows. The issue that I report below does not exist with

[R] Bug in R 3.6.0?

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 source (tar.gz). -Create a .Rprofile file with the following command in it : setwd("D:/") -Close your R

Re: [R] Potential R bug in identical

a Research Fellow Leeds Institute for Data Analytics Room 11.70, Worsley Building, University of Leeds From: Ivan Krylov Sent: 17 January 2019 20:40:32 To: Layik Hama Cc: r-help@r-project.org Subject: Re: [R] Potential R bug in identical On Thu, 17 Jan 2019 14:5

Re: [R] Potential R bug in identical

On Thu, 17 Jan 2019 21:05:07 + Layik Hama wrote: > Why would `identical(str, "Accident_Index", ignore.case = TRUE)` > behave differently on Linux/MacOS vs Windows? Because str is different from "Accident_Index" on Windows: it was decoded from bytes to characters according to different rules

Re: [R] Potential R bug in identical

On Thu, 17 Jan 2019 14:55:18 + Layik Hama wrote: > There seems to be some weird and unidentifiable (to me) characters in > front of the `Accidents_Index` column name there causing the length > to be 17 rather than 14 characters. Repeating the reproduction steps described at the linked pull

[R] Potential R bug in identical

Hi, My first email to r-help and as I am not sure about the issue, I wanted to ask for help first. The comments under this thread outline a particular string from a dataset which seems to be read by R on Windows differently to Linux and MacOS and

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

er to deal with any text file newline decoding > choice/task after the file transfer is completed. > > On December 6, 2018 7:03:48 AM PST, Duncan Murdoch < > murdoch.dun...@gmail.com> wrote: > >On 06/12/2018 7:45 AM, Kate Stone wrote: > >> Hello r-help, > >&g

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

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

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

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

cht Kauffmann > alkau...@fastmail.fm > > Am Do, 6. Dez 2018, um 13:45, schrieb Kate Stone: > > 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: > > >

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

u 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 length file (i.e.

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

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 length file (i.e. much lon

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

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

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

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

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

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

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

Hi, I just noticed the following bug: When we draw a random sample using the function stats::rnorm, there should be not auto-correlation in the sample. But their is some auto-correlation _when the sample that is drawn is small_. I describe the problem using two functions:

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

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

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

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

[R] [bug] spdep package?

Hello, I found a dangerous issue in the library spdep. I get variables x and y that cannot be removed by rm() and I don't don't how they show up. Can anyone reproduce this? ~$ R --vanilla > rm(list=ls()) > library(spdep) > x [1] 0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450

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

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

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

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

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

[R] Bug report: override stopifnot() ?

Hello, I stumbled over a problem: stopifnot(m1 == m2) It works with vector or matrix, but does not work for classes from Matrix package. In the source of stopifnot(), there is all(m1 == m2) that would just work, but there is also is.logical(m1 == m2) that id FALSE. Would it be possible if

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

[R] Bug?

Hello, In my code I found something that looks like an anomaly, I found a reproducible example in which I am just trying to compare each row in a data frame against the first row:

[R] Bug in the triMat( ) function in the deldir package.

Yesterday Jay Call drew to my attention the fact that the triMat() function was giving wrong answers in some instances. Wrong answers occur if the union of three contiguous Delaunay triangles happens to constitute another triangle. This latter triangle appeared in the list of triangles

Re: [R] R bug when started in Windows 10

On 8/14/2016 12:57 PM, Itamar José G. Nunes wrote: Greetings, CRAN supporter. I am Itamar José, a Brazilian programmer and biotechnology student. I'm using R from some time ago, most of the time working with it in Windows 7, but since I changed to Windows 10, I'm having some bugs when R platform

Re: [R] R bug when started in Windows 10

I have cc'ed this to r-help. As I said, I am not on Windows and so cannot help directly. -- Bert 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 Sun, Aug 14,

Re: [R] R bug when started in Windows 10

I'm not on Windows and cannot help directly. But you might consider downloading Rstudio ( https://www.rstudio.com/ ) and running R through that. Their website should contain the info you need to get things up and running. Cheers, Bert Bert Gunter "The trouble with having an open mind is that

[R] R bug when started in Windows 10

Greetings, CRAN supporter. I am Itamar José, a Brazilian programmer and biotechnology student. I'm using R from some time ago, most of the time working with it in Windows 7, but since I changed to Windows 10, I'm having some bugs when R platform particularly in this new operational system. If

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,

  1   2   3   4   5   >