[Rd] Assignment of individual values to data frame columns: intentional or unintentional behavior?
Dear developeRs, I have just discovered a strange feature when assigning some values to columns of a data frame: The column is matched by partial matching (as documented), but when assigning a value, a new column with the partial name is added to the data frame that is identical to the original column except for the changed value. Is that intentional ? An example: sw - swiss[1:5, 1:4] sw sw$Fert[1] - 10 sw Best, Ulrike -- *** * Ulrike Groemping* * BHT Berlin - University of Applied Sciences * *** * +49 (30) 39404863 (Home Office) * * +49 (30) 4504 5127 (BHT)* *** * http://prof.beuth-hochschule.de/groemping * * groemp...@bht-berlin.de * __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assignment of individual values to data frame columns: intentional or unintentional behavior?
On Thu, Aug 5, 2010 at 12:24 PM, Ulrike Grömping groemp...@bht-berlin.de wrote: Dear developeRs, I have just discovered a strange feature when assigning some values to columns of a data frame: The column is matched by partial matching (as documented), but when assigning a value, a new column with the partial name is added to the data frame that is identical to the original column except for the changed value. Is that intentional ? An example: Note that the lack of partial matching when performing assignment is also documented. See second last paragraph in Details section of ?Extract __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assignment of individual values to data frame columns: intentional or unintentional behavior?
Gabor Grothendieck schrieb: On Thu, Aug 5, 2010 at 12:24 PM, Ulrike Grömping groemp...@bht-berlin.de wrote: Dear developeRs, I have just discovered a strange feature when assigning some values to columns of a data frame: The column is matched by partial matching (as documented), but when assigning a value, a new column with the partial name is added to the data frame that is identical to the original column except for the changed value. Is that intentional ? An example: Note that the lack of partial matching when performing assignment is also documented. See second last paragraph in Details section of ?Extract Yes, I see, thanks. I looked at ?[.data.frame, where this is not documented. However, given the documentation that partial matching is not used on the left-hand side, I would have expected even more that the assignment sw$Fert[1] - 10 works differently, because I am using it on the left-hand side. Probably, extraction ([1]) is done first here, so that the right-hand side won. At least, this is very confusing. Best, Ulrike __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Assignment of individual values to data frame columns: intentional or unintentional behavior?
Ulrike Grömping wrote: However, given the documentation that partial matching is not used on the left-hand side, I would have expected even more that the assignment sw$Fert[1] - 10 works differently, because I am using it on the left-hand side. Probably, extraction ([1]) is done first here, so that the right-hand side won. At least, this is very confusing. I totally agree! I think that sw - data.frame(Fertility=1:5) sw$Fert[1] - 10 should work either like sw$Fert2[1] - 10 i.e. create new column, containing just 10. or like sw$Fertility[1] - 10 i.e. replace the 1st item in sw$Fertility by 10. -- View this message in context: http://r.789695.n4.nabble.com/Assignment-of-individual-values-to-data-frame-columns-intentional-or-unintentional-behavior-tp2315105p2315641.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rbind on data.frame that contains a column that is also a data.frame
Hi,
The following was already a topic on r-help, but after understanding what is
going on, I think it fits better in r-devel.
The problem is this:
When a data.frame has another data.frame in it, rbind doesn't work well.
Here is an example:
--
a=data.frame(x=1:10,y=1:10)
b=data.frame(z=1:10)
b$a=a
b
z a.x a.y
1 1 1 1
2 2 2 2
3 3 3 3
4 4 4 4
5 5 5 5
6 6 6 6
7 7 7 7
8 8 8 8
9 9 9 9
10 10 10 10
rbind(b,b)
Error in `row.names-.data.frame`(`*tmp*`, value = c(1, 2, 3, 4, :
duplicate 'row.names' are not allowed
In addition: Warning message:
non-unique values when setting 'row.names': ‘1’, ‘10’, ‘2’, ‘3’, ‘4’, ‘5’,
‘6’, ‘7’, ‘8’, ‘9’
--
Looking at the code of rbind.data.frame, the error comes from the
lines:
--
xij - xi[[j]]
if (has.dim[jj]) {
value[[jj]][ri, ] - xij
rownames(value[[jj]])[ri] - rownames(xij) # -- problem is here
}
--
if the rownames() line is dropped, all works well. What this line
tries to do is to join the rownames of internal elements of the
data.frames I try to rbind. So the result, in my case should have a
column 'a', whose rownames are the rownames of the original column 'a'. It
isn't totally clear to me why this is needed. When would a data.frame
have different rownames on the inside vs. the outside?
Notice also that rbind takes into account whether the rownames of the
data.frames to be joined are simply 1:n, or they are something else.
If they are 1:n, then the result will have rownames 1:(n+m). If not,
then the rownames might be kept.
I think, more consistent would be to replace the lines above with
something like:
if (has.dim[jj]) {
value[[jj]][ri, ] - xij
rnj = rownames(value[[jj]])
rnj[ri] = rownames(xij)
rnj = make.unique(as.character(unlist(rnj)), sep = )
rownames(value[[jj]]) - rnj
}
In this case, the rownames of inside elements will also be joined, but
in case they overlap, they will be made unique - just as they are for
the overall result of rbind. A side effect here would be that the
rownames of matrices will also be made unique, which till now didn't
happen, and which also doesn't happen when one rbinds matrices that
have rownames. So it would be better to test above if we are dealing
with a matrix or a data.frame.
But most people don't have different rownames inside and outside.
Maybe it would be best to add a flag as to whether you care or don't
care about the rownames of internal data.frames...
But maybe data.frames aren't meant to contain other data.frames?
If instead I do
b=data.frame( z=1:10, a=a)
then rbind(b,b) works well. In this case the data.frame was converted to its
columns. Maybe
b$a = a
should do the same?
Michael
--
View this message in context:
http://r.789695.n4.nabble.com/rbind-on-data-frame-that-contains-a-column-that-is-also-a-data-frame-tp2315682p2315682.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with dl tag in tools::Rd2HTML
On 05/08/2010 5:18 PM, Michael Lachmann wrote: Duncan Murdoch-2 wrote: What version are you using? I don't see that in current R patched. I see this in version 2.11.1. This is the code I ran to generate it: page - utils:::.getHelpFile(?options) tools::Rd2HTML(page,out=t.html) in the generated file, t.html, the first dl tag is such a case. Thanks. It is still there after all. I'll take a look... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gpar fill and transparency on devices
Hi
The help page for Working with Viewports (e.g., pushViewport()) has a
brief mention when talking about the ROOT viewport ...
The viewport tree always has a single root viewport (created by the
system) which corresponds to the entire device (and default graphical
parameter settings).
... which is a reasonable place for it because this is a feature of the
gpar of the ROOT viewport, not of gpars in general. That mention might
be a bit hard to find, but a very similar statement is also made in the
Section on Viewports in the R Graphics book. That in turn might be hard
to find if you don't have the book, but that chapter is also available
online (http://www.stat.auckland.ac.nz/~paul/RGraphics/chapter5.pdf)
It might be worth adding something more explicit about this sort of
gotcha ...
Some devices have different default graphics parameter settings, so it
is not safe to assume that the ROOT viewport will be identical on
different devices.
... ?
Paul
On 5/08/2010 8:14 a.m., baptiste auguie wrote:
Dear list,
I'm puzzled by the graphical output in the following example,
library(grid)
foo- function(){
grid.rect(gp=gpar(fill=black))
print(get.gpar()$fill)
grid.rect(width=0.2,height=0.2)
}
png(test.png, bg = transparent)
foo()
dev.off()
png(test1.png, bg = white)
foo()
dev.off()
It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gpar fill and transparency on devices
Hi,
Thanks for pointing this out. I do have the book, unfortunately I left
it abroad this year. I would think that such brief mention in ?gpar
could be useful (because that's where one first looks for gpar()
defaults --- which are not listed).
Best regards,
baptiste
On 6 August 2010 00:54, Paul Murrell p.murr...@auckland.ac.nz wrote:
Hi
The help page for Working with Viewports (e.g., pushViewport()) has a
brief mention when talking about the ROOT viewport ...
The viewport tree always has a single root viewport (created by the system)
which corresponds to the entire device (and default graphical parameter
settings).
... which is a reasonable place for it because this is a feature of the gpar
of the ROOT viewport, not of gpars in general. That mention might be a bit
hard to find, but a very similar statement is also made in the Section on
Viewports in the R Graphics book. That in turn might be hard to find if you
don't have the book, but that chapter is also available online
(http://www.stat.auckland.ac.nz/~paul/RGraphics/chapter5.pdf)
It might be worth adding something more explicit about this sort of gotcha
...
Some devices have different default graphics parameter settings, so it is
not safe to assume that the ROOT viewport will be identical on different
devices.
... ?
Paul
On 5/08/2010 8:14 a.m., baptiste auguie wrote:
Dear list,
I'm puzzled by the graphical output in the following example,
library(grid)
foo- function(){
grid.rect(gp=gpar(fill=black))
print(get.gpar()$fill)
grid.rect(width=0.2,height=0.2)
}
png(test.png, bg = transparent)
foo()
dev.off()
png(test1.png, bg = white)
foo()
dev.off()
It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)
Best regards,
baptiste
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
--
Dr. Baptiste Auguié
Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain
tel: +34 9868 18617
http://webs.uvigo.es/coloides
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
