Re: [Rd] Development version of R: Improved nchar(), nzchar() but changed API
Dear Martin, Does the work on nchar mean that bugs #16090 and #16091 will be resolved [1,2]? Thanks, Mark [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16090 [2] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16091 On Sat, Apr 25, 2015 at 11:06 PM, James Cloos wrote: > > "GC" == Gábor Csárdi writes: > > GC> You can get an RSS/Atom feed, however, if that's good: > GC> https://github.com/wch/r-source/commits/master.atom > > That is available in gwene/gmane as: > > gwene.com.github.wch.r-source.commits.trunk > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > __ > 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
[Rd] Inconsistency when naming a vector
Sometimes the absence of a name is maked by an NA: x <- 1:2 names(x)[[1]] <- "a" names(x) # [1] "a" NA Whereas other times its y <- c(a = 1, 2) names(y) # [1] "a" "" Is this deliberate? The help for names() is a bit murky, but an example shows the NA behaviour. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency when naming a vector
There is no inconsistency. Documentation of `names` says "...value
should be a character vector of up to the same length as x..."
In the first definition your character vector is not the same length
as length of x, so you enforce NA by not defining value[2]
x <- 1:2
value<-c("a")
value[2]
[1] NA
where as in the second case, R uses default value "", from `names`
documentation "..The name "" is special: it is used to indicate that
there is no name associated with an element.". Since you defined the
first one, it internally assigns "" to non-defined names to match the
length of the vector.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency when naming a vector
In `?names`:
If ‘value’ is shorter than ‘x’, it is extended by character ‘NA’s
to the length of ‘x’.
So it is as documented.
That said, it's somewhat surprising that both NA and "" serve as a
placeholder for a 'missing name'; I believe they're treated
identically by R under the hood (e.g. in subsetting operations) but
there may be some subtle cases where they're not.
On Mon, Apr 27, 2015 at 6:08 AM, Suzen, Mehmet wrote:
>
> There is no inconsistency. Documentation of `names` says "...value
> should be a character vector of up to the same length as x..."
> In the first definition your character vector is not the same length
> as length of x, so you enforce NA by not defining value[2]
>
> x <- 1:2
> value<-c("a")
> value[2]
> [1] NA
>
> where as in the second case, R uses default value "", from `names`
> documentation "..The name "" is special: it is used to indicate that
> there is no name associated with an element.". Since you defined the
> first one, it internally assigns "" to non-defined names to match the
> length of the vector.
>
> __
> 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] Inconsistency when naming a vector
> On 27 Apr 2015, at 13:48 , Hadley Wickham wrote:
>
> Sometimes the absence of a name is maked by an NA:
>
> x <- 1:2
> names(x)[[1]] <- "a"
> names(x)
> # [1] "a" NA
>
> Whereas other times its
>
> y <- c(a = 1, 2)
> names(y)
> # [1] "a" ""
>
> Is this deliberate? The help for names() is a bit murky, but an
> example shows the NA behaviour.
I think it is
(a) impossible to change
(b) at least somewhat coherent
The situation is partially due to the fact that character-NA is a relative
latecomer to the language. In the beginning, there was no real distinction
between NA and "NA", causing issues when abbreviating Noradrenaline, North
America, Nelson Anderson, etc. At some point, it was decided to fix things up,
as far as possible in a backawards compatible way. Some common idioms were
retained but others were changed to comply with the rules for other vector
types.
We have the empty string convention on (AFAICT) all constructor usages:
c(a=1, 3)
list(a=1, 3)
cbind(a=1, 3)
and also in the lists implied by argument matching
> f <- function(...) names(match.call(expand.dots=TRUE))
> f(a=1,3)
[1] "" "a" ""
In contrast, assignment forms have the NA convention. This is consistent with
the general rules for complex assignment. E.g. we have
> a <- "a"
> a[[5]] <- "b"
> a
[1] "a" NA NA NA "b"
and even
> a <- NULL
> a[[5]] <- "a"
> a
[1] NA NA NA NA "a"
also, we have
> l <- list(1,2,3)
> names(l) <- c("a","b")
> l
$a
[1] 1
$b
[1] 2
$
[1] 3
and we do want to obey general rules like
names(l)[[2]] <- "a"
being (nearly) equivalent to
`*tmp*`<- names(l)
`*tmp*`[[2]] <- "a"
names(l) <- `*tmp*`
- pd
>
> Hadley
>
> --
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN submit page down
Thanks. It is up again. Bill > On Apr 26, 2015, at 12:53 PM, Uwe Ligges > wrote: > > > > On 26.04.2015 13:23, William Revelle wrote: >> This still seems to be the case. >> >> I tried uploading the most recent version of psych and got as far as the >> Step 3 page which says that it has sent out an email. >> However, although normally this step takes agout 1 minute, nothing has >> happened for 16 hours. >> >> Should we just use the old system of uploading to the ftp site and sending a >> confirming email? >> >> Thanks of course to the CRAN maintainers without whom this amazing system >> would not exist. > > The sysadmins in Vienna will try to fix the problems on Monday. > > The submission page says so now. > > I'd be happy if non-urgent package submissions can be deferred until the web > submission page is working again. In case of really urgent submissions, > please go ahead with ftp uploads but *please* send the mails in the format > the CRAN team asks for in the CRAN policies. > > Thanks, sorry for the inconvenience and best wishes, > Uwe Ligges > > > >> >> Bill >> >>> On Apr 23, 2015, at 2:52 PM, Dirk Eddelbuettel wrote: >>> >>> >>> Andrie noticed that first, and I can confirm: from our end, it looks as if >>> the backend to http://cran.r-project.org/submit.html is currently down. >>> >>> Dirk >>> >>> -- >>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> William Revelle >> http://personality-project.org/revelle.html >> Professor http://personality-project.org >> Department of Psychology http://www.wcas.northwestern.edu/psych/ >> Northwestern University http://www.northwestern.edu/ >> Use R for psychology http://personality-project.org/r >> It is 3 minutes to midnight http://www.thebulletin.org >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel William Revellehttp://personality-project.org/revelle.html Professor http://personality-project.org Department of Psychology http://www.wcas.northwestern.edu/psych/ Northwestern Universityhttp://www.northwestern.edu/ Use R for psychology http://personality-project.org/r It is 3 minutes to midnighthttp://www.thebulletin.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Development version of R: Improved nchar(), nzchar() but changed API
> Mark van der Loo > on Mon, 27 Apr 2015 10:26:32 +0200 writes: > Dear Martin, Does the work on nchar mean that bugs #16090 > and #16091 will be resolved [1,2]? > Thanks, Mark > [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16090 > [2] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16091 Dear Mark, no, the changes I've been talking about are not related to the above. I'm not savvy on multi-byte / UTF-8 encodings and so left these in the capable hands of fellow R core members. But thank you for bringing the hijacked thread back on track .. My proposed changes -- after amendments -- are said to break 19 CRAN packages (i.e., R CMD check of these) and about a dozen Bioconductor packages (the latter being somewhat less relevant as bioconductor packages will only have to work for the R 3.2.x series for almost half a year.) It seems that most breakages are from things like if(nchar(someString) > 0) which now gives an error if someString is NA (i.e. NA_character_) but I'm currently arguing that this (error) is desirable, because NA means or and hence a character NA could well be the empty string. Also it seems, that much of the breaking code could have become more efficient and reliable (*) if the programmeRs had used nzchar(), i.e., instead of the above, faster and more reliable is if(nzchar(someString)) Note that nzchar() also gains the new 'keepNA' argument, but the plan is to set the default there to 'keepNA = FALSE', i.e., 100% back compatible. -- (*) because nchar(x) already now can give NA when x contains invalid multibyte characters. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
