date:20151007

Re: [Rd] Unexpected failure when calling new() with unnamed arg and

2015-10-07 Thread Joshua Wiley

Hi,

I realize this is an old thread, but just wondering whether a conclusion
was ever reached on this issue?  I'm using formula(NULL) but it would be
nice if default initialization worked for formula classes as well.

Cheers,

Josh


On Thu, May 14, 2015 at 8:13 AM, Hervé Pagès  wrote:

> Thanks Martin for looking into this.  H.
>
>
> On 05/13/2015 03:57 AM, Martin Maechler wrote:
>
>> Hervé Pagès 
>>>  on Tue, 12 May 2015 15:18:42 -0700 writes:
>>>
>>
>> Hi,
>>>
>>
>> The man page for new() suggests that if 'a' is an object with slots
>>> "slot1" and "slot2" and C is a class that extends the class of 'a',
>>> then the 2 following calls should be equivalent:
>>>
>>
>> new("C", a, ...)
>>> new("C", slot1=a@slot1, slot2=a@slot2, ...)
>>>
>>
>> This is generally the case but I just ran into a situation where it's
>>> not. In the following example the former fails while the latter works:
>>>
>>
>> setClass("A", representation(slot1="numeric", slot2="logical"))
>>> setClass("B", contains="A", representation(design="formula"))
>>> setClass("C", contains="B")
>>> a <- new("A", slot1=77, slot2=TRUE)
>>>
>>
>> new("C", a, design=x ~ y)  # fails
>>> new("C", slot1=a@slot1, slot2=a@slot2, design=x ~ y)  # works
>>>
>>
>> Note that new("B", a, design=x ~ y) works so the 3-level class
>>> hierarchy is really needed in order to reproduce.
>>>
>>
>> Probably related to this, I also noted that new("B") and/or new("C")
>>> return invalid objects:
>>>
>>
>> c <- new("C")
>>>
>>
>> validObject(c)
>>> # Error in validObject(c) :
>>> #  invalid class “C” object: invalid object for slot "design"
>>> #  in class "C": got class "S4", should be or extend class "formula"
>>>
>>
>> is(c@design, "formula")
>>> # [1] FALSE
>>>
>>
>> class(c@design)
>>> # [1] "S4"
>>>
>>
>> Note that 'c' can be fixed:
>>>
>>
>> c@design <- formula(NULL)
>>>
>>
>> validObject(c)
>>> # [1] TRUE
>>>
>>
>> Maybe something that the default "initialize" method should take care
>>> of?
>>>
>>
>> Another singularity that is maybe at the root of all of this is that
>>> the "formula" S4 class is virtual:
>>>
>>
>> showClass("formula")
>>> # Virtual Class "formula" [package "methods"]
>>> #
>>> # Slots:
>>> #
>>> # Name:   .S3Class
>>> # Class: character
>>> #
>>> # Extends: "oldClass"
>>>
>>
>> so a bare call to new("formula") fails:
>>>
>>
>> new("formula")
>>> # Error in new("formula") :
>>> #   trying to generate an object from a virtual class ("formula")
>>>
>>
>> Shouldn't new("formula") just return an "empty" S3 formula (like
>>> formula(NULL) does), in the same way that new("integer") returns
>>> an empty ordinary integer vector?
>>>
>>
>> Interesting .. and at least worth following.
>>
>> One problem and historical reason for the current setup seems
>> that the "formula" S3 class is not from 'base' but 'stats' :
>>
>> R's source, src/library/methods/R/BasicClasses.R,
>> lines 524 ff has the following comment block
>>
>> |  .OldClassesPrototypes is a list of S3 classes for which prototype
>> |  objects are known & reasonable.  The classes will reappear in
>> |  .OldClassesList, but will have been initialized first in
>> |  .InitBasicClasses.  NB:  the methods package will NOT set up
>> |  prototypes for S3 classes except those in package base and for "ts"
>> |  (and would rather not do those either).  The package that owns the
>> |  S3 class should have code to call setOldClass in its
>> |  initialization.
>>
>> So, when John Chambers wrote this, he envisioned that the
>> 'stats' package would do "the correct thing" for its own classes.
>> OTOH, as history went, the stats package was never allowed to
>> depend on methods.
>> There are many other S3 classes from 'stats' which also end up
>> similarly, being defined via  setOldClass() and that itself
>> produces a VIRTUAL class.
>> Also, another part of the (R source) comment above is no longer
>> quite accurate, e.g., "data.frame" is in .OldClassesPrototypes
>> but not in .OldClassesList ...
>>
>> As I do agree that "formula" is much more basic than these other classes,
>> I'm currently looking at tweaks to the methods (and stats) code,
>> to get this to work as indeed - you mentioned above -  we
>> already allow "empty S3 formula" objects anyway.
>>
>> ... half an hour later : Indeed, I've been able to use the above
>> information
>> such that  new("formula") and new("formula", y ~ x)
>> work.
>>
>> However, your code above now --- with my changes --- would  fail :
>>
>>   > setClass("A", representation(slot1="numeric", slot2="logical"))
>>   > setClass("B", contains="A", representation(design="formula"))
>>   > setClass("C", contains="B")
>>   Error in reconcilePropertiesAndPrototype(name, slots, prototype,
>> superClasses,  :
>> "B" is not eligible to be the data part of another class (must be a
>> basic class or a virtual class with no slots)
>>   >
>>

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

2015-10-07 Thread Morgan, Martin



> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Cook,
> Malcolm
> Sent: Wednesday, October 07, 2015 3:52 PM
> To: 'Duncan Murdoch'; Matt Dowle; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
> debugging
> 
> What other packages do you have loaded?  Perhaps a BioConductor one that
> loads S4Vectors that announces upon load:
> 
>   Creating a generic function for 'nchar' from package 'base' in package
> 'S4Vectors'

This was introduced as a way around the problem, where the declaration of a 
method was moved to the .onLoad hook

.onLoad <- function(libname, pkgname)
 setMethod("nchar", "Rle", .nchar_Rle)

instead of in the body of the package. The rationale was that the method is 
then created at run-time, when the generic is defined on the user's R, rather 
than at compile time, when the generic is defined on the build system's R. 
There was a subsequent independent report that this did not solve the problem, 
but we were not able to follow up on that.

This is only defined in the current release version of S4Vectors, which is the 
only version expected to straddle R versions with different signatures.

Martin Morgan

> 
> Maybe a red herring...
> 
> ~Malcolm
> 
>  > -Original Message-
>  > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of
> Duncan  > Murdoch  > Sent: Monday, October 05, 2015 6:57 PM  > To: Matt
> Dowle ; r-de...@stat.math.ethz.ch  > Subject: Re:
> [Rd] Error generated by .Internal(nchar) disappears when  > debugging  >  >
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
>  > > Joris Meys  gmail.com> writes:
>  > >
>  > >>
>  > >> Hi all,
>  > >>
>  > >> I have a puzzling problem related to nchar. In R 3.2.1, the internal  > 
> >
> nchar  > >> gained an extra argument (see  > >>
> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
>  > >>
>  > >> I've been testing code using the package copula, and at home I'm  > >>
> still running R 3.2.0 (I know, I know...). When trying the following  > >> 
> code, I
> > > got  > >> an error:
>  > >>
>  > >>> library(copula)
>  > >>> fgmCopula(0.8)
>  > >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
>  > >>   4 arguments passed to .Internal(nchar) which requires 3
>  > >>
>  > >> Cheers
>  > >> Joris
>  > >
>  > >
>  > > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN  >
> > of any package using base::nchar is affected. Could someone check my  > >
> answer here is correct please :
>  > > http://stackoverflow.com/a/32959306/403310
>  >
>  > Nobody has posted a simple reproducible example here, so it's kind of
> hard to  > say.
>  >
>  > I would have guessed that a change to the internal signature of the C code
> > underlying nchar() wouldn't have any effect on a package that called the R
> > nchar() function.
>  >
>  > When I put together my own example (a tiny package containing a
> function  > calling nchar(), built to .zip using R 3.2.2, installed into R 
> 3.2.0), it
> confirmed  > my guess.
>  >
>  > On the other hand, if some package is calling the .Internal function 
> directly,
> I'd  > expect that to break.  Packages shouldn't do that.
>  >
>  > So I'd say there's been no evidence posted of a problem in R here, though
> > there may be problems in some of the packages involved.  I'd welcome an
> > example that provided some usable evidence.
>  >
>  > Duncan Murdoch
>  >
>  > __
>  > 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


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] MARC creator role (was: authorship and citation)

2015-10-07 Thread Achim Zeileis


On Wed, 7 Oct 2015, Tim Keitt wrote:


On Wed, Oct 7, 2015 at 2:39 PM, Duncan Murdoch 
wrote:


I think it was easier to (ab)use that role than to get a "Maintainer"
role added to the standard ones.


Also note that the "creator" in the MARC vocabulary is with respect to a 
_resource_ - which is different from the creation of a _work_ by an 
"author".


In the case of the CRAN repository, the individual resources are the 
packages. And the maintainer is the person who is responsible for a 
package (aka resource) being made available (aka created) on CRAN. Also, 
the maintainer is the contact responsible for the resource.


Therefore, using the "author" role for those who have created the code 
(aka work) and the "creator" role for those who have created the (CRAN) 
package (aka resource) seemed appropriate.



Why bother with the relators list at all?


Certainly, it is better to use a standard vocabulary than creating a new 
domain-specific vocabulary to facilitate communication of the information 
outside the domain. Therefore, both the "person" and the "bibentry" 
objects try to follow models that were well established rather than 
starting out from scratch.



THK

http://www.keittlab.org/

[[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] authorship and citation

2015-10-07 Thread Tim Keitt

On Wed, Oct 7, 2015 at 2:39 PM, Duncan Murdoch 
wrote:

> I think it was easier to (ab)use that role than to get a "Maintainer"
> role added to the standard ones.
>

Why bother with the relators list at all?

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.table reads "i" as NA_complex_

2015-10-07 Thread William Dunlap

Thank you both!

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Oct 7, 2015 at 1:44 PM, peter dalgaard  wrote:

> This is fixed/changed in r-devel:
>
> > str(type.convert("i"))
>  Factor w/ 1 level "i": 1
>
> It was reported on July 18 as PR#16473, if you care.
>
> (Funny how an obscure issue goes unnoticed for a decade, then pops up
> twice independently within a few months. A property of the Poisson process,
> I suppose.)
>
>
> > On 07 Oct 2015, at 22:22 , William Dunlap  wrote:
> >
> > I just noticed that read.table() and type.convert() interpret the string
> "i"
> > as a missing value of type complex.
> >> str(read.table(text=c("i\ni\ni\ni\n")))
> >   'data.frame':   4 obs. of  1 variable:
> >$ V1: cplx  NA NA NA ...
> >> str(type.convert("i"))
> >cplx NA
> >
> > If there are other strings in the column it makes the column character so
> > most people will not notice
> >> str(read.table(text=c("i\nii\niii\niv\n")))
> >   'data.frame':   4 obs. of  1 variable:
> >$ V1: Factor w/ 4 levels "i","ii","iii",..: 1 2 3 4
> >
> > Is this intended?  It surprised me.
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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
>
>
>
>
>
>
>
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

2015-10-07 Thread Cook, Malcolm

OK – definitely a red herring – thanks for following up…

From: Joris Meys [mailto:jorism...@gmail.com]
Sent: Wednesday, October 07, 2015 4:09 PM
To: Cook, Malcolm 
Cc: Duncan Murdoch ; Matt Dowle 
; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

Malcolm,

I tested the code on a clean R 3.2.0 session. Not even in RStudio, just to rule 
that out.

> sessionInfo()
R version 3.2.0 (2015-04-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8 x64 (build 9200)

locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] copula_0.999-13

loaded via a namespace (and not attached):
 [1] Matrix_1.2-0 ADGofTest_0.3tools_3.2.0  pspline_1.0-17
 [5] gsl_1.9-10   mvtnorm_1.0-3grid_3.2.0   stats4_3.2.0
 [9] lattice_0.20-31  stabledist_0.7-0 fortunes_1.5-2


On Wed, Oct 7, 2015 at 9:52 PM, Cook, Malcolm 
mailto:m...@stowers.org>> wrote:
What other packages do you have loaded?  Perhaps a BioConductor one that loads 
S4Vectors that announces upon load:

Creating a generic function for 'nchar' from package 'base' in package 
'S4Vectors'

Maybe a red herring...

~Malcolm

 > -Original Message-
 > From: R-devel 
 > [mailto:r-devel-boun...@r-project.org] 
 > On Behalf Of Duncan
 > Murdoch
 > Sent: Monday, October 05, 2015 6:57 PM
 > To: Matt Dowle mailto:mattjdo...@gmail.com>>; 
 > r-de...@stat.math.ethz.ch
 > Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
 > debugging
 >
 > On 05/10/2015 7:24 PM, Matt Dowle wrote:
 > > Joris Meys  gmail.com> writes:
 > >
 > >>
 > >> Hi all,
 > >>
 > >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
 > > nchar
 > >> gained an extra argument (see
 > >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
 > >>
 > >> I've been testing code using the package copula, and at home I'm
 > >> still running R 3.2.0 (I know, I know...). When trying the following
 > >> code, I
 > > got
 > >> an error:
 > >>
 > >>> library(copula)
 > >>> fgmCopula(0.8)
 > >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
 > >>   4 arguments passed to .Internal(nchar) which requires 3
 > >>
 > >> Cheers
 > >> Joris
 > >
 > >
 > > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN
 > > of any package using base::nchar is affected. Could someone check my
 > > answer here is correct please :
 > > http://stackoverflow.com/a/32959306/403310
 >
 > Nobody has posted a simple reproducible example here, so it's kind of hard to
 > say.
 >
 > I would have guessed that a change to the internal signature of the C code
 > underlying nchar() wouldn't have any effect on a package that called the R
 > nchar() function.
 >
 > When I put together my own example (a tiny package containing a function
 > calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0), it 
 > confirmed
 > my guess.
 >
 > On the other hand, if some package is calling the .Internal function 
 > directly, I'd
 > expect that to break.  Packages shouldn't do that.
 >
 > So I'd say there's been no evidence posted of a problem in R here, though
 > there may be problems in some of the packages involved.  I'd welcome an
 > example that provided some usable evidence.
 >
 > Duncan Murdoch
 >
 > __
 > 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



--
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

2015-10-07 Thread Joris Meys

Malcolm,

I tested the code on a clean R 3.2.0 session. Not even in RStudio, just to
rule that out.

> sessionInfo()
R version 3.2.0 (2015-04-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8 x64 (build 9200)

locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] copula_0.999-13

loaded via a namespace (and not attached):
 [1] Matrix_1.2-0 ADGofTest_0.3tools_3.2.0  pspline_1.0-17
 [5] gsl_1.9-10   mvtnorm_1.0-3grid_3.2.0   stats4_3.2.0
 [9] lattice_0.20-31  stabledist_0.7-0 fortunes_1.5-2


On Wed, Oct 7, 2015 at 9:52 PM, Cook, Malcolm  wrote:

> What other packages do you have loaded?  Perhaps a BioConductor one that
> loads S4Vectors that announces upon load:
>
> Creating a generic function for 'nchar' from package 'base' in
> package 'S4Vectors'
>
> Maybe a red herring...
>
> ~Malcolm
>
>  > -Original Message-
>  > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of
> Duncan
>  > Murdoch
>  > Sent: Monday, October 05, 2015 6:57 PM
>  > To: Matt Dowle ; r-de...@stat.math.ethz.ch
>  > Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
>  > debugging
>  >
>  > On 05/10/2015 7:24 PM, Matt Dowle wrote:
>  > > Joris Meys  gmail.com> writes:
>  > >
>  > >>
>  > >> Hi all,
>  > >>
>  > >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
>  > > nchar
>  > >> gained an extra argument (see
>  > >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
>  > >>
>  > >> I've been testing code using the package copula, and at home I'm
>  > >> still running R 3.2.0 (I know, I know...). When trying the following
>  > >> code, I
>  > > got
>  > >> an error:
>  > >>
>  > >>> library(copula)
>  > >>> fgmCopula(0.8)
>  > >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
>  > >>   4 arguments passed to .Internal(nchar) which requires 3
>  > >>
>  > >> Cheers
>  > >> Joris
>  > >
>  > >
>  > > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN
>  > > of any package using base::nchar is affected. Could someone check my
>  > > answer here is correct please :
>  > > http://stackoverflow.com/a/32959306/403310
>  >
>  > Nobody has posted a simple reproducible example here, so it's kind of
> hard to
>  > say.
>  >
>  > I would have guessed that a change to the internal signature of the C
> code
>  > underlying nchar() wouldn't have any effect on a package that called
> the R
>  > nchar() function.
>  >
>  > When I put together my own example (a tiny package containing a function
>  > calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0),
> it confirmed
>  > my guess.
>  >
>  > On the other hand, if some package is calling the .Internal function
> directly, I'd
>  > expect that to break.  Packages shouldn't do that.
>  >
>  > So I'd say there's been no evidence posted of a problem in R here,
> though
>  > there may be problems in some of the packages involved.  I'd welcome an
>  > example that provided some usable evidence.
>  >
>  > Duncan Murdoch
>  >
>  > __
>  > 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
>



-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.table reads "i" as NA_complex_

2015-10-07 Thread peter dalgaard

This is fixed/changed in r-devel:

> str(type.convert("i"))
 Factor w/ 1 level "i": 1

It was reported on July 18 as PR#16473, if you care.

(Funny how an obscure issue goes unnoticed for a decade, then pops up twice 
independently within a few months. A property of the Poisson process, I 
suppose.)


> On 07 Oct 2015, at 22:22 , William Dunlap  wrote:
> 
> I just noticed that read.table() and type.convert() interpret the string "i"
> as a missing value of type complex.
>> str(read.table(text=c("i\ni\ni\ni\n")))
>   'data.frame':   4 obs. of  1 variable:
>$ V1: cplx  NA NA NA ...
>> str(type.convert("i"))
>cplx NA
> 
> If there are other strings in the column it makes the column character so
> most people will not notice
>> str(read.table(text=c("i\nii\niii\niv\n")))
>   'data.frame':   4 obs. of  1 variable:
>$ V1: Factor w/ 4 levels "i","ii","iii",..: 1 2 3 4
> 
> Is this intended?  It surprised me.
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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] read.table reads "i" as NA_complex_

2015-10-07 Thread Prof Brian Ripley


On 07/10/2015 21:22, William Dunlap wrote:

I just noticed that read.table() and type.convert() interpret the string "i"
as a missing value of type complex.
> str(read.table(text=c("i\ni\ni\ni\n")))
'data.frame':   4 obs. of  1 variable:
 $ V1: cplx  NA NA NA ...
> str(type.convert("i"))
 cplx NA

If there are other strings in the column it makes the column character so
most people will not notice
> str(read.table(text=c("i\nii\niii\niv\n")))
'data.frame':   4 obs. of  1 variable:
 $ V1: Factor w/ 4 levels "i","ii","iii",..: 1 2 3 4

Is this intended?  It surprised me.


It was intended (that input is ambiguous), but it is being changed  
from the NEWS file for R-devel:


• type.convert("i") now returns a factor instead of a complex value
  with zero real part and missing imaginary part.

--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
1 South Parks Road, Oxford OX1 3TG, UK

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] read.table reads "i" as NA_complex_

2015-10-07 Thread William Dunlap

I just noticed that read.table() and type.convert() interpret the string "i"
as a missing value of type complex.
   > str(read.table(text=c("i\ni\ni\ni\n")))
   'data.frame':   4 obs. of  1 variable:
$ V1: cplx  NA NA NA ...
   > str(type.convert("i"))
cplx NA

If there are other strings in the column it makes the column character so
most people will not notice
   > str(read.table(text=c("i\nii\niii\niv\n")))
   'data.frame':   4 obs. of  1 variable:
$ V1: Factor w/ 4 levels "i","ii","iii",..: 1 2 3 4

Is this intended?  It surprised me.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

2015-10-07 Thread Cook, Malcolm

What other packages do you have loaded?  Perhaps a BioConductor one that loads 
S4Vectors that announces upon load:

Creating a generic function for 'nchar' from package 'base' in package 
'S4Vectors'

Maybe a red herring...

~Malcolm

 > -Original Message-
 > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan
 > Murdoch
 > Sent: Monday, October 05, 2015 6:57 PM
 > To: Matt Dowle ; r-de...@stat.math.ethz.ch
 > Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
 > debugging
 > 
 > On 05/10/2015 7:24 PM, Matt Dowle wrote:
 > > Joris Meys  gmail.com> writes:
 > >
 > >>
 > >> Hi all,
 > >>
 > >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
 > > nchar
 > >> gained an extra argument (see
 > >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
 > >>
 > >> I've been testing code using the package copula, and at home I'm
 > >> still running R 3.2.0 (I know, I know...). When trying the following
 > >> code, I
 > > got
 > >> an error:
 > >>
 > >>> library(copula)
 > >>> fgmCopula(0.8)
 > >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
 > >>   4 arguments passed to .Internal(nchar) which requires 3
 > >>
 > >> Cheers
 > >> Joris
 > >
 > >
 > > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN
 > > of any package using base::nchar is affected. Could someone check my
 > > answer here is correct please :
 > > http://stackoverflow.com/a/32959306/403310
 > 
 > Nobody has posted a simple reproducible example here, so it's kind of hard to
 > say.
 > 
 > I would have guessed that a change to the internal signature of the C code
 > underlying nchar() wouldn't have any effect on a package that called the R
 > nchar() function.
 > 
 > When I put together my own example (a tiny package containing a function
 > calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0), it 
 > confirmed
 > my guess.
 > 
 > On the other hand, if some package is calling the .Internal function 
 > directly, I'd
 > expect that to break.  Packages shouldn't do that.
 > 
 > So I'd say there's been no evidence posted of a problem in R here, though
 > there may be problems in some of the packages involved.  I'd welcome an
 > example that provided some usable evidence.
 > 
 > Duncan Murdoch
 > 
 > __
 > 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] authorship and citation

2015-10-07 Thread Duncan Murdoch

On 07/10/2015 1:39 PM, Tim Keitt wrote:
> On Wed, Oct 7, 2015 at 11:29 AM, Spencer Graves > wrote:
> 
>> Another example:  The "Author" of the Ecdat package is Yves Croissant <
>> yves.croiss...@let.ish-lyon.cnrs.fr>.  I'm the Maintainer.  At some
>> point, I may add my name to the list of Authors but I certainly would never
>> remove Yves' name.  That package is, I think, exclusively data sets.  I
>> added functions, which I later spun off into a separate Edfun package;  I'm
>> listed as the Author and Maintainer of that.
>>
> 
> This reminded me of something I have always found curious about roles
> listed in the DESCRIPTION file. Since there is no "maintainer" role in this
> list: http://www.loc.gov/marc/relators/relaterm.html, which was used to get
> the role names, you will be listed as the "creator" of the package when you
> list yourself as maintainer even if you did not initiate the package or
> even contribute code.
> 

I think it was easier to (ab)use that role than to get a "Maintainer"
role added to the standard ones.  The description of "creator" is

"A person or organization responsible for the intellectual or artistic
content of a resource"

The usual English meaning of "creator" would be close to

"A person or organization originally responsible for the intellectual or
artistic content of a resource"

R's use of it is close to

"A person or organization currently responsible for the intellectual or
artistic content of a resource"

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

2015-10-07 Thread Tim Keitt

On Wed, Oct 7, 2015 at 11:29 AM, Spencer Graves  wrote:

> Another example:  The "Author" of the Ecdat package is Yves Croissant <
> yves.croiss...@let.ish-lyon.cnrs.fr>.  I'm the Maintainer.  At some
> point, I may add my name to the list of Authors but I certainly would never
> remove Yves' name.  That package is, I think, exclusively data sets.  I
> added functions, which I later spun off into a separate Edfun package;  I'm
> listed as the Author and Maintainer of that.
>

This reminded me of something I have always found curious about roles
listed in the DESCRIPTION file. Since there is no "maintainer" role in this
list: http://www.loc.gov/marc/relators/relaterm.html, which was used to get
the role names, you will be listed as the "creator" of the package when you
list yourself as maintainer even if you did not initiate the package or
even contribute code.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

2015-10-07 Thread Spencer Graves

An example from the sos package:  Its DESCRIPTION file says Author: 
Spencer Graves, Sundar Dorai-Raj, and Romain Francois.  However, the 
package includes a findFn function, whose help file includes an 
Author(s) section, which reads, "Spencer Graves, Sundar Dorai-Raj, 
Romain Francois.  Duncan Murdoch suggested the "???" alias for "findFn" 
and contributed the code for it.  Special thanks to Jonathan Baron and 
Andy Liaw. Baron maintains the RSiteSearch data base. Liaw and Baron 
created the RSiteSearch function in the utils package."



Another example:  The "Author" of the Ecdat package is Yves Croissant 
.  I'm the Maintainer.  At some 
point, I may add my name to the list of Authors but I certainly would 
never remove Yves' name.  That package is, I think, exclusively data 
sets.  I added functions, which I later spun off into a separate Edfun 
package;  I'm listed as the Author and Maintainer of that.



Another example that may help you:  The "distr" package has several 
companion packages:  distrDoc, distrEx, distrSim, distrTEst, distrTeach, 
distrMod, and distrEllipse.  I haven't checked, but each package could 
have a separate and different list of authors.



Hope this helps.
Spencer


On 10/7/2015 9:23 AM, Gabriel Becker wrote:

Hadley,

With all due respect, I'm not sure what exactly your deliniation between
author and contributor is, but from what I can tell I don't agree with it.

>From the blogpost regarding your new purrr package:

"Purrr wouldn’t be possible without Lionel Henry
. He wrote a lot of the package and his
insightful comments ..."

And yet he is listed as a contributor in the DESCRIPTION file, and thus in
your view not worthy of being in the citation even as a non-first author?
That does not jive with what I understand to be "standard practice" with
regard to software-related publications, and it certainly isn't what I
would choose to do in that situation.

Best,
~G

On Wed, Oct 7, 2015 at 4:59 AM, Hadley Wickham  wrote:


On Tue, Oct 6, 2015 at 4:58 PM, Adrian Dușa  wrote:

Hi Gabriel,

On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker 
wrote:


[...]

At the very least, this is seems to be a flagrant violation of the
*spirit* of the CRAN policy, which AFAIK is intended to enforce
acknowledgement of the contributions of all copyright holders in the
package. The fact that you are trying to bypass the policy by suggesting
users use an unofficial citation which would not comply with the policy
while maintaining an official one which complies, but which you don't

want

users to see  is probably a suggestion that you shouldn't do that.



But that is the very point: I read the CRAN policies twice, and there is

no

official guideline on how to compile the citation.
Regarding the Source packages, the policies mention:

##
The ownership of copyright and intellectual property rights of all
components of the package must be clear and unambiguous (including from

the

authors specification in the DESCRIPTION file). Where code is copied (or
derived) from the work of others (including from R itself), care must be
taken that any copyright/license statements are preserved and authorship

is

not misrepresented.
Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the

authors

of such code. Alternatively, the ‘Author’ field should list these authors
as contributors.

Where copyrights are held by an entity other than the package authors,

this

should preferably be indicated via ‘cph’ roles in the ‘Authors@R’

field, or

using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS
file).

Trademarks must be respected.
##

Now, that requirement is already met: the former author is still in the
authors' list. So the contribution of the former author is duly
acknowledged, but the fundamental issue of my question related to the
citation file, for which the CRAN policies doesn't offer any other
information.

If the spirit of the CRAN policies is to enforce citing each and every

one

of the authors, then I don't understand why the citation from package

Rcmdr

meets this spirit, while my suggestion doesn't.

I'd recommend that you read
https://cran.r-project.org/web/packages/shiny/DESCRIPTION and compare
it to citation("shiny"). Authors, but not contributors, all listed in
the citation.

Hadley

--
http://had.co.nz/






__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] A new CSS file for the offline documentation

