[Rd] Unnecessary lines in stem.c?
A discussion on r-help led me to look at stem.c at
https://github.com/wch/r-source/blob/trunk/src/library/graphics/src/stem.c
Lines 76-77 appear superfluous. They sit inside a condition, and set mu, as
follows:
if (k*(k-4)*(k-8) == 0) mu = 5;
if ((k-1)*(k-5)*(k-6) == 0) mu = 20;
But mu is set unconditionally to 10 on line 84, and that is followed by
conditional assignments (on line 85-6) identical to lines 76-77.
It looks like a couple of lines got left inside a condition that are no longer
needed there. If that is correct, is it worth removing the superfluous lines,
for future coders' benefit?
S Ellison
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)
Bug 17159 has been fixed (in R-devel), but there may be more issues left with UNC paths. Tomas On 01/17/2018 01:37 PM, Joris Meys wrote: Hi Peter, I share your experience with trying to help IT departments setting things up. The network directory of the students is mapped to a drive, but R still uses the unc path instead of the drive when attempting to create that user library. Unless I do it manually of course. The only solution I see right now is to set the HOME or R_LIBS_USER environment variable in Renviron, but that should be done each time a new student logs into the computer. Or is there a way to ensure R uses the mapped drive instead of the network unc path, either using an R setting or by messing with Windows itself? Cheers Joris On Wed, Jan 17, 2018 at 1:21 PM, Peter Dalgaard wrote: I can easily believe that. It was maily for Joris, that it might not be necessary to reinstall. -pd On 17 Jan 2018, at 11:55 , Thompson, Pete wrote: That solution works fine for the use case where each user has a network based home directory and needs to run R from there, but doesn’t help with my situation. I need to be able to support arbitrary network based paths in arbitrary numbers – so mapping drives isn’t an option. I have found a workaround using symbolic links to the network share created within the temporary folder, but would much prefer that R support UNC paths – it seems a reasonably simple fix. Cheers Pete On 17/01/2018, 10:52, "Peter Dalgaard" wrote: I usually draw a complete blank if I try to assist our IT department with such issues (we really need better documentation than the Admin manual for large-system installs by non-experts in R). However, it is my impression that there are also options involving environment variables and LFS naming. E.g., map the networked user directory to, say, a P: "drive" and make sure that the environment is set up to reflect this. -pd On 16 Jan 2018, at 17:52 , Joris Meys wrote: Hi all, I ran into this exact issue yesterday during the exam of statistical computing. Users can install packages in a user library that R tries to create automatically on the network drive of the student. But that doesn't happen as the unc path is not read correctly, leading to R attempting to create a local directory and being told it has no right to do so. That is an older version of R though (3.3), but I'm wondering whether I would ask our IT department to just update R on all these computers to the latest version, or if we have to look for another solution. Cheers Joris On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete Hi, I’d like to ask about bug 17159: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159 I can confirm that I see exactly this bug when using dir.create on paths of UNC form (\\server\share\xxx), with the recursive flag set. I’m seeing this when attempting to use install.packages with such a path (which I know isn’t supported, but would be great if it was!). I can see that a patch has been suggested for the problem and from looking at the source code I believe it’s a correct fix. Is there a possibility of getting this patch included? The existing logic for Windows recursive dir.create (platform.c lines 2209-22203) appears to be: - Skip over any \\share at the start of the directory name - Loop while there are pieces of directory name left (i.e. we haven’t hit the last \ character) = Find the next portion of the directory name (up to the next \ character) = Attempt to create the directory (unless it is of the form x: - i.e. a drive name) = Ignore any ‘already exists’ errors, otherwise throw an error This logic appears flawed in that it skips \\share which isn’t a valid path format (according to https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my memory, it’s possible that \\share was a supported format in very old versions of Windows, but it’s been a long time since the UNC format came in. It’s also possible that \\share is a valid format in some odd environments, but the UNC format is far more widely used. The patch suggested by Evan Cortens is simply to change the skip logic to skip over \\server\share instead of \\share. This will certainly fix the common use case of using UNC paths, but doesn’t attempt to deal with all the more complex options in Microsoft’s documentation. I doubt many users would ask for the complex cases, but the basic UNC format would be of wide applicability. Thanks Pete Thompson Director, Information Technology Head of Spotfire Centre of Excellence IQVIA IMPORTANT - PLEASE READ: This electronic message, including its attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY PRIVILEGED or PROTECTED information and is intended for the authorized recipient of the sender. If you are not the intended recipient, you are hereby notified that any use, disclosure, copying,
Re: [Rd] Duplicate column names created by base::merge() when by.x has the same name as a column in y
Hi Scott,
It seems like reasonable behavior to me. What result would you expect?
That the second "name" should be called "name.y"?
The "merge" documentation says:
If the columns in the data frames not used in merging have any
common names, these have ‘suffixes’ (‘".x"’ and ‘".y"’ by default)
appended to try to make the names of the result unique.
Since the first "name" column was used in merging, leaving both
without a suffix seems consistent with the documentation...
Frederick
On Fri, Feb 16, 2018 at 09:08:29AM +1100, Scott Ritchie wrote:
> Hi,
>
> I was unable to find a bug report for this with a cursory search, but would
> like clarification if this is intended or unavoidable behaviour:
>
> ```{r}
> # Create example data.frames
> parents <- data.frame(name=c("Sarah", "Max", "Qin", "Lex"),
> sex=c("F", "M", "F", "M"),
> age=c(41, 43, 36, 51))
> children <- data.frame(parent=c("Sarah", "Max", "Qin"),
>name=c("Oliver", "Sebastian", "Kai-lee"),
>sex=c("M", "M", "F"),
>age=c(5,8,7))
>
> # Merge() creates a duplicated "name" column:
> merge(parents, children, by.x = "name", by.y = "parent")
> ```
>
> Output:
> ```
>name sex.x age.x name sex.y age.y
> 1 Max M43 Sebastian M 8
> 2 Qin F36 Kai-lee F 7
> 3 Sarah F41Oliver M 5
> Warning message:
> In merge.data.frame(parents, children, by.x = "name", by.y = "parent") :
> column name ‘name’ is duplicated in the result
> ```
>
> Kind Regards,
>
> Scott Ritchie
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)
Wonderful ( - thanks! Cheers Pete On 16/02/2018, 16:29, "Tomas Kalibera" wrote: Bug 17159 has been fixed (in R-devel), but there may be more issues left with UNC paths. Tomas On 01/17/2018 01:37 PM, Joris Meys wrote: > Hi Peter, > > I share your experience with trying to help IT departments setting things > up. The network directory of the students is mapped to a drive, but R still > uses the unc path instead of the drive when attempting to create that user > library. Unless I do it manually of course. The only solution I see right > now is to set the HOME or R_LIBS_USER environment variable in Renviron, but > that should be done each time a new student logs into the computer. Or is > there a way to ensure R uses the mapped drive instead of the network unc > path, either using an R setting or by messing with Windows itself? > > Cheers > Joris > > > > On Wed, Jan 17, 2018 at 1:21 PM, Peter Dalgaard wrote: > >> I can easily believe that. It was maily for Joris, that it might not be >> necessary to reinstall. >> >> -pd >> >>> On 17 Jan 2018, at 11:55 , Thompson, Pete >> wrote: >>> That solution works fine for the use case where each user has a network >> based home directory and needs to run R from there, but doesn’t help with >> my situation. I need to be able to support arbitrary network based paths in >> arbitrary numbers – so mapping drives isn’t an option. I have found a >> workaround using symbolic links to the network share created within the >> temporary folder, but would much prefer that R support UNC paths – it seems >> a reasonably simple fix. >>> Cheers >>> Pete >>> >>> >>> On 17/01/2018, 10:52, "Peter Dalgaard" wrote: >>> >>> I usually draw a complete blank if I try to assist our IT department >> with such issues (we really need better documentation than the Admin manual >> for large-system installs by non-experts in R). >>> However, it is my impression that there are also options involving >> environment variables and LFS naming. E.g., map the networked user >> directory to, say, a P: "drive" and make sure that the environment is set >> up to reflect this. >>> -pd >>> On 16 Jan 2018, at 17:52 , Joris Meys wrote: Hi all, I ran into this exact issue yesterday during the exam of statistical computing. Users can install packages in a user library that R tries to create automatically on the network drive of the student. But that >> doesn't happen as the unc path is not read correctly, leading to R attempting to create a local directory and being told it has no right to do so. That is an older version of R though (3.3), but I'm wondering whether I would ask our IT department to just update R on all these computers to >> the latest version, or if we have to look for another solution. Cheers Joris On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete >>> wrote: > Hi, I’d like to ask about bug 17159: > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159 > > I can confirm that I see exactly this bug when using dir.create on >> paths > of UNC form (\\server\share\xxx), with the recursive flag set. I’m >> seeing > this when attempting to use install.packages with such a path (which I >> know > isn’t supported, but would be great if it was!). I can see that a >> patch has > been suggested for the problem and from looking at the source code I > believe it’s a correct fix. Is there a possibility of getting this >> patch > included? > > The existing logic for Windows recursive dir.create (platform.c lines > 2209-22203) appears to be: > - Skip over any \\share at the start of the directory name > - Loop while there are pieces of directory name left (i.e. we haven’t >> hit > the last \ character) > = Find the next portion of the directory name (up to the next \ > character) > = Attempt to create the directory (unless it is of the form x: - i.e. a > drive name) > = Ignore any ‘already exists’ errors, otherwise throw an error > > This logic appears flawed in that it skips \\share which isn’t a valid > path format (according to https://msdn.microsoft.com/en- > us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my >> memory, > it’s possible that \\share was a supported format in very old versions >> of > Windows, but it’s been a long time since the UNC format came in. It’s >> also > possible that \\share is a valid format in some odd en
Re: [Rd] Duplicate column names created by base::merge() when by.x has the same name as a column in y
Hi Frederick,
I would expect that any duplicate names in the resulting data.frame would
have the suffixes appended to them, regardless of whether or not they are
used as the join key. So in my example I would expect "names.x" and
"names.y" to indicate their source data.frame.
While careful reading of the documentation reveals this is not the case, I
would argue the intent of the suffixes functionality should equally be
applied to this type of case.
If you agree this would be useful, I'm happy to write a patch for
merge.data.frame that will add suffixes in this case - I intend to do the
same for merge.data.table in the data.table package where I initially
encountered the edge case.
Best,
Scott
On 17 February 2018 at 03:53, wrote:
> Hi Scott,
>
> It seems like reasonable behavior to me. What result would you expect?
> That the second "name" should be called "name.y"?
>
> The "merge" documentation says:
>
> If the columns in the data frames not used in merging have any
> common names, these have ‘suffixes’ (‘".x"’ and ‘".y"’ by default)
> appended to try to make the names of the result unique.
>
> Since the first "name" column was used in merging, leaving both
> without a suffix seems consistent with the documentation...
>
> Frederick
>
> On Fri, Feb 16, 2018 at 09:08:29AM +1100, Scott Ritchie wrote:
> > Hi,
> >
> > I was unable to find a bug report for this with a cursory search, but
> would
> > like clarification if this is intended or unavoidable behaviour:
> >
> > ```{r}
> > # Create example data.frames
> > parents <- data.frame(name=c("Sarah", "Max", "Qin", "Lex"),
> > sex=c("F", "M", "F", "M"),
> > age=c(41, 43, 36, 51))
> > children <- data.frame(parent=c("Sarah", "Max", "Qin"),
> >name=c("Oliver", "Sebastian", "Kai-lee"),
> >sex=c("M", "M", "F"),
> >age=c(5,8,7))
> >
> > # Merge() creates a duplicated "name" column:
> > merge(parents, children, by.x = "name", by.y = "parent")
> > ```
> >
> > Output:
> > ```
> >name sex.x age.x name sex.y age.y
> > 1 Max M43 Sebastian M 8
> > 2 Qin F36 Kai-lee F 7
> > 3 Sarah F41Oliver M 5
> > Warning message:
> > In merge.data.frame(parents, children, by.x = "name", by.y = "parent") :
> > column name ‘name’ is duplicated in the result
> > ```
> >
> > Kind Regards,
> >
> > Scott Ritchie
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
