Re: [Rd] order function called on a data.frame?

[Michael Lawrence via R-devel]

I guess we could make it do the equivalent of do.call(order, df).

On Mon, May 18, 2020 at 8:32 AM Rui Barradas  wrote:
>
> Hello,
>
> There is a result with lists? I am getting
>
>
> order(list(letters, 1:26))
> #Error in order(list(letters, 1:26)) :
> #  unimplemented type 'list' in 'orderVector1'
>
> order(data.frame(letters, 1:26))
> # [1] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
> #[22] 48 49 50 51 52  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
> #[43] 17 18 19 20 21 22 23 24 25 26
>
>
> And I agree that order with data.frames should give a warning. The
> result is indeed useless:
>
> data.frame(letters, 1:26)[order(data.frame(letters, 1:26)), ]
>
>
> Hope this helps,
>
> Rui Barradas
>
>
> Às 00:19 de 18/05/20, Jan Gorecki escreveu:
> > Hi,
> > base::order main input arguments are defined as:
> >
> > a sequence of numeric, complex, character or logical vectors, all of
> > the same length, or a classed R object
> >
> > When passing a list or a data.frame, the resuts seems to be a bit
> > useless. Shouldn't that raise an error, or at least warning?
> >
> > Best Regards,
> > Jan Gorecki
> >
> > __
> > 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



-- 
Michael Lawrence
Senior Scientist, Data Science and Statistical Computing
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Possible Regression in setClassUnion between 3.5.0 and 3.6.0

[Michael Lawrence via R-devel]

They're stabilizing. All changes are internal and addressing bugs; not
user-facing.