2015-10-07 Thread Nicolas Drouin

I have made a new CSS file for the R offline documentation.

It's far easier to read, it's lightweight, looks good, cross-browsers,
responsive, and without any bug.

Now my problem is where should I post it so it can be used in the next
version ? And it's not an easy problem...

Any ideas?

The file is here : www.nicolasdrouin.com/R.css

There is no need to change the HTML part just to switch the old CSS files
with this new one.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

2015-10-07 Thread Gabriel Becker

Hadley,

With all due respect, I'm not sure what exactly your deliniation between
author and contributor is, but from what I can tell I don't agree with it.

>From the blogpost regarding your new purrr package:

"Purrr wouldn’t be possible without Lionel Henry
. He wrote a lot of the package and his
insightful comments ..."

And yet he is listed as a contributor in the DESCRIPTION file, and thus in
your view not worthy of being in the citation even as a non-first author?
That does not jive with what I understand to be "standard practice" with
regard to software-related publications, and it certainly isn't what I
would choose to do in that situation.

Best,
~G

On Wed, Oct 7, 2015 at 4:59 AM, Hadley Wickham  wrote:

> On Tue, Oct 6, 2015 at 4:58 PM, Adrian Dușa  wrote:
> > Hi Gabriel,
> >
> > On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker 
> > wrote:
> >
> >> [...]
> >>
> >> At the very least, this is seems to be a flagrant violation of the
> >> *spirit* of the CRAN policy, which AFAIK is intended to enforce
> >> acknowledgement of the contributions of all copyright holders in the
> >> package. The fact that you are trying to bypass the policy by suggesting
> >> users use an unofficial citation which would not comply with the policy
> >> while maintaining an official one which complies, but which you don't
> want
> >> users to see  is probably a suggestion that you shouldn't do that.
> >>
> >
> >
> > But that is the very point: I read the CRAN policies twice, and there is
> no
> > official guideline on how to compile the citation.
> > Regarding the Source packages, the policies mention:
> >
> > ##
> > The ownership of copyright and intellectual property rights of all
> > components of the package must be clear and unambiguous (including from
> the
> > authors specification in the DESCRIPTION file). Where code is copied (or
> > derived) from the work of others (including from R itself), care must be
> > taken that any copyright/license statements are preserved and authorship
> is
> > not misrepresented.
> > Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the
> authors
> > of such code. Alternatively, the ‘Author’ field should list these authors
> > as contributors.
> >
> > Where copyrights are held by an entity other than the package authors,
> this
> > should preferably be indicated via ‘cph’ roles in the ‘Authors@R’
> field, or
> > using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS
> > file).
> >
> > Trademarks must be respected.
> > ##
> >
> > Now, that requirement is already met: the former author is still in the
> > authors' list. So the contribution of the former author is duly
> > acknowledged, but the fundamental issue of my question related to the
> > citation file, for which the CRAN policies doesn't offer any other
> > information.
> >
> > If the spirit of the CRAN policies is to enforce citing each and every
> one
> > of the authors, then I don't understand why the citation from package
> Rcmdr
> > meets this spirit, while my suggestion doesn't.
>
> I'd recommend that you read
> https://cran.r-project.org/web/packages/shiny/DESCRIPTION and compare
> it to citation("shiny"). Authors, but not contributors, all listed in
> the citation.
>
> Hadley
>
> --
> http://had.co.nz/
>



