[Rd] Speed-up/Cache loadNamespace()
Dear all, in our current setting we have our packages stored on a (rather slow) network drive and need to invoke short R scripts (using RScript) in a timely manner. Most of the script's runtime is spent with package loading using library() (or loadNamespace to be precise). Is there a way to cache the package namespaces as listed in loadedNamespaces() and load them into memory before the script is executed? My first simplistic attempt was to serialize the environment output from loadNamespace() to a file and load it before the script is started. However, loading the object automatically also loads all the referenced namespaces (from the slow network share) which is undesirable for this use case. Cheers, Mario [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed-up/Cache loadNamespace()
Thanks for the quick responses. As you both suggested storing the packages to local drive is feasible but comes with a size restriction I wanted to avoid. I'll keep this in mind as plan B. @Hugh: 2. would impose even greater slowdowns and 4. is just not feasible. However, 3. sounds interesting - how would this work in a Linux environment? Thank you, Mario Am So., 19. Juli 2020 um 20:11 Uhr schrieb Hugh Parsonage < hugh.parson...@gmail.com>: > My advice would be to avoid the network in one of the following ways > > 1. Store installed packages on your local drive > 2. Copy the installed packages to a tempdir on your local drive each time > the script is executed > 3. Keep an R session running in perpetuity and source the scripts within > that everlasting session > 4. Rewrite your scripts to use base R only. > > I suspect this solution list is exhaustive. > > On Mon, 20 Jul 2020 at 1:50 am, Mario Annau wrote: > >> Dear all, >> >> in our current setting we have our packages stored on a (rather slow) >> network drive and need to invoke short R scripts (using RScript) in a >> timely manner. Most of the script's runtime is spent with package loading >> using library() (or loadNamespace to be precise). >> >> Is there a way to cache the package namespaces as listed in >> loadedNamespaces() and load them into memory before the script is >> executed? >> >> My first simplistic attempt was to serialize the environment output >> from loadNamespace() to a file and load it before the script is started. >> However, loading the object automatically also loads all the referenced >> namespaces (from the slow network share) which is undesirable for this use >> case. >> >> Cheers, >> Mario >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in unsplit() with tibbles
Hello,
using the `unsplit()` function with tibbles currently leads to the
following error:
> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
> s <- split(mtcars_tb, mtcars_tb$gear)
> unsplit(s, mtcars_tb$gear)
Error: Must subset rows with a valid subscript vector.
ℹ Logical subscripts must match the size of the indexed input.
x Input has size 15 but subscript `rep(NA, len)` has size 32.
Run `rlang::last_error()` to see where the error occurred.
Tibble seems to (rightly) complain, that a logical vector has been used for
subsetting which does not have the same length as the data.frame (rows).
Since `NA` is a logical value, the subset should be changed to
`NA_integer_` in `unsplit()`:
> unsplit
function (value, f, drop = FALSE)
{
len <- length(if (is.list(f)) f[[1L]] else f)
if (is.data.frame(value[[1L]])) {
x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
}
else x <- value[[1L]][rep(NA, len)]
split(x, f, drop = drop) <- value
x
}
Cheers,
Mario
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in unsplit() with tibbles
Cool - thank you Peter!
@Marc: This is really not a tidyverse vs base-R debate and I personally
think that they should both work together for most parts. The common
environment is still R. But just to give you the full picture I also filed
a bug for tibbles (https://github.com/tidyverse/tibble/issues/829). With
these two fixes I think that split/unsplit would work for tibbles and users
(like me) just don't have to care in which "environments" they are working
in.
Cheers,
Mario
On Sat, 21 Nov 2020 at 17:54, Peter Dalgaard wrote:
> I get the sentiment, but this is really just bad coding (on my own part, I
> suspect), so we might as well just fix it...
>
> -pd
>
> > On 21 Nov 2020, at 17:42 , Marc Schwartz via R-devel <
> r-devel@r-project.org> wrote:
> >
> >
> >> On Nov 21, 2020, at 10:55 AM, Mario Annau
> wrote:
> >>
> >> Hello,
> >>
> >> using the `unsplit()` function with tibbles currently leads to the
> >> following error:
> >>
> >>> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
> >>> s <- split(mtcars_tb, mtcars_tb$gear)
> >>> unsplit(s, mtcars_tb$gear)
> >> Error: Must subset rows with a valid subscript vector.
> >> ℹ Logical subscripts must match the size of the indexed input.
> >> x Input has size 15 but subscript `rep(NA, len)` has size 32.
> >> Run `rlang::last_error()` to see where the error occurred.
> >>
> >> Tibble seems to (rightly) complain, that a logical vector has been used
> for
> >> subsetting which does not have the same length as the data.frame (rows).
> >> Since `NA` is a logical value, the subset should be changed to
> >> `NA_integer_` in `unsplit()`:
> >>
> >>> unsplit
> >> function (value, f, drop = FALSE)
> >> {
> >> len <- length(if (is.list(f)) f[[1L]] else f)
> >> if (is.data.frame(value[[1L]])) {
> >> x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
> >> rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
> >> }
> >> else x <- value[[1L]][rep(NA, len)]
> >> split(x, f, drop = drop) <- value
> >> x
> >> }
> >>
> >> Cheers,
> >> Mario
> >
> >
> > Hi,
> >
> > Perhaps I am missing something, but if you are using objects, like
> tibbles, that are intended to be part of another environment, in this case
> the tidyverse, why would you not use functions to manipulate these objects
> that were specifically created in the other environment?
> >
> > I don't use the tidyverse, but it seems to me that to expect base R
> functions to work with objects not created in base R, is problematic, even
> though, perhaps by coincidence, they may work without adverse effects, as
> appears to be the case with split().
> >
> > In other words, you should not, in reality, have had an a priori
> expectation that split() would work with a tibble either.
> >
> > Rather than modifying the base R functions, like unsplit(), as you are
> suggesting, to be compatible with these third party objects, the burden
> should either be on you to use relevant tidyverse functions, or on the
> authors of the tidyverse to provide relevant class methods to provide that
> functionality.
> >
> > Regards,
> >
> > Marc Schwartz
> >
> > __
> > 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
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
>
--
Mario Annau
Founder and CEO
Quantargo
Tel: +43 1 348 44 55-11 | mario.an...@quantargo.com
www.quantargo.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Proper way to define cbind, rbind for s4 classes in package
Hi all,
this question has already been posted on stackoverflow, however without
success, see also
http://stackoverflow.com/questions/27886535/proper-way-to-use-cbind-rbind-with-s4-classes-in-package.
I have written a package using S4 classes and would like to use the
functions rbind, cbind with these defined classes.
Since it does not seem to be possible to define rbind and cbind directly
as S4 methods (see ?cBind) I defined rbind2 and cbind2 instead:
setMethod("rbind2", signature(x="ClassA", y = "ANY"),
function(x, y) {
# Do stuff ...
})
setMethod("cbind2", signature(x="ClassA", y = "ANY"),
function(x, y) {
# Do stuff ...
})
>From ?cbind2 I learned that these functions need to be activated using
methods:::bind_activation to replace rbind and cbind from base.
I included the call in the package file R/zzz.R using the .onLoad function:
.onLoad <- function(...) {
# Bind activation of cbind(2) and rbind(2) for S4 classes
methods:::bind_activation(TRUE)
}
This works as expected. However, running R CMD check I am now getting
the following NOTE since I am using an unexported function in methods:
* checking dependencies in R code ... NOTE
Unexported object imported by a ':::' call: 'methods:::bind_activation'
See the note in ?`:::` about the use of this operator.
How can I get rid of the NOTE and what is the proper way to define the
methods cbind and rbind for S4 classes in a package?
Best,
mario
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Proper way to define cbind, rbind for s4 classes in package
>> I have written a package using S4 classes and would like to use the
>> functions rbind, cbind with these defined classes.
>>
>> Since it does not seem to be possible to define rbind and cbind directly
>> as S4 methods (see ?cBind) I defined rbind2 and cbind2 instead:
>>
>
> This needs some clarification. It certainly is possible to define
> cbind and rbind methods. The BiocGenerics package defines generics for
> those and many methods are defined by e.g. S4Vectors, IRanges, etc.
> The issue is that dispatch on "..." is singular, i.e., you can only
> specify one class that all args in "..." must share (potentially
> through inheritance). Thus, trying to combine objects from a different
> hierarchy (or non-S4 objects) will not work.
This is unfortunately an issue in my case since I would like to dispatch
on different classes.
To be more explicit than in the toy example, my actual method definition
is as follows:
setMethod("cbind2", signature(x="DataSet", y = "matrix"),
function(x, y) {
# Do stuff ...
}
setMethod("rbind2", signature(x="DataSet", y = "matrix"),
function(x, y) {
# Do stuff ...
}
The class DataSet actually wraps a pointer to a 2-dimensional HDF5
dataset. To make DataSet extensions more intuitive for the user I
thought that overloading cbind/rbind would be a good idea.
Best,
mario
> I would argue that bind_activation(TRUE) should be discouraged,
> because it replaces the native rbind and cbind with recursive variants
> that are going to cause problems, performance and otherwise. This is
> why it is hidden. Perhaps a reasonable compromise would be for the
> native cbind and rbind to check whether any arguments are S4 and if
> so, resort to recursion. Recursion does seem to be a clean way to
> implement "type promotion", i.e., to answer the question "which type
> should the result be when faced with mixed-type args?".
>
> Hopefully others have better ideas.
>
> Michael
>
>
>
>
>> setMethod("rbind2", signature(x="ClassA", y = "ANY"),
>> function(x, y) {
>> # Do stuff ...
>> })
>>
>> setMethod("cbind2", signature(x="ClassA", y = "ANY"),
>> function(x, y) {
>> # Do stuff ...
>> })
>>
>> >From ?cbind2 I learned that these functions need to be activated using
>> methods:::bind_activation to replace rbind and cbind from base.
>>
>> I included the call in the package file R/zzz.R using the .onLoad function:
>>
>> .onLoad <- function(...) {
>> # Bind activation of cbind(2) and rbind(2) for S4 classes
>> methods:::bind_activation(TRUE)
>> }
>> This works as expected. However, running R CMD check I am now getting
>> the following NOTE since I am using an unexported function in methods:
>>
>> * checking dependencies in R code ... NOTE
>> Unexported object imported by a ':::' call: 'methods:::bind_activation'
>> See the note in ?`:::` about the use of this operator.
>> How can I get rid of the NOTE and what is the proper way to define the
>> methods cbind and rbind for S4 classes in a package?
>>
>> Best,
>> mario
>>
>> __
>> 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] Proper way to define cbind, rbind for s4 classes in package
Hi Michael, I've tested your change in r67699 (using r67773) and the function now correctly dispatches to r/cbind2 within the R-session without bind_activation(TRUE). However, running unit tests using R CMD check I figured out that the same function call delegates to r/cbind.matrix (function uses S4 class as first- and matrix as second argument). Is this a bug and/or how can I get function dispatch right (to r/cbind2) for my test cases? best, mario Am 02/02/15 um 12:32 schrieb Martin Maechler: >>>>>> Michael Lawrence >>>>>> on Sun, 1 Feb 2015 19:23:06 -0800 writes: > > > I've implemented the proposed changes in > > R-devel. Minimally tested, so please try it. It should > > delegate to r/cbind2 when there is at least one S4 > > argument and S3 dispatch fails (so you'll probably want to > > add an S3 method for your class to introduce a conflict, > > otherwise it will dispatch to cbind.data.frame if one of > > the args is a data.frame). There may no longer be a need > > for cBind() and rBind(). > > > Michael > > This sounds great! Thank you very much, Michael! > :-) :-) > > ... but :-( experiments with the Matrix package (and R > devel with your change), show a remaining buglet with treating of dimnames : > >> M1 <- Matrix(m1 <- matrix(1:12, 3,4)) >> cbind(m1, MM = -1) >MM >[1,] 1 4 7 10 -1 >[2,] 2 5 8 11 -1 >[3,] 3 6 9 12 -1 >> cbind(M1, MM = -1) ## notice the "..." >3 x 5 Matrix of class "dgeMatrix" >... >[1,] 1 4 7 10 -1 >[2,] 2 5 8 11 -1 >[3,] 3 6 9 12 -1 >> rbind(R1 = 10:11, m1) > [,1] [,2] [,3] [,4] >R1 10 11 10 11 >147 10 >258 11 >369 12 >> rbind(R1 = 10:11, M1) ## --- notice the 'deparse.level' >4 x 4 Matrix of class "dgeMatrix" >[,1] [,2] [,3] [,4] >deparse.level 10 11 10 11 > 147 10 > 258 11 > 369 12 >> > > Also, it seems you are not observing the 'deparse.level' > argument at all: > Looking at the last three lines of the example in ?cbind, > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle 2 rownames > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 1) # 3 rownames > (default) > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 2) # 4 rownames > > but using a Matrix matrix 'dd', we see that (row)names > construction needs to amended: > > > (dd <- Matrix(rbind(c(0:1,0,0 > 1 x 4 sparse Matrix of class "dgCMatrix" > > [1,] . 1 . . > > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle 2 rownames > 4 x 4 sparse Matrix of class "dgCMatrix" > > deparse.level 1 2 3 4 > c 2 2 2 2 > a++ 10 10 10 10 >. 1 . . > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 1) # 3 rownames > (default) > 4 x 4 sparse Matrix of class "dgCMatrix" > > deparse.level 1 2 3 4 > c 2 2 2 2 > a++ 10 10 10 10 >. 1 . . > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 2) # 4 rownames > 4 x 4 sparse Matrix of class "dgCMatrix" > > deparse.level 1 2 3 4 > c 2 2 2 2 > a++ 10 10 10 10 >. 1 . . > > > > > > > On Mon, Jan 26, 2015 at 3:55 AM, Martin Maechler < > > maech...@lynne.stat.math.ethz.ch> wrote: > > >> >>>>> Michael Lawrence >>>>> > >> on Sat, 24 Jan 2015 06:39:37 -0800 writes: > >> > >> > On Sat, Jan 24, 2015 at 12:58 AM, Mario Annau > > >> wrote: >> Hi all, this question > >> has already been posted on >> stackoverflow, however > >> without success, see also > >> >> > >> > http://stackoverflow.com/questions/27886535/proper-way-to-use-cbind-rbind-with-s4-classes-in-package > >> . > >> >> > >> >> I have written a package using S4 classes and would > >> like >> to use the functions rbind, cbind with these > >> defined >> classes. > >> >> > >> >> Since it does not seem to be poss
Re: [Rd] Proper way to define cbind, rbind for s4 classes in package
sorry - I just got irritated by my different R-versions. The behaviour I described in the previous mail was discovered using R 3.1.2 without bind_activation(TRUE). In r67773 all calls are delegated to r/cbind.matrix and not r/cbind2. As a workaround I have now implemented an S3 method for my S4 class which correctly dispatches for both versions (3.1.2 and r67699+) - see also the commit for the h5 package on github: https://github.com/mannau/h5/commit/20daea37ade1a317458c8a1d03928f579e457f93. Any better ideas are welcome. br, mario Am 09/02/15 um 23:38 schrieb Michael Lawrence: > Are you able to create a reproducible example, somehow? > > Thanks, > Michael > > On Mon, Feb 9, 2015 at 2:28 PM, Mario Annau <mailto:mario.an...@gmail.com>> wrote: > > Hi Michael, > I've tested your change in r67699 (using r67773) and the function now > correctly dispatches to r/cbind2 within the R-session without > bind_activation(TRUE). However, running unit tests using R CMD check I > figured out that the same function call delegates to r/cbind.matrix > (function uses S4 class as first- and matrix as second argument). Is > this a bug and/or how can I get function dispatch right (to r/cbind2) > for my test cases? > best, > mario > > > Am 02/02/15 um 12:32 schrieb Martin Maechler: > >>>>>> Michael Lawrence <mailto:lawrence.mich...@gene.com>> > >>>>>> on Sun, 1 Feb 2015 19:23:06 -0800 writes: > > > > > I've implemented the proposed changes in > > > R-devel. Minimally tested, so please try it. It should > > > delegate to r/cbind2 when there is at least one S4 > > > argument and S3 dispatch fails (so you'll probably want to > > > add an S3 method for your class to introduce a conflict, > > > otherwise it will dispatch to cbind.data.frame if one of > > > the args is a data.frame). There may no longer be a need > > > for cBind() and rBind(). > > > > > Michael > > > > This sounds great! Thank you very much, Michael! > > :-) :-) > > > > ... but :-( experiments with the Matrix package (and R > > devel with your change), show a remaining buglet with treating of > dimnames : > > > >> M1 <- Matrix(m1 <- matrix(1:12, 3,4)) > >> cbind(m1, MM = -1) > >MM > >[1,] 1 4 7 10 -1 > >[2,] 2 5 8 11 -1 > >[3,] 3 6 9 12 -1 > >> cbind(M1, MM = -1) ## notice the "..." > >3 x 5 Matrix of class "dgeMatrix" > >... > >[1,] 1 4 7 10 -1 > >[2,] 2 5 8 11 -1 > >[3,] 3 6 9 12 -1 > >> rbind(R1 = 10:11, m1) > > [,1] [,2] [,3] [,4] > >R1 10 11 10 11 > >147 10 > >258 11 > >369 12 > >> rbind(R1 = 10:11, M1) ## --- notice the 'deparse.level' > >4 x 4 Matrix of class "dgeMatrix" > >[,1] [,2] [,3] [,4] > >deparse.level 10 11 10 11 > > 147 10 > > 258 11 > > 369 12 > >> > > > > Also, it seems you are not observing the 'deparse.level' > > argument at all: > > Looking at the last three lines of the example in ?cbind, > > > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle > 2 rownames > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 1) # 3 > rownames (default) > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 2) # 4 rownames > > > > but using a Matrix matrix 'dd', we see that (row)names > > construction needs to amended: > > > > > (dd <- Matrix(rbind(c(0:1,0,0 > > 1 x 4 sparse Matrix of class "dgCMatrix" > > > > [1,] . 1 . . > > > > > rbind(1:4, c = 2, "a++" = 10, dd, deparse.level = 0) # middle > 2 rownames > > 4 x 4 sparse Matrix of class "dgCMatrix" > > > > deparse.level 1 2 3 4 > > c 2 2 2 2 > > a++ 10 10 10 10 > >. 1 . . > > > rbind(1:4, c = 2, &q
Re: [Rd] Proper way to define cbind, rbind for s4 classes in package
Thank you very much for your effort! I can confirm that *bind S4 method
dispatching now works for my use cases as expected (tested using r67856).
Cheers,
mario
Am 20/02/15 um 12:40 schrieb Martin Maechler:
>>>>>> Mario Annau
>>>>>> on Wed, 11 Feb 2015 20:18:53 +0100 writes:
>
> > sorry - I just got irritated by my different R-versions.
> > The behaviour I described in the previous mail was discovered using R
> > 3.1.2 without bind_activation(TRUE). In r67773 all calls are delegated
> > to r/cbind.matrix and not r/cbind2.
> > As a workaround I have now implemented an S3 method for my S4 class
> > which correctly dispatches for both versions (3.1.2 and r67699+) - see
> > also the commit for the h5 package on github:
> >
> https://github.com/mannau/h5/commit/20daea37ade1a317458c8a1d03928f579e457f93.
> > Any better ideas are welcome.
>
> and in the mean time there have been a few off-list e-mails,
>
> {"No, using an S3 method was definitely not the idea of
> Michael's changes!" .. }
>
> and many hours of work by me.
> R-devel svn rev 67852 and later now has cbind() / rbind()
> working in a better way, dipatching to either cbind2(), rbind2()
> S4 methods for "your" classes, or to S4 rbind() or cbind()
> methods for your classes.
>
> Notably the new code now should create column / rownames
> analogously to base::cbind / rbind, influenced by deparse.level
> in the case of non-matrix arguments.
>
> Small changes in some outputs may occur, notably as the hidden
> methods:::cbind and rbind functions (think of "S4 default method")
> now do obey deparse.level and also otherwise should create row
> and column names in the same way as base::[cr]bind().
>
> Martin Maechler
> ETH Zurich and R Core Team
>
> > br,
> > mario
>
>
> > Am 09/02/15 um 23:38 schrieb Michael Lawrence:
> >> Are you able to create a reproducible example, somehow?
> >>
> >> Thanks,
> >> Michael
> >>
> >> On Mon, Feb 9, 2015 at 2:28 PM, Mario Annau >> <mailto:mario.an...@gmail.com>> wrote:
> >>
> >> Hi Michael,
> >> I've tested your change in r67699 (using r67773) and the function now
> >> correctly dispatches to r/cbind2 within the R-session without
> >> bind_activation(TRUE). However, running unit tests using R CMD check I
> >> figured out that the same function call delegates to r/cbind.matrix
> >> (function uses S4 class as first- and matrix as second argument). Is
> >> this a bug and/or how can I get function dispatch right (to r/cbind2)
> >> for my test cases?
> >> best,
> >> mario
> >>
> >>
> >> Am 02/02/15 um 12:32 schrieb Martin Maechler:
> >> >>>>>> Michael Lawrence >> <mailto:lawrence.mich...@gene.com>>
> >> >>>>>> on Sun, 1 Feb 2015 19:23:06 -0800 writes:
> >> >
> >> > > I've implemented the proposed changes in
> >> > > R-devel. Minimally tested, so please try it. It should
> >> > > delegate to r/cbind2 when there is at least one S4
> >> > > argument and S3 dispatch fails (so you'll probably want to
> >> > > add an S3 method for your class to introduce a conflict,
> >> > > otherwise it will dispatch to cbind.data.frame if one of
> >> > > the args is a data.frame). There may no longer be a need
> >> > > for cBind() and rBind().
> >> >
> >> > > Michael
> >> >
> >> > This sounds great! Thank you very much, Michael!
> >> > :-) :-)
> >> >
> >> > ... but :-( experiments with the Matrix package (and R
> >> > devel with your change), show a remaining buglet with treating of
> >> dimnames :
> >> >
> >> >> M1 <- Matrix(m1 <- matrix(1:12, 3,4))
> >> >> cbind(m1, MM = -1)
> >> >MM
> >> >[1,] 1 4 7 10 -1
> >> >[2,] 2 5 8 11 -1
> >> >[3,] 3 6 9 12 -1
> >> >> cbind(M1, MM = -1) ## notice the "..."
> >> >3 x 5 Matrix of class "dgeMatrix"
> >> >...
> >> >[1,]