On Tue, Feb 25, 2020 at 5:34 PM Robert Harlow  wrote:
>
> Okay - that makes sense and thanks for looking into this! As an aside, from 
> R-devel's perspective would you say methods are stabilizing again or do you 
> foresee a lot of changes coming in the 4.* series?
>
> On Tue, Feb 25, 2020 at 3:39 PM Michael Lawrence via R-devel 
>  wrote:
>>
>> This seems to work as expected (returning "hi!") in R-devel, but there
>> have been so many destabilizing changes to methods that it would be
>> tough to port this to release. Probably should just wait for 4.0.
>>
>> Michael
>>
>> On Tue, Feb 18, 2020 at 8:00 PM Michael Lawrence  wrote:
>> >
>> > Thanks, I'll look into it.
>> >
>> > On Tue, Feb 18, 2020 at 8:32 AM Ezra Tucker  wrote:
>> > >
>> > > Hi Robert,
>> > >
>> > > This looks like a bug to me (tested in R 3.6.2 on Windows), f(new("a"))
>> > > should return "hi!". I'll add that this DOES work properly in 3.6.1
>> > > which leads me to suspect this could be due to the subtle change in the
>> > > way method dispatch was performed to fix a different bug, in 3.6.2. Can
>> > > anybody else confirm that?
>> > >
>> > >
>> > > On 2/18/2020 9:32 AM, Robert Harlow wrote:
>> > > > I am trying to create a class union of class unions to facilitate 
>> > > > method
>> > > > dispatch. When I execute code in the global environment, everything 
>> > > > acts as
>> > > > expected, however when I put the same code in the context of a package,
>> > > > selectMethod can no longer find the correct method. This first block 
>> > > > below
>> > > > puts the code in the context of a package:
>> > > >
>> > > > fn <- "codefile.R"
>> > > > writeLines(
>> > > >  c(
>> > > >  "setClass('x', slots = list(slot ='character'))",
>> > > >  "setClass('y', slots = list(slot ='character'))",
>> > > >  "setClass('a', slots = list(slot ='character'))",
>> > > >  "setClass('b', slots = list(slot ='character'))",
>> > > >  "setClassUnion('xy', c('x', 'y'))",
>> > > >  "setClassUnion('ab', c('a', 'b'))",
>> > > >  "setClassUnion('xyab', c('xy', 'ab'))",
>> > > >  "setGeneric('f', function(object, ...) standardGeneric('f'))",
>> > > >  "setMethod('f', 'xyab', function(object, ...) print('hi!'))"
>> > > >  ),
>> > > >  con = fn
>> > > > )
>> > > > package.skeleton(code_files = "codefile.R")
>> > > > system("rm -rf anRpackage/man")
>> > > > system("R CMD INSTALL anRpackage")
>> > > > library(anRpackage)
>> > > > ## fails in R 3.6.2, but works in R 3.5.0
>> > > > f(new("a"))
>> > > >
>> > > > Next, if a fresh R 3.6.2 session is started and I execute the 
>> > > > following at
>> > > > the prompt, method dispatch works as expected.
>> > > >
>> > > > setClass("x", slots = list(slot ="character"))
>> > > > setClass("y", slots = list(slot ="character"))
>> > > > setClass("a", slots = list(slot ="character"))
>> > > > setClass("b", slots = list(slot ="character"))
>> > > > setClassUnion("xy", c("x", "y"))
>> > > > setClassUnion("ab", c("a", "b"))
>> > > > setClassUnion("xyab", c("xy", "ab"))
>> > > > setGeneric("f", function(object, ...) standardGeneric("f"))
>> > > > setMethod("f", "xyab", function(object, ...) print("hi!"))
>> > > > ## print's "hi!" as expected
>> > > > f(new("a"))
>> > > >
>> > > > I have also posted to stack overflow here:
>> > > > https://stackoverflow.com/questions/60264786/r-s4-class-union-of-class-unions?noredirect=1#comment106627883_60264786,
>> > > > (the example in this note removes devto

Re: [Rd] Possible Regression in setClassUnion between 3.5.0 and 3.6.0

[Michael Lawrence via R-devel]

This seems to work as expected (returning "hi!") in R-devel, but there
have been so many destabilizing changes to methods that it would be
tough to port this to release. Probably should just wait for 4.0.

Michael

On Tue, Feb 18, 2020 at 8:00 PM Michael Lawrence  wrote:
>
> Thanks, I'll look into it.
>
> On Tue, Feb 18, 2020 at 8:32 AM Ezra Tucker  wrote:
> >
> > Hi Robert,
> >
> > This looks like a bug to me (tested in R 3.6.2 on Windows), f(new("a"))
> > should return "hi!". I'll add that this DOES work properly in 3.6.1
> > which leads me to suspect this could be due to the subtle change in the
> > way method dispatch was performed to fix a different bug, in 3.6.2. Can
> > anybody else confirm that?
> >
> >
> > On 2/18/2020 9:32 AM, Robert Harlow wrote:
> > > I am trying to create a class union of class unions to facilitate method
> > > dispatch. When I execute code in the global environment, everything acts 
> > > as
> > > expected, however when I put the same code in the context of a package,
> > > selectMethod can no longer find the correct method. This first block below
> > > puts the code in the context of a package:
> > >
> > > fn <- "codefile.R"
> > > writeLines(
> > >  c(
> > >  "setClass('x', slots = list(slot ='character'))",
> > >  "setClass('y', slots = list(slot ='character'))",
> > >  "setClass('a', slots = list(slot ='character'))",
> > >  "setClass('b', slots = list(slot ='character'))",
> > >  "setClassUnion('xy', c('x', 'y'))",
> > >  "setClassUnion('ab', c('a', 'b'))",
> > >  "setClassUnion('xyab', c('xy', 'ab'))",
> > >  "setGeneric('f', function(object, ...) standardGeneric('f'))",
> > >  "setMethod('f', 'xyab', function(object, ...) print('hi!'))"
> > >  ),
> > >  con = fn
> > > )
> > > package.skeleton(code_files = "codefile.R")
> > > system("rm -rf anRpackage/man")
> > > system("R CMD INSTALL anRpackage")
> > > library(anRpackage)
> > > ## fails in R 3.6.2, but works in R 3.5.0
> > > f(new("a"))
> > >
> > > Next, if a fresh R 3.6.2 session is started and I execute the following at
> > > the prompt, method dispatch works as expected.
> > >
> > > setClass("x", slots = list(slot ="character"))
> > > setClass("y", slots = list(slot ="character"))
> > > setClass("a", slots = list(slot ="character"))
> > > setClass("b", slots = list(slot ="character"))
> > > setClassUnion("xy", c("x", "y"))
> > > setClassUnion("ab", c("a", "b"))
> > > setClassUnion("xyab", c("xy", "ab"))
> > > setGeneric("f", function(object, ...) standardGeneric("f"))
> > > setMethod("f", "xyab", function(object, ...) print("hi!"))
> > > ## print's "hi!" as expected
> > > f(new("a"))
> > >
> > > I have also posted to stack overflow here:
> > > https://stackoverflow.com/questions/60264786/r-s4-class-union-of-class-unions?noredirect=1#comment106627883_60264786,
> > > (the example in this note removes devtools to make the environment
> > > cleaner).
> > >
> > > Interestingly, the issue only seems to arise when there are > 1 layer
> > > of the class union. E.g. if I were to setMethod on "ab" instead of
> > > "xyab", method dispatch would work as expected. I am not posting a bug
> > > yet as it is still unclear to me if I am doing something incorrect.
> > >
> > > My sessionInfo() is :
> > >
> > > R version 3.6.2 (2019-12-12)
> > > Platform: x86_64-pc-linux-gnu (64-bit)
> > > Running under: Ubuntu 18.04.3 LTS
> > >
> > > Matrix products: default
> > > BLAS:   /usr/local/lib/R/lib/libRblas.so
> > > LAPACK: /usr/local/lib/R/lib/libRlapack.so
> > >
> > > locale:
> > >   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> > >   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> > >   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> > >   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> > >   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> > >
> > > attached base packages:
> > > [1] stats graphics  grDevices utils datasets  methods   base
> > >
> > > other attached packages:
> > > [1] anRpackage_1.0
> > >
> > > loaded via a namespace (and not attached):
> > > [1] compiler_3.6.2 tools_3.6.2
> > >
> > > Thanks in advance for the help!
> > >
> > >   [[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
>
>
>
> --
> Michael Lawrence
> Senior Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube



-- 
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760

Re: [Rd] Possible Regression in setClassUnion between 3.5.0 and 3.6.0

[Michael Lawrence via R-devel]

Thanks, I'll look into it.

On Tue, Feb 18, 2020 at 8:32 AM Ezra Tucker  wrote:
>
> Hi Robert,
>
> This looks like a bug to me (tested in R 3.6.2 on Windows), f(new("a"))
> should return "hi!". I'll add that this DOES work properly in 3.6.1
> which leads me to suspect this could be due to the subtle change in the
> way method dispatch was performed to fix a different bug, in 3.6.2. Can
> anybody else confirm that?
>
>
> On 2/18/2020 9:32 AM, Robert Harlow wrote:
> > I am trying to create a class union of class unions to facilitate method
> > dispatch. When I execute code in the global environment, everything acts as
> > expected, however when I put the same code in the context of a package,
> > selectMethod can no longer find the correct method. This first block below
> > puts the code in the context of a package:
> >
> > fn <- "codefile.R"
> > writeLines(
> >  c(
> >  "setClass('x', slots = list(slot ='character'))",
> >  "setClass('y', slots = list(slot ='character'))",
> >  "setClass('a', slots = list(slot ='character'))",
> >  "setClass('b', slots = list(slot ='character'))",
> >  "setClassUnion('xy', c('x', 'y'))",
> >  "setClassUnion('ab', c('a', 'b'))",
> >  "setClassUnion('xyab', c('xy', 'ab'))",
> >  "setGeneric('f', function(object, ...) standardGeneric('f'))",
> >  "setMethod('f', 'xyab', function(object, ...) print('hi!'))"
> >  ),
> >  con = fn
> > )
> > package.skeleton(code_files = "codefile.R")
> > system("rm -rf anRpackage/man")
> > system("R CMD INSTALL anRpackage")
> > library(anRpackage)
> > ## fails in R 3.6.2, but works in R 3.5.0
> > f(new("a"))
> >
> > Next, if a fresh R 3.6.2 session is started and I execute the following at
> > the prompt, method dispatch works as expected.
> >
> > setClass("x", slots = list(slot ="character"))
> > setClass("y", slots = list(slot ="character"))
> > setClass("a", slots = list(slot ="character"))
> > setClass("b", slots = list(slot ="character"))
> > setClassUnion("xy", c("x", "y"))
> > setClassUnion("ab", c("a", "b"))
> > setClassUnion("xyab", c("xy", "ab"))
> > setGeneric("f", function(object, ...) standardGeneric("f"))
> > setMethod("f", "xyab", function(object, ...) print("hi!"))
> > ## print's "hi!" as expected
> > f(new("a"))
> >
> > I have also posted to stack overflow here:
> > https://stackoverflow.com/questions/60264786/r-s4-class-union-of-class-unions?noredirect=1#comment106627883_60264786,
> > (the example in this note removes devtools to make the environment
> > cleaner).
> >
> > Interestingly, the issue only seems to arise when there are > 1 layer
> > of the class union. E.g. if I were to setMethod on "ab" instead of
> > "xyab", method dispatch would work as expected. I am not posting a bug
> > yet as it is still unclear to me if I am doing something incorrect.
> >
> > My sessionInfo() is :
> >
> > R version 3.6.2 (2019-12-12)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Ubuntu 18.04.3 LTS
> >
> > Matrix products: default
> > BLAS:   /usr/local/lib/R/lib/libRblas.so
> > LAPACK: /usr/local/lib/R/lib/libRlapack.so
> >
> > locale:
> >   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics  grDevices utils datasets  methods   base
> >
> > other attached packages:
> > [1] anRpackage_1.0
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.6.2 tools_3.6.2
> >
> > Thanks in advance for the help!
> >
> >   [[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



-- 
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] How to get an object name from C?

[Michael Lawrence via R-devel]

Since substitute() is implemented in C, you could look at its implementation.

On Fri, Jan 24, 2020 at 1:09 AM Daniel Cegiełka
 wrote:
>
>
> (earlier I sent it as html by mistake).
>
> Hi,
>
> How can I get from C an object name used as a function argument? I
> have sample code in C that gives me access to the name of the function
> being called:
>
>
> SEXP xname(SEXP x)
> {
> const char *fun_name = CHAR(PRINTNAME(CAR(x)));
> x =  CDR(x);
> const char *arg_name = isNull(TAG(x)) ? "" : CHAR(PRINTNAME(TAG(x)));
>
> Rprintf("fn_name: %s, arg_name: %s\n", fun_name, arg_name);
> return R_NilValue;
> }
>
>
> > xname <- function(...) invisible(.External("xname", ...))
> >
> > x1 = 123
> >
> > xname(x1)
> fn_name: xname, var_name:
>
>
> However, I am trying to find a way to access the object name. In the
> documentation I found a solution for named args:
>
>
> > xname(arg = x1)
> fn_name: xname, var_name: arg
>
>
> And I'd like to find the equivalent in C for substitute():
>
> > substitute(x1)
> x1
>
>
> Best regards,
> Daniel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Troubles using numeric in s4 class union

[Michael Lawrence via R-devel]

I've been working on this and will hopefully get a fix checked in today.

On Wed, Nov 27, 2019 at 3:53 AM Martin Maechler
 wrote:
>
> > Ezra Tucker
> > on Mon, 11 Nov 2019 21:47:41 + writes:
>
> > Hi all,
> >
> > I came across an issue in using the Matrix package which made it that I
> > could only subset Matrices using the numeric class, but could not using
> > integers. Steps to reproduce the problem:
> >
> > library(Matrix)
> >
> > # this class has *nothing* to do with Matrix
> > setClass("MyClass",
> > representation(myvalue = "numeric"),
> > prototype(myvalue = NA_real_))
> > # this class also has nothing to do with Matrix
> > setClassUnion("NumOrMyClass", c("numeric", "MyClass"))
> >
> > # this is to demonstrate creating and subsetting a specific Matrix
> > m <- new("dgCMatrix", i = c(2L, 0L, 1L, 2L, 0L, 1L), p = c(0L, 1L, 2L, 4L,
> > 4L, 6L),
> > Dim = c(3L, 5L), Dimnames = list(NULL, NULL), x = c(2, 1, 2, 1, 2, 1),
> > factors = list())
> > # this next line fails:
> > m[1:2, 1:2]
> >
> > The last line fails consistently with R 3.6.1 and Matrix 1.2-17 on a
> > variety of operating systems and computers (tested with ubuntu 19.10 &
> > windows 10). I'll note at this point that without the class union I defined
> > above, the rest of the code works perfectly fine.
> >
> > There are 2 workarounds I've come up with. Firstly, one could change the
> > last line to
> > m[as.numeric(1:2), as.numeric(1:2)]
> > or as.numeric(seq()) or c(1, 2), etc.
> >
> > The other workaround is to change setClassUnion("NumOrMyClass",
> > c("numeric", "MyClass")) to setClassUnion("NumOrMyClass", c("numeric",
> > "double", "integer", "MyClass")), which I believe should be the recommended
> > workaround here.
> >
> > The underlying issue, though, is that I would not have expected *anything*
> > that I write to get in the way of Matrix; in fact, the classes that I
> > defined have nothing to do with Matrix at all. So, I have some fears that
> > this might be a bigger problem, possibly either in Methods or in Base.
> >
> > 1. Can others confirm that this is in fact an issue as I believe it to be?
>
> yes, others have confirmed this is an issue .. (unfortunately
> not in this R-devel thread).
>
> Thank you, Ezra, very much for your helpful report, including a
> simple reproducible example.
>
> > 2. If it is a legitimate issue, have others seen it manifested working with
> > other packages that are not Matrix? In this case, I believe that the class
> > union I defied is somehow interfering with the "index" class union in
> > Matrix, R/AllClass.R, line 809
>
> > 3. Why should the class union I defined interfere with the inner workings
> > of a separate package?
>
> There is no good reason ...
>
> > 4. Is this a bug in Base or Methods?
>
> This is a bug in "base R", in package 'methods'.
>
> The R core team had taken the issue up, already two weeks ago,
> but unfortunately did not get to address this in a definitive
> way.  ==>  I'll remind us about it !
>
> Martin Maechler
> ETH Zurich and R Core
>
>
> > Thank you for your time!
> >
> > Sincerely,
> > Ezra
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] R C api for 'inherits' S3 and S4 objects

[Michael Lawrence via R-devel]

If your goal is to perform multithreaded computations, why not perform
all necessary interactions with R upfront and then compute only on
primitives? It would help for us to understand your use case.

On Fri, Nov 1, 2019 at 4:26 AM Jan Gorecki  wrote:
>
> Dear R developers,
>
> Motivated by discussion about checking inheritance of S3 and S4
> objects (in head matrix/array topic) I would light to shed some light
> on a minor gap about that matter in R C API.
> Currently we are able to check inheritance for S3 class objects from C
> in a robust way (no allocation, thread safe). This is unfortunately
> not possible for S4 classes. I would kindly request new function in R
> C api so it can be achieved for S4 classes with no risk of allocation.
> For reference mentioned functions below. Thank you.
> Jan Gorecki
>
> // S3 inheritance
> bool INHERITS(SEXP x, SEXP char_) {
>   SEXP klass;
>   if (isString(klass = getAttrib(x, R_ClassSymbol))) {
> for (int i=0; i   if (STRING_ELT(klass, i) == char_) return true;
> }
>   }
>   return false;
> }
> // S4 inheritance
> bool Rinherits(SEXP x, SEXP char_) {
>   SEXP vec = PROTECT(ScalarString(char_));
>   SEXP call = PROTECT(lang3(sym_inherits, x, vec));
>   bool ans = LOGICAL(eval(call, R_GlobalEnv))[0]==1;
>   UNPROTECT(2);
>   return ans;
> }
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Senior Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] S4SXP type vs S4 object bit?

[Michael Lawrence via R-devel]

Yes, any object of a class that derives from a basic type, like an
atomic vector for example, will be of the basic SEXP type, with the S4
bit set. This means that a class can extend "integer" and objects of
that class can be treated as any ordinary integer vector. S4SXP is
only for objects that do not derive from another basic type.

Michael

On Tue, Oct 22, 2019 at 1:28 AM Travers Ching  wrote:
>
> I'm trying to understand the R internals a bit better and reading over the
> documentation.
>
> I see that there is a bit related to whether an object is S4
> (S4_OBJECT_MASK), and also the object type S4SXP (25).  The documentation
> makes clear that these two things aren't the same.
>
> But in practice, will the S4-bit and object type ever disagree for S4
> objects?  I know that one can set the bit manually in C; are there any
> practical applications for doing so?
>
> Thank you
> Travers
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] New matrix function

[Michael Lawrence via R-devel]

Thanks for this interesting suggestion, Morgan. While there is no strict
criteria for base R inclusion, one criterion relevant in this case is that
the usefulness of a feature be proven in the package space first.

Michael


On Fri, Oct 11, 2019 at 5:19 AM Morgan Morgan 
wrote:

> On Fri, 11 Oct 2019 10:45 Duncan Murdoch, 
> wrote:
>
> > On 11/10/2019 6:44 a.m., Morgan Morgan wrote:
> > > Hi All,
> > >
> > > I was looking for a function to find a small matrix inside a larger
> > matrix
> > > in R similar to the one described in the following link:
> > >
> > >
> >
> https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix
> > >
> > > I couldn't find anything.
> > >
> > > The above function can be seen as a "generalisation" of the "which"
> > > function as well as the function described in the following post:
> > >
> > >
> >
> https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/
> > >
> > > Would be possible to add such a function to base R?
> > >
> > > I am happy to work with someone from the R core team (if you wish) and
> > > suggest an implementation in C.
> >
> > That seems like it would sometimes be a useful function, and maybe
> > someone will point out a package that already contains it.  But if not,
> > why would it belong in base R?
> >
>
> If someone already implemented it, that would great indeed. I think it is a
> very general and basic function, hence base R could be a good place for it?
>
> But this is probably not a good reason; maybe someone from the R core team
> can shed some light on how they decide whether or not to include a function
> in base R?
>
>
> > Duncan Murdoch
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

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

Re: [Rd] Cryptic error message from namespaceExport

[Michael Lawrence via R-devel]

Thanks. The error message will now say:

undefined exports: class inla

Will check-in after running more tests.


On Fri, Sep 6, 2019 at 10:19 AM Thierry Onkelinx 
wrote:

> Dear Michael,
>
> my package has setOldClass("inla") and the NAMESPACE
> contains exportClasses(inla) and importFrom(INLA, inla.posterior.sample)
>
> the old version of INLA uses the S3 class "inla" but does not export it.
> the new version of INLA has setOldClass("inla") and the NAMESPACE
> contains exportClasses(inla)
>
> installing my package in combination with an older INLA version works
>
> install.packages("
> https://inla.r-inla-download.org/R/stable/src/contrib/INLA_18.07.12.tar.gz;,
> repos = NULL)
> remotes::install_github("inbo/inlatools", upgrade = FALSE, force = TRUE)
>
> installing my package with a recent INLA versions yields the error
>
> install.packages("
> https://inla.r-inla-download.org/R/stable/src/contrib/INLA_19.09.03.tar.gz;,
> repos = NULL)
> remotes::install_github("inbo/inlatools", upgrade = FALSE, force = TRUE)
>
> Warning: INLA is a very large package. The old version is 87 MB, the new
> one 250 MB
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
>
> ///
>
> 
>
>
> Op vr 6 sep. 2019 om 17:16 schreef Michael Lawrence <
> lawrence.mich...@gene.com>:
>
>> Just to clarify, your package is exporting a class that is not
>> defined? Or is it exporting a class that is defined by a dependency
>> and then masked by setOldClass()? A simple reproducible example would
>> help.
>>
>> On Fri, Sep 6, 2019 at 7:48 AM Thierry Onkelinx via R-devel
>>  wrote:
>> >
>> > Dear all,
>> >
>> > Today I got this error message (R 3.6.1) when installing my package:
>> >
>> > Error: package or namespace load failed for ‘inlatools’ in
>> > namespaceExport(ns, exports):
>> >  undefined exports: .__C__inla
>> >
>> > My package was using setOldClass("inla") and exported the "inla" class
>> via
>> > the NAMESPACE. It imports functions from the INLA package. Older
>> versions
>> > of the INLA package did not export the "inla" class. Hence the use of
>> > setOldClass().
>> > The current version of the INLA package does export the "inla" class
>> > through it NAMESPACE. This triggered the error described above.
>> >
>> > Is the possible to improve this error message? The current message is
>> > misleading as neither packages contain the string ".__C__inla"
>> >
>> > Best regards,
>> >
>> > ir. Thierry Onkelinx
>> > Statisticus / Statistician
>> >
>> > Vlaamse Overheid / Government of Flanders
>> > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
>> AND
>> > FOREST
>> > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
>> > thierry.onkel...@inbo.be
>> > Havenlaan 88 bus 73, 1000 Brussel
>> > www.inbo.be
>> >
>> >
>> ///
>> > To call in the statistician after the experiment is done may be no more
>> > than asking him to perform a post-mortem examination: he may be able to
>> say
>> > what the experiment died of. ~ Sir Ronald Aylmer Fisher
>> > The plural of anecdote is not data. ~ Roger Brinner
>> > The combination of some data and an aching desire for an answer does not
>> > ensure that a reasonable answer can be extracted from a given body of
>> data.
>> > ~ John Tukey
>> >
>> ///
>> >
>> > 
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>> --
>> Michael Lawrence
>> Scientist, Bioinformatics and Computational Biology
>> Genentech, A Member of the Roche Group
>> Office +1 (650) 225-7760
>> micha...@gene.com
>>
>> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>>
>

-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760

Re: [Rd] Should slot<-() alter its first argument?

[Michael Lawrence via R-devel]

The core of Bioconductor and the methods package itself once took
advantage of this "feature" to avoid unnecessary duplication. Since
the introduction of shallow copying, those abuses have been removed.

Note that these assignment functions always have issues due to
optimizations that assume <-() is called. For example,

>  setClass("Z", rep=representation(x="character"))
> z <- new("Z", x="orig")

> z2 <- `@<-`(z, "x", value="newer")
> .Internal(inspect(z2)) # NAMED==1, as it should be
@565446e0bdf8 25 S4SXP g0c0 [OBJ,NAM(1),S4,gp=0x10,ATT]

> `@<-`(z2, "x", value="newest")
An object of class "Z"
Slot "x":
[1] "newest"
> z2 # modified in place due to NAMED==1, because we assume assignment back to 
> itself
An object of class "Z"
Slot "x":
[1] "newest"

Since we assume <-() bumps NAMED, z2 has its NAMED cleared even though
it's obviously named:
> z2 <- `@<-`(z, "x", value="newer")
> .Internal(inspect(z2))
@56544726ae60 25 S4SXP g0c0 [OBJ,NAM(1),S4,gp=0x10,ATT]
> .Internal(inspect(`@<-`(z2, "x", value="newest"))) # NAMED == 0, same address 
> as above
@56544726ae60 25 S4SXP g0c0 [OBJ,S4,gp=0x10,ATT]

So I guess we could make slot<-() a bit safer but unless we give up
the optimizations or maybe inform the "gets" functions that they are
being called outside of complex assignment, there will be exploits.

Michael

On Thu, Sep 19, 2019 at 11:19 AM William Dunlap via R-devel
 wrote:
>
> We noticed that the slot<- function alters its first argument, which goes
> against the grain of a functional language.  The similar @<- does not
> change its first argument.  Is this intended?  The timeSeries and distr
> package depend on this altering.
>
> > setClass("Z", rep=representation(x="character"))
> > z <- new("Z", x="orig")
> > `@<-`(z, "x", value="newer")
> An object of class "Z"
> Slot "x":
> [1] "newer"
>
> > z
> An object of class "Z"
> Slot "x":
> [1] "orig"
>
> >
> > `slot<-`(z, "x", value="newest")
> An object of class "Z"
> Slot "x":
> [1] "newest"
>
> > z
> An object of class "Z"
> Slot "x":
> [1] "newest"
>
> 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



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Cryptic error message from namespaceExport

[Michael Lawrence via R-devel]

Just to clarify, your package is exporting a class that is not
defined? Or is it exporting a class that is defined by a dependency
and then masked by setOldClass()? A simple reproducible example would
help.

On Fri, Sep 6, 2019 at 7:48 AM Thierry Onkelinx via R-devel
 wrote:
>
> Dear all,
>
> Today I got this error message (R 3.6.1) when installing my package:
>
> Error: package or namespace load failed for ‘inlatools’ in
> namespaceExport(ns, exports):
>  undefined exports: .__C__inla
>
> My package was using setOldClass("inla") and exported the "inla" class via
> the NAMESPACE. It imports functions from the INLA package. Older versions
> of the INLA package did not export the "inla" class. Hence the use of
> setOldClass().
> The current version of the INLA package does export the "inla" class
> through it NAMESPACE. This triggered the error described above.
>
> Is the possible to improve this error message? The current message is
> misleading as neither packages contain the string ".__C__inla"
>
> Best regards,
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> ///
>
> 
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Feature request: non-dropping regmatches/strextract

[Michael Lawrence via R-devel]

After some discussion within R core, we decided that a "nomatch"
argument on regmatches() may be a good initial step. We might add a
new function later that combines the regexpr() and regmatches() steps.
The gregexpr() and regexec() inputs are both lists so it's not clear
whether a "nomatch" value would be relevant (the elements are empty)
in those cases.

On Mon, Sep 2, 2019 at 11:38 AM Cyclic Group Z_1
 wrote:
>
> I think that's a good reason for not including this in regmatches; you're 
> right, its name is somewhat suggestive of yielding matches. Also, that sounds 
> like a great design for strcapture with an atomic prototype.
>
> Best,
> CG



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Feature request: non-dropping regmatches/strextract

[Michael Lawrence via R-devel]

Just started thinking about this. The name of regmatches() suggests
that it will only extract the matches but not return anything for the
non-matches. We might need another function that returns a value for
non-matches. Perhaps the value should be the empty string for
non-matches and NA for matches to NA. The rationale is that we
delegate to regexpr() (at least conceptually), and it returns a
"matching region" which would be empty when there is no match. We
could allow strcapture() to accept an atomic vector as a prototype,
which would do what you want for regexec() (NA on no match, empty
string on empty capture). Then we could call the regexpr()-based
function strextract().

What do you think?

Michael

On Thu, Aug 29, 2019 at 3:27 PM Cyclic Group Z_1
 wrote:
>
> Thank you! I greatly appreciate your consideration, though of course it is up 
> to you. I think many people switch to stringr/stringi simply because 
> functions in those packages have some consistent design choices, for example, 
> they do not drop empty/missing matches, which facilitates array-based 
> programming. For example, in the cases where one needs to make a new column 
> in a data.frame (data.table, tibble, etc.) of regex extractions. Or in any 
> other case where there needs to be an element-wise correspondence between 
> input and output. I think insertion of NA_character_ to prevent dropping 
> indices seems like the natural choice for an array language (which, I think, 
> motivated the creation of stringr/stringi). While those are great packages 
> and this behavior can be easily replicated with simple wrappers, string 
> operations are normally easy to accomplish in base languages, so this seems 
> like something that would be appropriate to have in base. For example, MATLAB 
> and Pandas regex both all
 ow non-dropping empty matches (though of course I acknowledge Pandas is not a 
base language).
>
> Best,
> CG



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Feature request: non-dropping regmatches/strextract

[Michael Lawrence via R-devel]

I'd be happy to entertain patches or at least more specific
suggestions to improve strextract() and strcapture(). I hadn't
exported strextract(), because I wasn't quite sure how it should
behave. This feedback should be helpful.

Thanks,
Michael

On Thu, Aug 29, 2019 at 2:20 PM Cyclic Group Z_1 via R-devel
 wrote:
>
> Thank you, I am aware that there are packages that can accomplish this. I 
> mentioned stringr::str_extract as a function that does not drop empty 
> matches. I think that the behavior of regmatches(..., regexpr(...)) in base R 
> should permit an option to prevent dropping of empty matches both for sake of 
> consistency with the rest of the language (missing data does not yield a 
> dropped index in other sorts of R functions, and an empty match conceptually 
> corresponds with missing data) and facility of use in data.frames. The 
> behavior of regmatches(..., gregexpr(...)) is not objectionable to me, as 
> lists do not drop indices when they contain character(0) vectors. 
> Alternatively, perhaps this should be reflected in the (currently 
> non-exported) strextract.
>
> Best,
> CG
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Any plans for ALTREP lists (VECSXP)?

[Michael Lawrence via R-devel]

Hi Kylie,

As an alternative in the short term, you could consider deriving from
S4Vector's List class, implementing the getListElement() method to
lazily create the objects.

Michael

On Tue, Jul 23, 2019 at 9:09 AM Bemis, Kylie  wrote:
>
> Hello,
>
> I was wondering if there were any plans for ALTREP lists (VECSXP)?
>
> It seems to me that they could be supported in a similar way to how ALTSTRING 
> works, with Elt() and Set_elt() methods, or would there be some problems with 
> that I’m not seeing due to lists not being atomic vectors?
>
> I was taking an approach of converting each list element (of a file-based 
> list data structure) to an ALTREP representation to build up an “ALTREP list”.
>
> This seems fine for shorter lists with large elements, but I noticed that for 
> longer lists with smaller elements, this could be far more time-consuming 
> than simply reading the entire list into memory and returning a non-ALTREP 
> list:
>
> > x
> <34840 length> matter_list :: out-of-memory list
> (1.1 MB real | 543.3 MB virtual)
>
> > system.time(y <- as.list(x))
>user  system elapsed
>   1.116   2.175   5.053
>
> > system.time(z <- as.altrep(x))
>user  system elapsed
>  36.295   4.717  41.216
>
> > .Internal(inspect(y))
> @108255000 19 VECSXP g1c7 [MARK,NAM(7)] (len=34840, tl=0)
>   @7f9044d9fc00 14 REALSXP g1c7 [MARK] (len=1129, tl=0) 
> 404.093,404.096,404.099,404.102,404.105,...
>   @7f9044d25e00 14 REALSXP g1c7 [MARK] (len=890, tl=0) 
> 409.924,409.927,409.931,409.934,409.937,...
>   @7f9044da6000 14 REALSXP g1c7 [MARK] (len=1878, tl=0) 
> 400.3,400.303,400.306,400.309,400.312,...
>   @7f9031a6b000 14 REALSXP g1c7 [MARK] (len=2266, tl=0) 
> 402.179,402.182,402.185,402.188,402.191,...
>   @7f9031a77a00 14 REALSXP g1c7 [MARK] (len=1981, tl=0) 
> 403.021,403.024,403.027,403.03,403.033,...
>   ...
>
> > .Internal(inspect(z))
> @10821 19 VECSXP g1c7 [MARK,NAM(7)] (len=34840, tl=0)
>   @7f904eea7660 14 REALSXP g1c0 [MARK,NAM(7)] matter vector (mode=4, 
> len=1129, mem=0)
>   @7f9050347498 14 REALSXP g1c0 [MARK,NAM(7)] matter vector (mode=4, len=890, 
> mem=0)
>   @7f904d286b20 14 REALSXP g1c0 [MARK,NAM(7)] matter vector (mode=4, 
> len=1878, mem=0)
>   @7f904fd38820 14 REALSXP g1c0 [MARK,NAM(7)] matter vector (mode=4, 
> len=2266, mem=0)
>   @7f904c75ce90 14 REALSXP g1c0 [MARK,NAM(7)] matter vector (mode=4, 
> len=1981, mem=0)
>   ...
>
> In this situation, it would be much faster and simpler for me to return a 
> theoretical ALTREP list that serves SEXP elements on-demand, similar to how 
> ALTSTRING seems to be implemented.
>
> I don’t know how many other people would get a use out of ALTREP lists, but I 
> certainly would.
>
> Are there any plans for this?
>
> Thanks!
>
> ~~~
> Kylie Ariel Bemis
> Khoury College of Computer Sciences
> Northeastern University
> kuwisdelu.github.io
>
>
>
>
>
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined

[Michael Lawrence via R-devel]

I'm unable to reproduce this with R 3.6.1. Which version are you
using? Is this a fresh session?

On Mon, Jul 15, 2019 at 3:25 AM Ghiggi Gionata  wrote:
>
> Hi all !
>
> I noticed a strange behaviour of the function `class<-` when a class-specific 
> '[[.' method is defined.
>
> Here below a reproducible example :
>
>
> #---.
>
> counttt <- 0
>
> `[[.MYCLASS` = function(x, ...) {
>   counttt <<- counttt + 1
>   # browser()
>   x = NextMethod()
>   return(x)
> }
>
> df <- as.data.frame(matrix(1:20, nrow=5))
> class(df) <- c("MYCLASS","data.frame")
> counttt
>
> # The same occurs when using structure(, class=) or attr(,"class")<-
> df <- as.data.frame(matrix(1:20, nrow=5))
> df <- structure(df, class=c("MYCLASS","data.frame"))
> attr(df, "class") <- c("MYCLASS","data.frame")
>
> #---.
>
> Why in this example `class<-` is calling  `[[.MYCLASS` 9 times ?
>
> Is there a way to avoid `class<-` to call `[[.MYCLASS` ?
>
>
> Thank you in advance for your help and suggestions.
>
> Gionata
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] Format printing inside a matrix

