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

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

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

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

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

Is the following a bug in your opinion? I think so. This works as expected: ``` with(mtcars, plot(wt, mpg, plot.first = { plot.window(range(wt), range(mpg)) arrows(3, 15, 4, 30) })) ``` This does not. ``` plot(mpg ~ wt, data = mtcars, plot.first = { plot.window(range(wt), range(mpg)

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

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

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

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

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

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

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

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

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

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

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)

are too useful for local variables, so I would say TRUE, FALSE, & 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: tex

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

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

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

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

[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: /usr/lib/x86_64-linux-gnu/openblas-pthread/libbla

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

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

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

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

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

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?

lazy loading 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 b

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

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

[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

the receiver 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, &

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

Murdoch wrote: >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.f

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

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

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

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 f

[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

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)

  1   2   3   4   5   6   >