Re: [Rd] Subscripting fails if name of element is "" (PR#8161)
Dear Brian,
Thanks for picking this up.
I think the critical point is that it is not a single isolated bug and it
would be a main effort to get this stuff consistent, because it (and
implications) seems to be spread all over the code. The to be applauded
efforts to properly sort out "NA" vs. as.character(NA) have not been fully
successful yet and "" is a similar issue. Please consider the following,
sorry for the length:
# ERROR 1
# I agree that c() disallows "" and NA names
# it makes sense discouraging users from using such names
> c(as.character(NA)=1)
Fehler: Syntaxfehler in Zeile "c(as.character(NA)="
> c("NA"=2, "a"=3)
NA a
2 3
> c(""=4)
Fehler: Versuch einen Variablennamen der Länge 0 zu nutzen
# however, "NA" must be expected as a legal name, e.g. when importing data
# and in your example specifying "no-name" in fact results in a "" name
> names(c(a=1, 2))
[1] "a" ""
>
# My interpreteation is that the user specifies a mixture of elements with
and without names,
# and therefore the no-names must be co-erced to "" names, and in principle
that's completely fine
# a character vector is defined to have either as.character(NA) OR "NA" OR
"" or another positive length string
# (which is complicated enough)
# formally the names is an attribute (character vector) of an object and can
be manipulated as such
> x <- 1:4
> names(x) <- c(NA, "NA", "a", "")
> names(x)
[1] NA "NA" "a" ""
> # and in principle all of those can be properly distinguished
> x[match(names(x), names(x))]
NAa
1234
# introducing a fifth non-name state that sometimes equals "" and sometimes
not, introduces inconsistency into the language
# e.g. the fact that elements can be selected by their name but not by their
non-name
# Thus currently selecting by names is a mess from a consistency perspective
> x[names(x)]
a
113 NA
# in the following subscripting with "" works, but not with "NA"
> for (i in names(x))
+ print(x[[i]])
[1] 1
[1] 1
[1] 3
[1] 4
# ERROR 1a: If failing on "NA" is not a bug, I switch from programming to
Kafka
> x["NA"]
1
# ERROR 1b: clearly wrong
> x[["NA"]]
[1] 1
# ERROR 1c: and from my humble understanding failing on "" is a bug as well
> x[""]
NA
# wheras interestingly this is correct
> x[[""]]
[1] 4
# I think it is obvious how to remove these inconsistencies
# (as long as we do not disallow "" in names alltogether,
# which is almost impossible, since every users legally can set the names
vector in a variety of ways )
# these are not easy, but perfectly fine
> x[as.character(NA)]
1
> x[as.integer(NA)]
NA
# and these are really debatable difficult ones
> x[NA]
NA NA NA NA
> x[as.logical(NA)]
NA NA NA NA
## ERROR 2+3: the above inconsistencies generalize to lists
lx <- as.list(x)
> lx
$"NA" (ERROR 2a)
[1] 1
$"NA"
[1] 2
$a
[1] 3
[[4]] (ERROR 2b)
[1] 4
# and should read
> lx
$NA ( or $as.character(NA) for clarity and warning )
[1] 1
$"NA"
[1] 2
$a
[1] 3
$""
[1] 4
# Note that - except for printing - match works perfectly in
> lx[match(names(lx), names(lx))]
$"NA"
[1] 1
$"NA"
[1] 2
$a
[1] 3
[[4]]
[1] 4
# and also in
> for (i in match(names(lx), names(lx)))
+ print(lx[[i]])
[1] 1
[1] 2
[1] 3
[1] 4
# Of course I consider the following behaviour as inconsistent
> lx[names(lx)]
$"NA"
[1] 1
$"NA"
[1] 1 (ERROR 3a)
$a
[1] 3
$"NA"
NULL(ERROR 3b)
# using [[ the second one fails
> for (i in names(lx))
+ print(lx[[i]])
[1] 1
[1] 1 (ERROR 3c)
[1] 3
[1] 4 (interestingly correct)
# finally note that this works
> eval(substitute(lx$y, list(y=as.character(NA
# but not this
> get("$")(lx, as.character(NA))
Fehler in get("$")(lx, as.character(NA)) : ungültiger Indextyp
# and both go wrong with "NA"
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] new.packages() problem (PR#8185)
Full_Name: AJ Rossini Version: 2.2.0 OS: Unix Submission from: (NULL) (160.62.4.10) new.packages() reports on packages which are installed as well as not installed, for packages installed using install.packages() and the argument installWithVers=TRUE This contrasts with reporting only on uninstalled packages (correct behavior) for packages installed using install.packages() and the argument installWithVers=FALSE. i.e. install.packages(new.packages(),installWithVers=TRUE) run again and again will keep installing the same packages. install.packages(new.packages()) run again and again will only install the packages once. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building packages on Windows fails
Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: > On Fri, 7 Oct 2005, Peter Kleiweg wrote: > > > > > What has changed in R for Windows from version 1.7.1 to > > 2.2.0 that won't allow me to build binary packages? > > Many things have changed; I don't know which is causing the failure you see. > One change is that instructions are now collected in the Installation and > Administration manual. Try following the setup instructions there and see if > it still fails. I can't find anything on building packages for Windows in that manual. I did find a solution to the problem. On a Linux install, each package has a file CONTENTS. These are missing from the Windows install. I copied those files from my Linux install to my Windows install, and then I could build my own package. So I guess, these CONTENTS files should be included in the Windows install. I got another error message when I remove a package, but I couldn't see what effect this error has. When I run: d:\>Rcmd REMOVE iL04 The package gets removed, but I get: make: *** No rule to make target `indices'. Stop. > > -- Making package iL04 > > adding build stamp to DESCRIPTION > > installing R files > > installing demos > > installing data files > > installing man source files > > installing indices > > cat: d:/R-2.2.0/library/*/CONTENTS: No such file or directory > > make[2]: *** [indices] Error 1 > > make[1]: *** [all] Error 2 > > make: *** [pkg-iL04] Error 2 > > *** Installation of iL04 failed *** -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] svn version number
Is there some way of automatically including the svn version number of a package in the DESCRIPTION file or otherwise so that one can check from within R which svn version number one has? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Links to stylesheet are broken
I did a standard install of R 2.2.0 on Linux. When I run help.start(), I get an intro page that has a broken link to a stylesheet. The same for the pages "Packages", "Search Engine & Keywords", "About R", and "Resources". The other help pages do have a correct link to the stylesheet. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building packages on Windows fails
On Fri, 7 Oct 2005, Peter Kleiweg wrote: > Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: > >> On Fri, 7 Oct 2005, Peter Kleiweg wrote: >> >>> >>> What has changed in R for Windows from version 1.7.1 to >>> 2.2.0 that won't allow me to build binary packages? >> >> Many things have changed; I don't know which is causing the failure you see. >> One change is that instructions are now collected in the Installation and >> Administration manual. Try following the setup instructions there and see if >> it still fails. > > I can't find anything on building packages for Windows in that > manual. Your problems was installing, so the section on `Installing Packages' should help you. A binary build is an install plus wrapping-up. > I did find a solution to the problem. On a Linux install, each > package has a file CONTENTS. These are missing from the Windows > install. I copied those files from my Linux install to my > Windows install, and then I could build my own package. So I > guess, these CONTENTS files should be included in the Windows > install. And indeed they are, as the presence of 500+ packages on CRAN for Windows will show you. The recommended way to build a binary package on Windows is R CMD INSTALL --build since that is able to get HTML links made (on Windows, you need to install in the main library tree to do so). > > I got another error message when I remove a package, but I > couldn't see what effect this error has. When I run: > >d:\>Rcmd REMOVE iL04 > > The package gets removed, but I get: > >make: *** No rule to make target `indices'. Stop. That does seem a recent bug, soon to be fixed in R-patched. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to stylesheet are broken
On Fri, 7 Oct 2005, Peter Kleiweg wrote: > > I did a standard install of R 2.2.0 on Linux. When I run > help.start(), I get an intro page that has a broken link to a > stylesheet. The same for the pages "Packages", "Search Engine & > Keywords", "About R", and "Resources". The other help pages do > have a correct link to the stylesheet. Confirmed. help-links.sh is not linking R.css, and is expected to. The help pages link to the stylesheet in their library tree, not the one in doc/html. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
Just want to clarify that it is the package itself that is being developed under svn; I was not referring to the svn version number of R. On 10/7/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Is there some way of automatically including the svn version number > of a package in the DESCRIPTION file or otherwise so that one > can check from within R which svn version number one has? > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Gunilla aetiology
Hi Do you d less On tions? want to spen your Meddica It's Very easy! - Get more information CiaXanViaAmValiLev liagbuit s $1xra $ienm $ra 21 3.33 3.75 And more than 200 other , Have a nice day [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building packages on Windows fails
Prof Brian Ripley schreef op de 7e dag van de wijnmaand van het jaar 2005: > On Fri, 7 Oct 2005, Peter Kleiweg wrote: > > > Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: > > > > > On Fri, 7 Oct 2005, Peter Kleiweg wrote: > > > > > > > What has changed in R for Windows from version 1.7.1 to > > > > 2.2.0 that won't allow me to build binary packages? > > > > > > Many things have changed; I don't know which is causing > > > the failure you see. One change is that instructions are > > > now collected in the Installation and Administration > > > manual. Try following the setup instructions there and see > > > if it still fails. > > > > I can't find anything on building packages for Windows in > > that manual. > > Your problems was installing, so the section on `Installing > Packages' should help you. Installing worked fine. Building a binary distribution (with compiled help files) is what didn't work. This worked fine: Rcmd build iL04 But that just gave a gzip'ed tarfile, not a zip-file, and without the compiled helpfiles. This didn't work: Rcmd build --force --binary iL04 > > I did find a solution to the problem. On a Linux install, > > each package has a file CONTENTS. These are missing from the > > Windows install. I copied those files from my Linux install > > to my Windows install, and then I could build my own > > package. So I guess, these CONTENTS files should be included > > in the Windows install. > > And indeed they are, as the presence of 500+ packages on CRAN > for Windows will show you. Well, I just ran the install program for Windows, with compiled html help, but without the ordinary html help files. In that case, no CONTENTS files get installed. > The recommended way to build a binary package on Windows is > > R CMD INSTALL --build Yes, that works. Even without the CONTENTS files. And this is recommended in the manual "Creating R packages", another manual than Duncan Murdoch was referring to. I was using a method that was recommended in earlier versions. Perhaps that method should just be disabled, with a message about the current method, instead of having it fail for obscure reasons. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building packages on Windows fails
On Fri, 7 Oct 2005, Peter Kleiweg wrote: > Prof Brian Ripley schreef op de 7e dag van de wijnmaand van het jaar 2005: > >> On Fri, 7 Oct 2005, Peter Kleiweg wrote: >> >>> Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: >>> On Fri, 7 Oct 2005, Peter Kleiweg wrote: > What has changed in R for Windows from version 1.7.1 to > 2.2.0 that won't allow me to build binary packages? Many things have changed; I don't know which is causing the failure you see. One change is that instructions are now collected in the Installation and Administration manual. Try following the setup instructions there and see if it still fails. >>> >>> I can't find anything on building packages for Windows in >>> that manual. >> >> Your problems was installing, so the section on `Installing >> Packages' should help you. > > Installing worked fine. Building a binary distribution (with > compiled help files) is what didn't work. > > This worked fine: > >Rcmd build iL04 > > But that just gave a gzip'ed tarfile, not a zip-file, and > without the compiled helpfiles. > > This didn't work: > >Rcmd build --force --binary iL04 > > >>> I did find a solution to the problem. On a Linux install, >>> each package has a file CONTENTS. These are missing from the >>> Windows install. I copied those files from my Linux install >>> to my Windows install, and then I could build my own >>> package. So I guess, these CONTENTS files should be included >>> in the Windows install. >> >> And indeed they are, as the presence of 500+ packages on CRAN >> for Windows will show you. > > Well, I just ran the install program for Windows, with compiled > html help, but without the ordinary html help files. In that > case, no CONTENTS files get installed. Ah, that's the clue. People normally build complete binary distributions: let's see if we can track that down. >> The recommended way to build a binary package on Windows is >> >> R CMD INSTALL --build > > Yes, that works. Even without the CONTENTS files. And this is > recommended in the manual "Creating R packages", another manual > than Duncan Murdoch was referring to. > > I was using a method that was recommended in earlier versions. > Perhaps that method should just be disabled, with a > message about the current method, instead of having it fail for > obscure reasons. It is not quite the same thing. I have been in favour of removing it, but others have differed in their opinions. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subscripting fails if name of element is "" (PR#8161)
I haven't been following this conversation in order, but I think there's
another bug here besides the one(s?) you identified:
Jens had this example:
> x <- 1:4
> names(x) <- c(NA, "NA", "a", "")
> x[names(x)]
a
113 NA
Shouldn't the second entry in the result be 2, with name "NA"? It seems
the string "NA" has been converted to here.
Duncan Murdoch
Prof Brian Ripley wrote:
> On Thu, 6 Oct 2005, "Jens Oehlschlägel" wrote:
>
>
>>Dear Thomas,
>>
>>
>>>This looks deliberate (there is a function NonNullStringMatch that does
>>>the matching). I assume this is because there is no other way to
>>>indicate that an element has no name.
>>
>>>If so, it is a documentation bug -- help(names) and FAQ 7.14 should
>>>specify this behaviour. Too late for 2.2.0, unfortunately.
>>
>>I respectfully disagree: the element has a name, its an empty string. Of
>>course "" is a doubtful name for an element, but as long as we allow this
>>name when assigning names()<- we also should handle it like a name in
>>subscripting. The alternative would be to disallow "" in names at all.
>>However, both alternatives rather look like code changes, not only
>>documentation.
>
>
> I think Thomas is right as to how S interprets this: "" is no name on
> assignment, wheread NA as a name is a different thing (there probably is a
> name, we just do not know what it is).
>
> Here is the crux of the example.
>
> p <- c(a=1, 2)
>
>>p <- c(a=1, 2)
>>names(p)
>
> [1] "a" ""
>
>>p
>
> a
> 1 2
>
>>p2 <- c(1,2)
>>names(p2) <- c("a", "")
>>identical(p, p2)
>
> [1] TRUE
>
> so giving the name is "" really is the same as giving no name.
>
> `Error 1' is said to be
>
>
>>p[""]
>
>
>NA
>
> You haven't given a name, so I think that is right. S (which has no
> character NAs) uses "" as the name, but here there may be a name or not.
>
>
>>P <- list(a=1, 2)
>
>
> I think Jens then meant as `error 2' that
>
>
>>P
>
> $a
> [1] 1
>
> [[2]]
> [1] 2
>
> shows no name for the second element, and that seems right to me (although
> S shows "" here).
>
> Finally (`error 3')
>
>
>>P[""]
>
> $"NA"
> NULL
>
> is a length-one list with name character-NA. (S has no name here.) That
> seems the right answer but if so is printed inconsistently.
>
> I would say that
>
>
>>Q <- list(1, 2)
>>names(Q) <- c("a", NA)
>>Q
>
> $a
> [1] 1
>
> $"NA"
> [1] 2
>
> was the only bug here (the name should be printed as ). Now that
> comes from this bit of code
>
> if( isValidName(CHAR(PRINTNAME(TAG(s )
> sprintf(ptag, "$%s", CHAR(PRINTNAME(TAG(s;
> else
> sprintf(ptag, "$\"%s\"", CHAR(PRINTNAME(TAG(s;
>
> so non-syntactic names are printed surrounded by "". Nowadays I think we
> would prefer ``, as in
>
>
>>A <- list("a+b"=1)
>>A
>
> $"a+b"
> [1] 1
>
>
>>A$"a+b"
>
> [1] 1
>
>>A$`a+b`
>
> [1] 1
>
> but NA needs to be a special case as in
>
>
>>A <- list(1, 2)
>>names(A) <- c("NA", NA)
>>A
>
> $"NA"
> [1] 1
>
> $"NA"
> [1] 2
>
>
>>is.na(names(A))
>
> [1] FALSE TRUE
>
>
>
>
>
>
> __
> 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] Building packages on Windows fails
Peter Kleiweg wrote: > Prof Brian Ripley schreef op de 7e dag van de wijnmaand van het jaar 2005: > > >>On Fri, 7 Oct 2005, Peter Kleiweg wrote: >> >> >>>Duncan Murdoch schreef op de 6e dag van de wijnmaand van het jaar 2005: >>> >>> On Fri, 7 Oct 2005, Peter Kleiweg wrote: >What has changed in R for Windows from version 1.7.1 to >2.2.0 that won't allow me to build binary packages? Many things have changed; I don't know which is causing the failure you see. One change is that instructions are now collected in the Installation and Administration manual. Try following the setup instructions there and see if it still fails. >>> >>>I can't find anything on building packages for Windows in >>>that manual. >> >>Your problems was installing, so the section on `Installing >>Packages' should help you. > > > Installing worked fine. Building a binary distribution (with > compiled help files) is what didn't work. > > This worked fine: > > Rcmd build iL04 > > But that just gave a gzip'ed tarfile, not a zip-file, and > without the compiled helpfiles. > > This didn't work: > > Rcmd build --force --binary iL04 > > > >>>I did find a solution to the problem. On a Linux install, >>>each package has a file CONTENTS. These are missing from the >>>Windows install. I copied those files from my Linux install >>>to my Windows install, and then I could build my own >>>package. So I guess, these CONTENTS files should be included >>>in the Windows install. >> >>And indeed they are, as the presence of 500+ packages on CRAN >>for Windows will show you. > > > Well, I just ran the install program for Windows, with compiled > html help, but without the ordinary html help files. In that > case, no CONTENTS files get installed. > > >>The recommended way to build a binary package on Windows is >> >>R CMD INSTALL --build > > > Yes, that works. Even without the CONTENTS files. And this is > recommended in the manual "Creating R packages", another manual > than Duncan Murdoch was referring to. > > I was using a method that was recommended in earlier versions. > Perhaps that method should just be disabled, with a > message about the current method, instead of having it fail for > obscure reasons. I agree there should be only one method, and it should work. The problem is: - Users with limited permissions can't run INSTALL, because it needs write access to R_HOME/library. - Because Windows doesn't have soft links, the only way we have to get cross references in the help files to work is to install to R_HOME/library. I'd prefer to fix "Rcmd build --binary" so that it got the help links right and then have "Rcmd INSTALL --build" use it first, then install the .zip file, but I haven't taken the time to do this. I don't like having two parallel tracks of very similar code (because of problems like yours, where the one I don't personnally use falls out of date and stops working). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
Gabor Grothendieck wrote: > Is there some way of automatically including the svn version number > of a package in the DESCRIPTION file or otherwise so that one > can check from within R which svn version number one has? You could do this by writing it into your Makefile, but there's no other existing support for it. I'd recommend combining the URL reported by "svn info" with the result of svnversion to get the most informative version. Watch out for cases of people who are trying to make your package from a tarfile, rather than an svn checkout. We have ended up with some fairly tricky Makefile programming to get what we want into the R banner. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > Is there some way of automatically including the svn version number > > of a package in the DESCRIPTION file or otherwise so that one > > can check from within R which svn version number one has? > > You could do this by writing it into your Makefile, but there's no other > existing support for it. I'd recommend combining the URL reported by > "svn info" with the result of svnversion to get the most informative > version. Watch out for cases of people who are trying to make your > package from a tarfile, rather than an svn checkout. We have ended up > with some fairly tricky Makefile programming to get what we want into > the R banner. There is no makefile at all currently as my package is all R. Also, I currently use TortoiseSVN. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subscripting fails if name of element is "" (PR#8161)
On Fri, 7 Oct 2005, Duncan Murdoch wrote:
I haven't been following this conversation in order, but I think there's
another bug here besides the one(s?) you identified:
Jens had this example:
x <- 1:4
names(x) <- c(NA, "NA", "a", "")
x[names(x)]
a
113 NA
Shouldn't the second entry in the result be 2, with name "NA"? It seems the
string "NA" has been converted to here.
Yes, but I don't see it in PR#8161 where there is no name "NA" that I can
see. (In other words it is not an instance of the subject line.)
The issue is that is matching "NA", and it should not. As in the
code
Rboolean NonNullStringMatch(SEXP s, SEXP t)
{
if (CHAR(s)[0] && CHAR(t)[0] && strcmp(CHAR(s), CHAR(t)) == 0)
return TRUE;
else
return FALSE;
}
and there are more instances around.
Duncan Murdoch
Prof Brian Ripley wrote:
On Thu, 6 Oct 2005, "Jens Oehlschlägel" wrote:
Dear Thomas,
This looks deliberate (there is a function NonNullStringMatch that does
the matching). I assume this is because there is no other way to
indicate that an element has no name.
If so, it is a documentation bug -- help(names) and FAQ 7.14 should
specify this behaviour. Too late for 2.2.0, unfortunately.
I respectfully disagree: the element has a name, its an empty string. Of
course "" is a doubtful name for an element, but as long as we allow this
name when assigning names()<- we also should handle it like a name in
subscripting. The alternative would be to disallow "" in names at all.
However, both alternatives rather look like code changes, not only
documentation.
I think Thomas is right as to how S interprets this: "" is no name on
assignment, wheread NA as a name is a different thing (there probably is a
name, we just do not know what it is).
Here is the crux of the example.
p <- c(a=1, 2)
p <- c(a=1, 2)
names(p)
[1] "a" ""
p
a
1 2
p2 <- c(1,2)
names(p2) <- c("a", "")
identical(p, p2)
[1] TRUE
so giving the name is "" really is the same as giving no name.
`Error 1' is said to be
p[""]
NA
You haven't given a name, so I think that is right. S (which has no
character NAs) uses "" as the name, but here there may be a name or not.
P <- list(a=1, 2)
I think Jens then meant as `error 2' that
P
$a
[1] 1
[[2]]
[1] 2
shows no name for the second element, and that seems right to me (although
S shows "" here).
Finally (`error 3')
P[""]
$"NA"
NULL
is a length-one list with name character-NA. (S has no name here.) That
seems the right answer but if so is printed inconsistently.
I would say that
Q <- list(1, 2)
names(Q) <- c("a", NA)
Q
$a
[1] 1
$"NA"
[1] 2
was the only bug here (the name should be printed as ). Now that
comes from this bit of code
if( isValidName(CHAR(PRINTNAME(TAG(s )
sprintf(ptag, "$%s", CHAR(PRINTNAME(TAG(s;
else
sprintf(ptag, "$\"%s\"", CHAR(PRINTNAME(TAG(s;
so non-syntactic names are printed surrounded by "". Nowadays I think we
would prefer ``, as in
A <- list("a+b"=1)
A
$"a+b"
[1] 1
A$"a+b"
[1] 1
A$`a+b`
[1] 1
but NA needs to be a special case as in
A <- list(1, 2)
names(A) <- c("NA", NA)
A
$"NA"
[1] 1
$"NA"
[1] 2
is.na(names(A))
[1] FALSE TRUE
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] svn version number
On 7 Oct 2005, [EMAIL PROTECTED] wrote: > On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> Gabor Grothendieck wrote: >>> Is there some way of automatically including the svn version >>> number of a package in the DESCRIPTION file or otherwise so that >>> one can check from within R which svn version number one has? >> >> You could do this by writing it into your Makefile, but there's no >> other existing support for it. I'd recommend combining the URL >> reported by "svn info" with the result of svnversion to get the >> most informative version. Watch out for cases of people who are >> trying to make your package from a tarfile, rather than an svn >> checkout. We have ended up with some fairly tricky Makefile >> programming to get what we want into the R banner. > > There is no makefile at all currently as my package is all R. Also, > I currently use TortoiseSVN. This is really an svn question. Perhaps asking/searching on an svn list would be helpful. Personally, I don't think R's package building tools should do anything svn specific. There is no reason to expect/enforce svn as *the* SCM that people use to develop R packages. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subscripting issues unrelated to [Subscripting fails if name of element is "" (PR#8161)]
Jens,
This is a completely separate issue. In indexing, character NA matches
the name "NA". That was a bug, but it is nothing to do with the subject
line or PR#8161, and for the record let's keep this separate. The
`critical point' is not to build a theory around misunderstandings of
several unrelated examples.
You say
get("$")(lx, as.character(NA))
goes wrong. Now the documentation has x$name for 'name' a symbol or a
character string, and you have passed an _expression_ and got an
appropriate error message,
Error in get("$")(lx, as.character(NA)) : invalid subscript type
If you don't see that, please review the section in R-lang or the Blue
Book. Equally
get("$")(lx, as.character("a"))
Error in get("$")(lx, as.character("a")) : invalid subscript type
so it nothing to do with NA or "" or the subject line here.
On the other hand
substitute(lx$y, list(y=as.character(NA)))
is lx$NA, using a name (and no longer a character NA).
Brian
On Fri, 7 Oct 2005, "Jens Oehlschlägel" wrote:
Dear Brian,
Thanks for picking this up.
I think the critical point is that it is not a single isolated bug and it
would be a main effort to get this stuff consistent, because it (and
implications) seems to be spread all over the code. The to be applauded
efforts to properly sort out "NA" vs. as.character(NA) have not been fully
successful yet and "" is a similar issue. Please consider the following,
sorry for the length:
# ERROR 1
# I agree that c() disallows "" and NA names
# it makes sense discouraging users from using such names
c(as.character(NA)=1)
Fehler: Syntaxfehler in Zeile "c(as.character(NA)="
c("NA"=2, "a"=3)
NA a
2 3
c(""=4)
Fehler: Versuch einen Variablennamen der Länge 0 zu nutzen
# however, "NA" must be expected as a legal name, e.g. when importing data
# and in your example specifying "no-name" in fact results in a "" name
names(c(a=1, 2))
[1] "a" ""
# My interpreteation is that the user specifies a mixture of elements with
and without names,
# and therefore the no-names must be co-erced to "" names, and in principle
that's completely fine
# a character vector is defined to have either as.character(NA) OR "NA" OR
"" or another positive length string
# (which is complicated enough)
# formally the names is an attribute (character vector) of an object and can
be manipulated as such
x <- 1:4
names(x) <- c(NA, "NA", "a", "")
names(x)
[1] NA "NA" "a" ""
# and in principle all of those can be properly distinguished
x[match(names(x), names(x))]
NAa
1234
# introducing a fifth non-name state that sometimes equals "" and sometimes
not, introduces inconsistency into the language
# e.g. the fact that elements can be selected by their name but not by their
non-name
# Thus currently selecting by names is a mess from a consistency perspective
x[names(x)]
a
113 NA
# in the following subscripting with "" works, but not with "NA"
for (i in names(x))
+ print(x[[i]])
[1] 1
[1] 1
[1] 3
[1] 4
# ERROR 1a: If failing on "NA" is not a bug, I switch from programming to
Kafka
x["NA"]
1
# ERROR 1b: clearly wrong
x[["NA"]]
[1] 1
# ERROR 1c: and from my humble understanding failing on "" is a bug as well
x[""]
NA
# wheras interestingly this is correct
x[[""]]
[1] 4
# I think it is obvious how to remove these inconsistencies
# (as long as we do not disallow "" in names alltogether,
# which is almost impossible, since every users legally can set the names
vector in a variety of ways )
# these are not easy, but perfectly fine
x[as.character(NA)]
1
x[as.integer(NA)]
NA
# and these are really debatable difficult ones
x[NA]
NA NA NA NA
x[as.logical(NA)]
NA NA NA NA
## ERROR 2+3: the above inconsistencies generalize to lists
lx <- as.list(x)
lx
$"NA" (ERROR 2a)
[1] 1
$"NA"
[1] 2
$a
[1] 3
[[4]] (ERROR 2b)
[1] 4
# and should read
lx
$NA ( or $as.character(NA) for clarity and warning )
[1] 1
$"NA"
[1] 2
$a
[1] 3
$""
[1] 4
# Note that - except for printing - match works perfectly in
lx[match(names(lx), names(lx))]
$"NA"
[1] 1
$"NA"
[1] 2
$a
[1] 3
[[4]]
[1] 4
# and also in
for (i in match(names(lx), names(lx)))
+ print(lx[[i]])
[1] 1
[1] 2
[1] 3
[1] 4
# Of course I consider the following behaviour as inconsistent
lx[names(lx)]
$"NA"
[1] 1
$"NA"
[1] 1 (ERROR 3a)
$a
[1] 3
$"NA"
NULL(ERROR 3b)
# using [[ the second one fails
for (i in names(lx))
+ print(lx[[i]])
[1] 1
[1] 1 (ERROR 3c)
[1] 3
[1] 4 (interestingly correct)
# finally note that this works
eval(substitute(lx$y, list(y=as.character(NA
# but not this
get("$")(lx, as.character(NA))
Fehler in get("$")(lx, as.character(NA)) : ungültiger Indextyp
# and both go wrong with "NA"
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
-
Re: [Rd] svn version number
Gabor Grothendieck wrote: > On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>Gabor Grothendieck wrote: >> >>>Is there some way of automatically including the svn version number >>>of a package in the DESCRIPTION file or otherwise so that one >>>can check from within R which svn version number one has? >> >>You could do this by writing it into your Makefile, but there's no other >>existing support for it. I'd recommend combining the URL reported by >>"svn info" with the result of svnversion to get the most informative >>version. Watch out for cases of people who are trying to make your >>package from a tarfile, rather than an svn checkout. We have ended up >>with some fairly tricky Makefile programming to get what we want into >>the R banner. > > > There is no makefile at all currently as my package is all R. Also, I > currently use TortoiseSVN. Probably the simplest option is to set an svn:keywords property on one of your source files, and get Subversion to put the revision number into the source when you check out. This won't tell you if you've got a mixed or modified revision, but as long as you are careful not to do this, it might give you what you want. I've got no idea how to do this in TortoiseSVN (I use command line svn), but presumably the documentation will talk about it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] FFT
Hi, Is FFT implemented in R takes advantage of multi-processors? I ran this benchmark from from http://www.sciviews.org, and AMD Opteron 2.2 GHz performs better than AMD Opteron 1.8 GHz on all test cases, except FFT operation. Both machines run same OSs (RedHat WS 3) and 2.2 GHz has more memory (2 GB RAM) than 1.8 GHz (1 GB RAM). The only difference is that 1.8 GHz is a dual-processor machine, and 2.2 GHz is a single processor machine. Could this be the reason? Does anyone has insights on this? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] optim warning message. (PR#8186)
Full_Name: Ken Kelley
Version: 2.1.1
OS: Windows XP
Submission from: (NULL) (156.56.79.54)
A warning from optim() when reltol was specified for the L-BFGS-B method:
"method L-BFGS-B uses 'fact' (and 'pgtol') instead of 'reltol' and 'abstol' in:
optim(par = LL.0, fn = Low.Lim.NC.F, gr = NULL, method = c("Nelder-Mead","
But, "fact" should be "factr," which is the name of the control parameter or
interest.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