[Michael Lawrence via R-devel]

A generic for displaying an object in a cell would be a reasonable
solution for this particular problem. However, as soon as you start
treating these objects as data (like putting them into a matrix),
you're likely going to want vectorized operations over them, which
means formalized vector and matrix classes. S4Vectors in Bioconductor
facilitates this for vectors, but not for higher-order arrays.

Michael

On Sun, Jul 7, 2019 at 4:44 PM Abby Spurdle  wrote:
>
> > I am not sure if there is an existing solution to this, but I want my S4
> > objects inside a list matrix showing correctly.
> > R> matrix(lst, 2)
> >  [,1] [,2] [,3] [,4] [,5]
> > [1,] ?????
> > [2,] ?????
> > Is it possible that the print method for matrix can call some type of
> generic
> > such as `as.character` or `format` when it encounters such cases?
>
> I had some difficulty understanding this question.
> So, I'm going to paraphrase it.
>
> R, to the best of my knowledge, does not support object arrays, as such.
> (Or if it does, I've certainly missed the memo on this one).
>
> The closest option, is to create an (S3) list of (S3 or S4) objects.
> This is sufficient in the one-dimension case.
> However, to provide functionality of two- or three-dimensional object
> arrays, one can create a matrix (or array) from the list.
>
> It's desirable to print such matrices and arrays.
> This is possible but the output contains an array of question marks, which
> isn't helpful.
>
> Would it be possible for the print method for both matrices and arrays
> (conditional on having a list type), call the format method for each
> object, possibly creating a character matrix?
> Presumably there are other approaches, but the main thing is that the
> output is useful and it's easy for R users to control the way objects (in
> matrices and arrays) are printed.
>
> > Or is there any other place that I can override without introducing a new
> S3 class?
>
> In theory, the simplest approach is to redefine the print method for
> matrices.
> However, that would be unacceptable in a CRAN package, probably...
>
> So, unless R Core change the print method, you may have to create a matrix
> subclass.
>
>
> Abs
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

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