-- 
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

2015-10-07 Thread Hadley Wickham

On Tue, Oct 6, 2015 at 4:58 PM, Adrian Dușa  wrote:
> Hi Gabriel,
>
> On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker 
> wrote:
>
>> [...]
>>
>> At the very least, this is seems to be a flagrant violation of the
>> *spirit* of the CRAN policy, which AFAIK is intended to enforce
>> acknowledgement of the contributions of all copyright holders in the
>> package. The fact that you are trying to bypass the policy by suggesting
>> users use an unofficial citation which would not comply with the policy
>> while maintaining an official one which complies, but which you don't want
>> users to see  is probably a suggestion that you shouldn't do that.
>>
>
>
> But that is the very point: I read the CRAN policies twice, and there is no
> official guideline on how to compile the citation.
> Regarding the Source packages, the policies mention:
>
> ##
> The ownership of copyright and intellectual property rights of all
> components of the package must be clear and unambiguous (including from the
> authors specification in the DESCRIPTION file). Where code is copied (or
> derived) from the work of others (including from R itself), care must be
> taken that any copyright/license statements are preserved and authorship is
> not misrepresented.
> Preferably, an ‘Authors@R’ would be used with ‘ctb’ roles for the authors
> of such code. Alternatively, the ‘Author’ field should list these authors
> as contributors.
>
> Where copyrights are held by an entity other than the package authors, this
> should preferably be indicated via ‘cph’ roles in the ‘Authors@R’ field, or
> using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS
> file).
>
> Trademarks must be respected.
> ##
>
> Now, that requirement is already met: the former author is still in the
> authors' list. So the contribution of the former author is duly
> acknowledged, but the fundamental issue of my question related to the
> citation file, for which the CRAN policies doesn't offer any other
> information.
>
> If the spirit of the CRAN policies is to enforce citing each and every one
> of the authors, then I don't understand why the citation from package Rcmdr
> meets this spirit, while my suggestion doesn't.

