Re: [Rd] Extending suggestion for stopifnot
On Wed, Aug 21, 2013 at 3:30 AM, ivo welch wrote:
> thx, deepayan: how is stopifnot better than
> if (!all(...)) stop()
But I am not claiming that it is!
If you think it is not useful, then don't use stopifnot(), use stop()
instead, and tell your students to do so as well.
> given that we have stopifnot() and I have seen it used often, I think
> my two suggestions would make it better.
Maybe it will (in some specific use cases). But looking at your
suggestion purely from the point of view of "is it worth incorporating
into base R?", I don't see enough justification. The disadvantage is
that it will complicate a simple function. The supposed advantage is
only an advantage when you use stopifnot() in a way that was not
intended, whereas there is already an alternative that does almost
exactly what you want (at least you haven't yet explained why you are
not happy with stop()). Interpolated strings may be cool, but I don't
see a big readability advantage of
if (!is.matrix(m)) stop("m is not a matrix, but a {{class(m)}}")
over
if (!is.matrix(m)) stop("m is not a matrix, but a ", class(m))
Note that I'm not saying that stop() is perfect or anything, or that
there is no need for alternatives. Just that I'm not convinced that
the base R changes you want are justified.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
Hi all, Thanks for getting back to me. We would like to move over to v3.0.0 on our cluster so that we can build matrices larger than 46300*46300 (limit in R <3.0.0) but so far we can't get things to work with R v3.0.0 and higher. I am trying to trouble shoot at the moment and I am now thinking that the problem is actually with the diag function that has been rewritten in version 3.0.0. The problem is definitely with the diag function and it does not occur on smaller matrices (2*2) and I think it maybe a bug. This illustrates the problem: This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 (but I do see the same for 3.0.0). This does not occur when I run it with R 2.15.2. mat1=matrix(rexp(2^2), 2) mat1[1:10,1:10] [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [1,] 0.1829090 0.39867734 0.80499126 4.1746377 0.20717066 1.1477365 0.469843567 2.57767543 0.17449595 0.01949358 [2,] 0.5731522 0.15835939 0.29165029 0.6781249 0.64553728 2.4438404 2.140374938 0.40091195 0.51201369 0.98904490 [3,] 0.3250310 0.09934147 0.79962549 0.4933385 0.30473422 0.4556765 0.002640034 0.90606861 2.58772944 0.89884208 [4,] 1.4195017 0.16082660 0.01377838 0.2115803 1.43992672 0.3883675 0.040903805 0.51011305 0.41998024 0.44209926 [5,] 0.8328441 1.10335604 0.11875332 0.1600287 0.1724 0.3388678 3.206179119 0.52170966 1.03084845 0.05843232 [6,] 1.3179906 0.76376188 1.24231798 0.9424030 0.04440514 1.0237664 2.547528816 1.35629450 0.87983354 0.25236343 [7,] 0.6990544 1.17003075 0.66063936 0.8632534 0.28965611 0.6718020 1.137348735 0.08371053 0.23144290 0.18915132 [8,] 0.9908026 1.20471979 0.08816010 0.2652131 0.03537790 0.3295816 0.144371435 3.03299285 0.09728111 0.39890260 [9,] 0.9557305 0.29196500 0.43955758 0.7332643 2.03457020 0.5858431 2.437192399 0.34689557 0.02039205 0.54898488 [10,] 3.7220703 0.13572389 0.1673 0.5683698 1.79209016 1.3495723 0.571159401 0.63375850 0.63221987 1.32840290 > mat1[19990:2,19990:2] [,1] [,2] [,3] [,4] [,5][,6] [,7] [,8] [,9] [,10] [,11] [1,] 1.7910910 0.5719982 0.38689588 1.2157545685 0.8530179 1.464105574 0.5986705 1.1623393 0.55244563 0.1770146 0.4326310 [2,] 0.2862914 1.5267870 0.98214645 0.0004617244 0.6395319 0.075217874 0.6725620 0.2403549 0.08436217 0.1435451 0.7487862 [3,] 2.0492301 0.7216115 0.16951284 0.2726676762 2.1893806 1.202518385 0.9897710 1.4813026 2.42517705 0.3398811 0.7285074 [4,] 0.6538994 0.2437594 2.08848881 0.3917212249 0.4441824 0.433749415 1.3022991 1.3695241 0.07057642 0.4296937 2.9307556 [5,] 2.3688094 2.3970048 0.03545232 0.5986997508 0.8914097 0.497023176 0.4210650 1.5337767 0.01141066 1.1562830 1.0572076 [6,] 2.0626934 0.6186995 0.99197835 1.4794321654 0.1549314 1.296227000 0.2790942 0.9327613 0.84131377 0.8782590 0.3279970 [7,] 1.2423823 0.2385994 0.11390071 2.0745023842 1.9152523 0.754186281 1.5474078 2.5899490 5.19298969 1.4680934 1.0537164 [8,] 1.3657070 1.9502828 1.07681438 0.9339731540 1.7532474 0.186193421 1.8699504 1.9187339 5.13248671 0.4621520 0.4753582 [9,] 0.6512000 0.5104660 0.17820166 0.3965162944 0.0919119 0.187808660 0.7391137 0.1574844 0.65985494 0.4066742 0.8072494 [10,] 0.7435028 1.1395666 2.46096009 0.7060164691 1.7965986 0.008278685 0.4642319 0.1582297 1.71676326 0.3662139 0.7864957 [11,] 0.3537041 0.6622001 2.01642141 1.8225423060 0.3295436 1.260737179 0.8430396 0.5132811 0.30547431 1.6088725 0.4001791 diag(mat1)=0 mat1[1:10,1:10] [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [1,] 0.000 0.39867734 0.80499126 4.1746377 0.20717066 1.1477365 0.469843567 2.57767543 0.17449595 0.01949358 [2,] 0.5731522 0. 0.29165029 0.6781249 0.64553728 2.4438404 2.140374938 0.40091195 0.51201369 0.98904490 [3,] 0.3250310 0.09934147 0. 0.4933385 0.30473422 0.4556765 0.002640034 0.90606861 2.58772944 0.89884208 [4,] 1.4195017 0.16082660 0.01377838 0.000 1.43992672 0.3883675 0.040903805 0.51011305 0.41998024 0.44209926 [5,] 0.8328441 1.10335604 0.11875332 0.1600287 0. 0.3388678 3.206179119 0.52170966 1.03084845 0.05843232 [6,] 1.3179906 0.76376188 1.24231798 0.9424030 0.04440514 0.000 2.547528816 1.35629450 0.87983354 0.25236343 [7,] 0.6990544 1.17003075 0.66063936 0.8632534 0.28965611 0.6718020 0.0 0.08371053 0.23144290 0.18915132 [8,] 0.9908026 1.20471979 0.08816010 0.2652131 0.03537790 0.3295816 0.144371435 0. 0.09728111 0.39890260 [9,] 0.9557305 0.29196500 0.43955758 0.7332643 2.03457020 0.5858431 2.437192399 0.34689557 0. 0.54898488 [10,] 3.7220703 0.13572389 0.1673 0.5683698 1.79209016 1.3495723 0.571159401 0.63375850 0.63221987 0. mat1[19990:2,19990:2] [,1] [,2] [,3] [,4] [,5][,6] [,7] [,8] [,9] [,10] [,11] [1,] 0.000 0.5719982 0.38689588 1.2157545685 0
Re: [Rd] Problem with R >3.0.0
Hi Peter, But this is still an issue bellow the old R limit. I just tried the same with a matrix of 3*3 and I see the same problem. This never used to happen with R v2.15.2 and we could regularly build similarity matrices of 45000*45000. This behavior of filling up the bottom of the matrix with 0's after calling diag is only happening with v3.0.0 and v3.0.1. As I said I don't think that this is an issue with WGCNA but it has implications for WGCNA because it limits the number of genes to be included in network construction. Thanks Sam On 8/20/13 10:53 AM, "Peter Langfelder" wrote: >Hi Samuel, > >WGCNA currently does not support calculations with matrices larger >than the old R limit, and it will take some time to update it to >support the large matrices. Furthermore, WGCNA relies on other >functions (most notably hclust) that would have to be updated as well >to support long vectors. > >In the meantime I suggest using the "blockwise" functions to handle >large data sets, or, if possible, reducing the number of genes to less >than the old limit of 46340 or so. > >Sorry I can't be of more help. > >Best, > >Peter > >On Tue, Aug 20, 2013 at 10:42 AM, Shelton, Samuel > wrote: >> Hi all, >> >> Thanks for getting back to me. We would like to move over to v3.0.0 on >>our >> cluster so that we can build matrices larger than 46300*46300 (limit in >>R >> <3.0.0) >> but so far we can't get things to work with R v3.0.0 and higher. I am >> trying to trouble shoot at the moment and I am now thinking that the >> problem is actually with the diag function that has been rewritten in >> version 3.0.0. >> >> >> The problem is definitely with the diag function and it does not occur >>on >> smaller matrices (2*2) and I think it maybe a bug. >> This illustrates the problem: >> >> This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 >>(but >> I do see the same for 3.0.0). This does not occur when I run it with R >> 2.15.2. >> >> >> mat1=matrix(rexp(2^2), 2) >> >> mat1[1:10,1:10] >>[,1] [,2] [,3] [,4] [,5] [,6] >> [,7] [,8] [,9] [,10] >> [1,] 0.1829090 0.39867734 0.80499126 4.1746377 0.20717066 1.1477365 >> 0.469843567 2.57767543 0.17449595 0.01949358 >> [2,] 0.5731522 0.15835939 0.29165029 0.6781249 0.64553728 2.4438404 >> 2.140374938 0.40091195 0.51201369 0.98904490 >> [3,] 0.3250310 0.09934147 0.79962549 0.4933385 0.30473422 0.4556765 >> 0.002640034 0.90606861 2.58772944 0.89884208 >> [4,] 1.4195017 0.16082660 0.01377838 0.2115803 1.43992672 0.3883675 >> 0.040903805 0.51011305 0.41998024 0.44209926 >> [5,] 0.8328441 1.10335604 0.11875332 0.1600287 0.1724 0.3388678 >> 3.206179119 0.52170966 1.03084845 0.05843232 >> [6,] 1.3179906 0.76376188 1.24231798 0.9424030 0.04440514 1.0237664 >> 2.547528816 1.35629450 0.87983354 0.25236343 >> [7,] 0.6990544 1.17003075 0.66063936 0.8632534 0.28965611 0.6718020 >> 1.137348735 0.08371053 0.23144290 0.18915132 >> [8,] 0.9908026 1.20471979 0.08816010 0.2652131 0.03537790 0.3295816 >> 0.144371435 3.03299285 0.09728111 0.39890260 >> [9,] 0.9557305 0.29196500 0.43955758 0.7332643 2.03457020 0.5858431 >> 2.437192399 0.34689557 0.02039205 0.54898488 >> [10,] 3.7220703 0.13572389 0.1673 0.5683698 1.79209016 1.3495723 >> 0.571159401 0.63375850 0.63221987 1.32840290 >>> mat1[19990:2,19990:2] >>[,1] [,2] [,3] [,4] [,5][,6] >> [,7] [,8] [,9] [,10] [,11] >> [1,] 1.7910910 0.5719982 0.38689588 1.2157545685 0.8530179 1.464105574 >> 0.5986705 1.1623393 0.55244563 0.1770146 0.4326310 >> [2,] 0.2862914 1.5267870 0.98214645 0.0004617244 0.6395319 0.075217874 >> 0.6725620 0.2403549 0.08436217 0.1435451 0.7487862 >> [3,] 2.0492301 0.7216115 0.16951284 0.2726676762 2.1893806 1.202518385 >> 0.9897710 1.4813026 2.42517705 0.3398811 0.7285074 >> [4,] 0.6538994 0.2437594 2.08848881 0.3917212249 0.4441824 0.433749415 >> 1.3022991 1.3695241 0.07057642 0.4296937 2.9307556 >> [5,] 2.3688094 2.3970048 0.03545232 0.5986997508 0.8914097 0.497023176 >> 0.4210650 1.5337767 0.01141066 1.1562830 1.0572076 >> [6,] 2.0626934 0.6186995 0.99197835 1.4794321654 0.1549314 1.296227000 >> 0.2790942 0.9327613 0.84131377 0.8782590 0.3279970 >> [7,] 1.2423823 0.2385994 0.11390071 2.0745023842 1.9152523 0.754186281 >> 1.5474078 2.5899490 5.19298969 1.4680934 1.0537164 >> [8,] 1.3657070 1.9502828 1.07681438 0.9339731540 1.7532474 0.186193421 >> 1.8699504 1.9187339 5.13248671 0.4621520 0.4753582 >> [9,] 0.6512000 0.5104660 0.17820166 0.3965162944 0.0919119 0.187808660 >> 0.7391137 0.1574844 0.65985494 0.4066742 0.8072494 >> [10,] 0.7435028 1.1395666 2.46096009 0.7060164691 1.7965986 0.008278685 >> 0.4642319 0.1582297 1.71676326 0.3662139 0.7864957 >> [11,] 0.3537041 0.6622001 2.01642141 1.8225423060 0.3295436 1.260737179 >> 0.8430396 0.5132811 0.30547431 1.6088725 0.4001791 >> >> diag(mat1)=0 >> >> mat1[1:10,1:10] >>[,1]
Re: [Rd] Problem with R >3.0.0
On Aug 20, 2013, at 19:42 , Shelton, Samuel wrote: > Hi all, > > Thanks for getting back to me. We would like to move over to v3.0.0 on our > cluster so that we can build matrices larger than 46300*46300 (limit in R > <3.0.0) > but so far we can't get things to work with R v3.0.0 and higher. I am > trying to trouble shoot at the moment and I am now thinking that the > problem is actually with the diag function that has been rewritten in > version 3.0.0. > > > The problem is definitely with the diag function and it does not occur on > smaller matrices (2*2) and I think it maybe a bug. > This illustrates the problem: > > This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 (but > I do see the same for 3.0.0). This does not occur when I run it with R > 2.15.2. > Thanks. I can condense this to > M <- matrix(1,23170,23170) ; diag(M) <- 0 ; range(colSums(M)) [1] 23169 23169 > M <- matrix(1,23171,23171) ; diag(M) <- 0 ; range(colSums(M)) [1] 0 23170 and the fact that 2^14.5 is 23170.48 is not likely to be a coincidence... It is only happening with some of my builds, though. In particular, my MacPorts build of 3.0.1 does not have the problem on Snow Leopard, nor does the CRAN build of 3.0.0, still on Snow Leopard. It takes forever to check on a 4GB machine -- 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] Extending suggestion for stopifnot
first, I think it would be more useful if it had an optional character string, so users could write stopifnot( is.matrix(m), "m is not a matrix" ) stop() allows for arbitrary strings __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
On 21/08/2013 13:45, peter dalgaard wrote: On Aug 20, 2013, at 19:42 , Shelton, Samuel wrote: Hi all, Thanks for getting back to me. We would like to move over to v3.0.0 on our cluster so that we can build matrices larger than 46300*46300 (limit in R <3.0.0) but so far we can't get things to work with R v3.0.0 and higher. I am trying to trouble shoot at the moment and I am now thinking that the problem is actually with the diag function that has been rewritten in version 3.0.0. The problem is definitely with the diag function and it does not occur on smaller matrices (2*2) and I think it maybe a bug. This illustrates the problem: This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 (but I do see the same for 3.0.0). This does not occur when I run it with R 2.15.2. Thanks. I can condense this to M <- matrix(1,23170,23170) ; diag(M) <- 0 ; range(colSums(M)) [1] 23169 23169 M <- matrix(1,23171,23171) ; diag(M) <- 0 ; range(colSums(M)) [1] 0 23170 A much faster check is to look at M[1:3, 1:3] and the fact that 2^14.5 is 23170.48 is not likely to be a coincidence... It is only happening with some of my builds, though. In particular, my MacPorts build of 3.0.1 does not have the problem on Snow Leopard, nor does the CRAN build of 3.0.0, still on Snow Leopard. It takes forever to check on a 4GB machine Note that does not use the diag() function but diag<-(), which is essentially unchanged since 2.15.x (the error detection was moved above an expensive calculation). It works correctly on x86_64 Linux and Solaris. I suspect a platform-specific issue in x[cbind(i, i)] <- value -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
On Aug 21, 2013, at 16:00 , Prof Brian Ripley wrote: > On 21/08/2013 13:45, peter dalgaard wrote: >> >> On Aug 20, 2013, at 19:42 , Shelton, Samuel wrote: >> >>> Hi all, >>> >>> Thanks for getting back to me. We would like to move over to v3.0.0 on our >>> cluster so that we can build matrices larger than 46300*46300 (limit in R >>> <3.0.0) >>> but so far we can't get things to work with R v3.0.0 and higher. I am >>> trying to trouble shoot at the moment and I am now thinking that the >>> problem is actually with the diag function that has been rewritten in >>> version 3.0.0. >>> >>> >>> The problem is definitely with the diag function and it does not occur on >>> smaller matrices (2*2) and I think it maybe a bug. >>> This illustrates the problem: >>> >>> This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 (but >>> I do see the same for 3.0.0). This does not occur when I run it with R >>> 2.15.2. >>> >> >> >> Thanks. I can condense this to >> >>> M <- matrix(1,23170,23170) ; diag(M) <- 0 ; range(colSums(M)) >> [1] 23169 23169 >>> M <- matrix(1,23171,23171) ; diag(M) <- 0 ; range(colSums(M)) >> [1] 0 23170 > > A much faster check is to look at M[1:3, 1:3] That doesn't show the issue for larger values of 23171, though. > >> and the fact that 2^14.5 is 23170.48 is not likely to be a coincidence... >> >> It is only happening with some of my builds, though. In particular, my >> MacPorts build of 3.0.1 does not have the problem on Snow Leopard, nor does >> the CRAN build of 3.0.0, still on Snow Leopard. It takes forever to check on >> a 4GB machine > > Note that does not use the diag() function but diag<-(), which is essentially > unchanged since 2.15.x (the error detection was moved above an expensive > calculation). > > It works correctly on x86_64 Linux and Solaris. I suspect a > platform-specific issue in > >x[cbind(i, i)] <- value Likely. I'm not seeing it on the iMac/SnowLeopard, only on the MacPro/Lion. I'm upgrading the MacPorts R on the MacPro now to see whether it has issues too, but of course that reinstalls everything but the kitchen sink... -- 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] Problem with R >3.0.0
On Aug 21, 2013, at 16:39 , peter dalgaard wrote: > > Likely. I'm not seeing it on the iMac/SnowLeopard, only on the MacPro/Lion. > I'm upgrading the MacPorts R on the MacPro now to see whether it has issues > too, but of course that reinstalls everything but the kitchen sink... Whoops. I don't know what I was thinking there. I seem to have suppressed all memory of the hard disk replacement on the iMac, and its aftereffects. Both machines are in fact running Lion! That makes things even odder... -- 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] Problem with R >3.0.0
In case this is helpful, I don't see this issue on my Mac Pro with OSX version 10.7.5. Details below. > M <- matrix(1,23171,23171) ; diag(M) <- 0 ; range(colSums(M)) [1] 23170 23170 > sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-apple-darwin10.8.0 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base > .Platform $OS.type [1] "unix" $file.sep [1] "/" $dynlib.ext [1] ".so" $GUI [1] "X11" $endian [1] "little" $pkgType [1] "mac.binary" $path.sep [1] ":" $r_arch [1] "" > R.Version() $platform [1] "x86_64-apple-darwin10.8.0" $arch [1] "x86_64" $os [1] "darwin10.8.0" $system [1] "x86_64, darwin10.8.0" $status [1] "" $major [1] "3" $minor [1] "0.1" $year [1] "2013" $month [1] "05" $day [1] "16" $`svn rev` [1] "62743" $language [1] "R" $version.string [1] "R version 3.0.1 (2013-05-16)" $nickname [1] "Good Sport" On Wed, Aug 21, 2013 at 12:51 PM, peter dalgaard wrote: > > On Aug 21, 2013, at 16:39 , peter dalgaard wrote: > >> >> Likely. I'm not seeing it on the iMac/SnowLeopard, only on the MacPro/Lion. >> I'm upgrading the MacPorts R on the MacPro now to see whether it has issues >> too, but of course that reinstalls everything but the kitchen sink... > > Whoops. I don't know what I was thinking there. I seem to have suppressed all > memory of the hard disk replacement on the iMac, and its aftereffects. Both > machines are in fact running Lion! That makes things even odder... > > > -- > 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
On 21/08/2013 15:00, Prof Brian Ripley wrote: On 21/08/2013 13:45, peter dalgaard wrote: On Aug 20, 2013, at 19:42 , Shelton, Samuel wrote: Hi all, Thanks for getting back to me. We would like to move over to v3.0.0 on our cluster so that we can build matrices larger than 46300*46300 (limit in R <3.0.0) but so far we can't get things to work with R v3.0.0 and higher. I am trying to trouble shoot at the moment and I am now thinking that the problem is actually with the diag function that has been rewritten in version 3.0.0. The problem is definitely with the diag function and it does not occur on smaller matrices (2*2) and I think it maybe a bug. This illustrates the problem: This was done on an iMac i5 with OSX 10.8.5 16GB Ram and with R 3.0.1 (but I do see the same for 3.0.0). This does not occur when I run it with R 2.15.2. Thanks. I can condense this to M <- matrix(1,23170,23170) ; diag(M) <- 0 ; range(colSums(M)) [1] 23169 23169 M <- matrix(1,23171,23171) ; diag(M) <- 0 ; range(colSums(M)) [1] 0 23170 A much faster check is to look at M[1:3, 1:3] and the fact that 2^14.5 is 23170.48 is not likely to be a coincidence... It is only happening with some of my builds, though. In particular, my MacPorts build of 3.0.1 does not have the problem on Snow Leopard, nor does the CRAN build of 3.0.0, still on Snow Leopard. It takes forever to check on a 4GB machine Note that does not use the diag() function but diag<-(), which is essentially unchanged since 2.15.x (the error detection was moved above an expensive calculation). It works correctly on x86_64 Linux and Solaris. I suspect a platform-specific issue in x[cbind(i, i)] <- value I have tracked this down to an issue with memcpy on vectors of 2^32 or more bytes. That very likely explains why it appears in some OS X builds and not others (depending on the compiler and libc used), and not on other platforms. I am looking into a workaround that only uses smaller sections for memcpy without losing all the performance gains. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
thx to everyone for having listened to my suggestion and reasoning through it, even though it won't fly. maybe, as a last word, let me add a short appeal that is more generic: R is a tough programming language for beginners. anything that allows a user to request additional error-checking, and/or that makes it easier and encourages users to write programs that check inputs would probably get widely used and be welcome by many. R libraries are useful, but it's not the same as having these sort of features in the base language. regards, /iaw Ivo Welch (ivo.we...@gmail.com) http://www.ivo-welch.info/ J. Fred Weston Professor of Finance Anderson School at UCLA, C519 Director, UCLA Anderson Fink Center for Finance and Investments Free Finance Textbook, http://book.ivo-welch.info/ Editor, Critical Finance Review, http://www.critical-finance-review.org/ On Wed, Aug 21, 2013 at 6:56 AM, Geoff Jentry wrote: >> first, I think it would be more useful if it had an optional character >> string, so users could write >> stopifnot( is.matrix(m), "m is not a matrix" ) > > > stop() allows for arbitrary strings __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] legitimate use of :::
Hi, So now R CMD check starts to warn against :::, but I believe sometimes it is legitimate to use it when developing R packages. For example, I have some utils functions that are not exported but I want to share them across the packages that I maintain. I do not need to coordinate with other authors about these internal functions since I'm the only author and I know clearly what I'm doing, and I want to avoid copying and pasting the code across packages just to avoid the NOTE in R CMD check. What should I do in this case? Regards, Yihui -- Yihui Xie Web: http://yihui.name Department of Statistics, Iowa State University 102 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