Re: [Rd] topenv of emptyenv

[Michael Lawrence via R-devel]

And it is used profusely by the methods package.

On Thu, Mar 28, 2019 at 4:53 AM Gábor Csárdi  wrote:

> On Thu, Mar 28, 2019 at 11:43 AM Martin Maechler
>  wrote:
> [...]
> >
> > Indeed... and as I mentioned I had never actively noticed the
> > use of topenv() at all...
>
> FWIW topenv() is used in a couple of packages, although some of these
> are false positives:
> https://github.com/search?q=org%3Acran+topenv=Code
>
> Gabor
>
> [...]
>
> __
> 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

Re: [Rd] [RFC] readtable enhancement

[Michael Lawrence via R-devel]

Gabe described my main concern. Specifying a coercion function asserts that
the data (1) were what was expected and (2) were converted into what was
expected. Allowing a coercer to delegate to a "next method" is a good idea,
but keep in mind that any function that did that would not confer the
beneficial constraints mentioned above.

We can continue the discussion at:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17546

Michael

On Thu, Mar 28, 2019 at 1:35 AM Kurt Van Dijck <
dev.k...@vandijck-laurijssen.be> wrote:

> On wo, 27 mrt 2019 22:55:06 -0700, Gabriel Becker wrote:
> >Kurt,
> >Cool idea and great "seeing new faces" on here proposing things on
> here
> >and engaging with R-core on here.
> >Some comments on the issue of fallbacks below.
> >On Wed, Mar 27, 2019 at 10:33 PM Kurt Van Dijck
> ><[1]dev.k...@vandijck-laurijssen.be> wrote:
> >
> >  Hey,
> >  In the meantime, I submitted a bug. Thanks for the assistence on
> >  that.
> >  >and I'm not convinced that
> >  >coercion failures should fallback gracefully to the default.
> >  the gracefull fallback:
> >  - makes the code more complex
> >  + keeps colConvert implementations limited
> >  + requires the user to only implement what changed from the default
> >  + seemed to me to smallest overall effort
> >  In my opinion, gracefull fallback makes the thing better,
> >  but without it, the colConvert parameter remains usefull, it would
> >  still
> >  fill a gap.
> >
> >Another way of viewing coercion failure, I think, is that either the
> >user-supplied converter has a bug in it or was mistakenly applied in a
> >situation where it shouldn't have been. If thats the case the fail
> >early and loud paradigm might ultimately be more helpful to users
> >there.
> >Another thought in the same vein is that if fallback occurs, the
> >returned result will not be what the user asked for and is expecting.
> >So either their code which assumes (e.g., that a column has correctly
> >parsed as a date) is going to break in mysterious (to them) ways, or
> >they have to put a bunch of their own checking logic after the call to
> >see if their converters actually worked in order to protect themselves
> >from that.  Neither really seems ideal to me; I think an error would
> be
> >better, myself. I'm more of a software developer than a script
> >writer/analyst though, so its possible others' opinions would differ
> >(though I'd be a bit surprised by that in this particular case given
> >the danger).
>
> I see.
> So if we provide a default colConvert, named e.g. colConvertBuiltin,
> which is used if colConvert is not given?
> 1) This respects the 'fail early and loud'.
> 2) The user would get what he asks for
> 3) A colConvert implementation would be able to call colConvertBuiltin
> manually if desired, so have colConvert limited to adding on top of the
> default implementation.
>
> If this is acceptable, I'll prepare a new patch.
>
> Kind regards,
> Kurt
>