I'd recommend that you read
https://cran.r-project.org/web/packages/shiny/DESCRIPTION and compare
it to citation("shiny"). Authors, but not contributors, all listed in
the citation.

Hadley

-- 
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

2015-10-07 Thread S Ellison

> > Is there a point at which the original developer should not stay on the 
> > author
> list?
> 
> Authorship is not just about code.  For example, there are functions in R 
> which
> have been completely recoded, but the design and documentation remain.
> Copyright can apply to designs and there is shading between
> inspiration and infringement.   And many of us believe that inspiration
> should be credited as a moral even if not a legal obligation.

"Once an author on CRAN, always an author on CRAN"* doesn't sound a bad maxim 
to work to.


*This statement should be cited** as
S L R Ellison, C L Dodgson, 'RE: [Rd] authorship and citation'. r-devel mailing 
list, 2015 with 
Acknowledgements: B Ripley, R-Core, S Urbanek for helpful remarks 

**following its own precepts :)


***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If 
you have received this message in error, please notify the sender 
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com 
and delete this message and any copies from your computer and network. 
LGC Limited. Registered in England 2991879. 
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Unexpected failure when calling new() with unnamed arg and

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

Re: [Rd] MARC creator role (was: authorship and citation)

Re: [Rd] authorship and citation

Re: [Rd] read.table reads "i" as NA_complex_

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

Re: [Rd] read.table reads "i" as NA_complex_

Re: [Rd] read.table reads "i" as NA_complex_

[Rd] read.table reads "i" as NA_complex_

Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

Re: [Rd] authorship and citation

Re: [Rd] authorship and citation

Re: [Rd] authorship and citation

[Rd] A new CSS file for the offline documentation

Re: [Rd] authorship and citation

Re: [Rd] authorship and citation

Re: [Rd] authorship and citation

18 matches

Site Navigation

Mail list logo

Footer information