[[alternative HTML version deleted]]

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

Re: [Rd] [RFC] readtable enhancement

[Michael Lawrence via R-devel]

This has some nice properties:

1) It self-documents the input expectations in a similar manner to
colClasses.
2) The implementation could eventually "push down" the coercion, e.g.,
calling it on each chunk of an iterative read operation.

The implementation needs work though, and I'm not convinced that coercion
failures should fallback gracefully to the default.

Feature requests fall under a "bug" in bugzilla terminology, so please
submit this there. I think I've made you an account.

Thanks,
Michael

On Wed, Mar 27, 2019 at 1:19 PM Kurt Van Dijck <
dev.k...@vandijck-laurijssen.be> wrote:

> Thank you for your answers.
> I rather do not file a new bug, since what I coded isn't really a bug.
>
> The problem I (my colleagues) have today is very stupid:
> We read .csv files with a lot of columns, of which most contain
> date-time stamps, coded in DD/MM/ HH:MM.
> This is not exotic, but the base library's readtable (and derivatives)
> only accept date-times in a limited number of possible formats (which I
> understand very well).
>
> We could specify a format in a rather complicated format, for each
> column individually, but this syntax is rather difficult to maintain.
>
> My solution to this specific problem became trivial, yet generic
> extension to read.table.
> Rather than relying on the built-in type detection, I added a parameter
> to a function that will be called for each to-be-type-probed column so I
> can overrule the built-in limited default.
> If nothing returns from the function, the built-in default is still
> used.
>
> This way, I could construct a type-probing function that is
> straight-forward, not hard to code, and makes reading my .csv files
> acceptible in terms of code (read.table parameters).
>
> I'm sure I'm not the only one dealing with such needs, escpecially
> date-time formats exist in enormous amounts, but I want to stress here
> that my approach is agnostic to my specific problem.
>
> For those asking to 'show me the code', I redirect to my 2nd patch,
> where the tests have been extended with my specific problem.
>
> What are your opinions about this?
>
> Kind regards,
> Kurt
>
> __
> 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

Re: [Rd] [PATCH 1/2] readtable: add hook for type conversions per column

[Michael Lawrence via R-devel]

Please file a bug on bugzilla so we can discuss this further.

On Tue, Mar 26, 2019 at 11:53 AM Kurt Van Dijck <
dev.k...@vandijck-laurijssen.be> wrote:

> Hello,
>
> I want to find out if this patch is ok or not, and if not, what should
> change.
>
> Kind regards,
> Kurt
>
> __
> 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

Re: [Rd] selectMethod() can fail to find methods in situations of multiple dispatch

[Michael Lawrence via R-devel]

Agreed but I'm not sure we want users accessing documentation with those
types of aliases. One option is the method?foo("numeric") syntax.

On Thu, Mar 21, 2019 at 9:52 PM Pages, Herve  wrote:

> Fine with me as long as eliminating the inconveniences associated with it
> can be put on the roadmap. The alias instability and the fact that the user
> has no way to know if s/he should do ?`foo,numeric-method` or
> ?`foo,numeric,ANY-method` to find the method has been a long-standing
> problem.
>
> H.
> On 3/21/19 21:29, Michael Lawrence wrote:
>
> If we started over, I'd try to avoid this sort of complexity, but "ANY"
> truncation has been happening since at least 2003.
>
> > matchSignature(c("numeric", "ANY"), foo)
> x
> "numeric"
>
> So I'm not sure we want to mess with it.
>
> Michael
>
> On Thu, Mar 21, 2019 at 8:14 PM Pages, Herve  wrote:
>
>> Hi Michael,
>>
>> Thanks for looking into this. I suspect that truncation of ANY suffixes
>> from method signatures is also the culprit behind the sudden breakage of
>> aliases of the form \alias{foo,numeric-method} when a method without the
>> ANY suffix in its signature gets added to the ecosystem. See my post about
>> this to the Bioc-devel mailing list a couple of months ago:
>> https://stat.ethz.ch/pipermail/bioc-devel/2019-January/014603.html
>> 
>>
>> So overall isn't this truncation more trouble than it's worth?
>>
>> H.
>> On 3/19/19 10:12, Michael Lawrence wrote:
>>
>> This is due to the intentional truncation of ANY suffixes from method
>> signatures. I've hacked selectMethod() to be robust to that and will commit
>> soon. Thanks for the report.
>>
>> Michael
>>
>> On Thu, Mar 14, 2019 at 9:32 AM Pages, Herve 
>> wrote:
>>
>>> Here is an example:
>>>
>>>   setGeneric("foo", function(x, y) standardGeneric("foo"))
>>>
>>>   setMethod("foo", c("numeric", "ANY"),
>>> function(x, y) cat("I'm the foo#numeric#ANY method\n")
>>>   )
>>>
>>>
>>> Dispatch works as expected but selectMethod() fails to find the method:
>>>
>>>
>>>   > foo(1, TRUE)
>>>   I'm the foo#numeric#ANY method
>>>
>>>   > selectMethod("foo", c("numeric", "logical"))
>>>   Error in selectMethod("foo", c("numeric", "logical")) :
>>> no method found for signature numeric, logical
>>>
>>> Adding an arbitrary method that doesn't have ANY in the signature
>>> "fixes" selectMethod():
>>>
>>>   setMethod("foo", c("complex", "integer"),
>>> function(x, y) cat("I'm the foo#complex#integer method\n")
>>>   )
>>>
>>> Then:
>>>
>>>   > selectMethod("foo", c("numeric", "logical"))
>>>   Method Definition:
>>>
>>>   function (x, y)
>>>   cat("I'm the foo#numeric#ANY method\n")
>>>
>>>   Signatures:
>>> x y
>>>   target  "numeric" "logical"
>>>   defined "numeric" "ANY"
>>>
>>>
>>> Thanks,
>>>
>>> H.
>>>
>>>
>>> --
>>> Hervé Pagès
>>>
>>> Program in Computational Biology
>>> Division of Public Health Sciences
>>> Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N, M1-B514
>>> P.O. Box 19024
>>> Seattle, WA 98109-1024
>>>
>>> E-mail: hpa...@fredhutch.org
>>> Phone:  (206) 667-5791
>>> Fax:(206) 667-1319
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>>
>> --
>> Hervé Pagès
>>
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M1-B514
>> P.O. Box 19024
>> Seattle, WA 98109-1024
>>
>> E-mail: hpa...@fredhutch.org
>> Phone:  (206) 667-5791
>> Fax:(206) 667-1319
>>
>> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] selectMethod() can fail to find methods in situations of multiple dispatch

[Michael Lawrence via R-devel]

If we started over, I'd try to avoid this sort of complexity, but "ANY"
truncation has been happening since at least 2003.

> matchSignature(c("numeric", "ANY"), foo)
x
"numeric"

So I'm not sure we want to mess with it.

Michael

On Thu, Mar 21, 2019 at 8:14 PM Pages, Herve  wrote:

> Hi Michael,
>
> Thanks for looking into this. I suspect that truncation of ANY suffixes
> from method signatures is also the culprit behind the sudden breakage of
> aliases of the form \alias{foo,numeric-method} when a method without the
> ANY suffix in its signature gets added to the ecosystem. See my post about
> this to the Bioc-devel mailing list a couple of months ago:
> https://stat.ethz.ch/pipermail/bioc-devel/2019-January/014603.html
>
> So overall isn't this truncation more trouble than it's worth?
>
> H.
> On 3/19/19 10:12, Michael Lawrence wrote:
>
> This is due to the intentional truncation of ANY suffixes from method
> signatures. I've hacked selectMethod() to be robust to that and will commit
> soon. Thanks for the report.
>
> Michael
>
> On Thu, Mar 14, 2019 at 9:32 AM Pages, Herve  wrote:
>
>> Here is an example:
>>
>>   setGeneric("foo", function(x, y) standardGeneric("foo"))
>>
>>   setMethod("foo", c("numeric", "ANY"),
>> function(x, y) cat("I'm the foo#numeric#ANY method\n")
>>   )
>>
>>
>> Dispatch works as expected but selectMethod() fails to find the method:
>>
>>
>>   > foo(1, TRUE)
>>   I'm the foo#numeric#ANY method
>>
>>   > selectMethod("foo", c("numeric", "logical"))
>>   Error in selectMethod("foo", c("numeric", "logical")) :
>> no method found for signature numeric, logical
>>
>> Adding an arbitrary method that doesn't have ANY in the signature "fixes"
>> selectMethod():
>>
>>   setMethod("foo", c("complex", "integer"),
>> function(x, y) cat("I'm the foo#complex#integer method\n")
>>   )
>>
>> Then:
>>
>>   > selectMethod("foo", c("numeric", "logical"))
>>   Method Definition:
>>
>>   function (x, y)
>>   cat("I'm the foo#numeric#ANY method\n")
>>
>>   Signatures:
>> x y
>>   target  "numeric" "logical"
>>   defined "numeric" "ANY"
>>
>>
>> Thanks,
>>
>> H.
>>
>>
>> --
>> Hervé Pagès
>>
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M1-B514
>> P.O. Box 19024
>> Seattle, WA 98109-1024
>>
>> E-mail: hpa...@fredhutch.org
>> Phone:  (206) 667-5791
>> Fax:(206) 667-1319
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] setClass accepts slot-mismatch between slots and prototype arguments

[Michael Lawrence via R-devel]

Thanks for the report. There is a comment from 2001 in the header for
reconcilePropertiesAndPrototype() that states:

"The prototype may imply slots not in the properties list.  It is not
required that the extends classes be define at this time.  Should it
be?"

But somewhere in the mid 2000's, I think, it became necessary for the
extends classes to be defined, so it may be safe to add this
constraint.

I'll commit a fix soon. While fixing, I found that the type
consistency check for slots shared with superclasses was completely
broken ever since it was written in 2002.

Michael

On Thu, Jan 10, 2019 at 8:31 AM William Dunlap via R-devel
 wrote:
>
> I was installing the 'diffobj' package into TERR and got an error from the
> call
> StyleSummary <- setClass("StyleSummary",
>   slots=c(container="ANY", body="ANY", map="ANY"),
>   prototype=list(
> container=function(x) sprintf("\n%s\n", paste0(x, collapse="")),
> body=identity,
> detail=function(x) sprintf("\n%s\n", paste0("  ", x, collapse="")),
> map=function(x) sprintf("\n%s", paste0("  ", x, collapse="\n"))
>   ))
> because the prototype contained components not in the slots list.  R does
> not complain about the mismatch, but new("StyleSummary") does name make
> something with a 'detail' slot.  Should this be an error?
>
> I suspect that the package writer intended to include 'detail' in the slots
> argument.
>
> 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

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