Re: [Rd] R CMD check and missing imports from base packages
> Gábor Csárdi > on Wed, 29 Apr 2015 23:07:09 -0400 writes: > On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert wrote: >> >> As I recall, several packages mask the simulate generic in stats, if you >> are looking for examples. >> > FWIW, here is a list of base* functions masked** by CRAN packages: > https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md > Look at the long table in the end. simulate indeed comes up 16 times. (But > read ** below.) > * This only includes functions in base packages that are attached by > default. > ** The CRAN function names were taken from the manual page aliases, so a > couple of them are not really function names, and some of them are probably > not masking anything, but defining an S3 generic. This was a lot simpler > than going over the namespaces of all CRAN packages. > It seems that several base functions are masked, by several packages. I > would need to get a better CRAN function list, though. Thank you Gabor. As Martin Morgan observed, many of these will be methods, S3 and S3 and there is often no conflict and no masking at all for all these, so I am claiming that your "statistics" are quite a bit biased, and probably most of the more common names are proper methods. There is another issue, I've wanted to raise, exemplified by my Rmpfr package [interface to the MPFR C library for high-accuracy floating point computations]: As it defines "mpfr"-ified versions of standard R functions many of which are *not* generic, it must mask them. E.g, currently, the following "are masked" messages (when attaching Rmpfr) are unavoidable Attaching package: ‘Rmpfr’ The following objects are masked from ‘package:stats’: dbinom, dnorm, dpois, pnorm The following objects are masked from ‘package:base’: pmax, pmin (Currently, there are also 'cbind' and 'rbind' being masked in order to work with mpfr-number matrices ... but that should in principle be avoidable) I think these "... are masked" messages are still appropriate: After all, pnorm() will really be taken from Rmpfr instead of from stats, and the user should know that she is trusting the author of Rmpfr (me) to do the right thing, when she calls pnorm(), namely to call the equivalent stats::pnorm() for standard numbers, and to call the MPFR-library code for mpfr-numbers. - - - - - - - - - - - - - - - - - - - - - - - - Now the above may have almost nothing to do with the original subject. If I have understood your main point correctly, you are suggesting that 'R CMD check' should start putting out a NOTE when package code calls a function from one of a set of "standard packages" (*) and the package author failed to use an importFrom(, ) in his/her NAMESPACE. I agree that this would be useful. Actually, I think we have something like this in place already... but maybe not strictly enough (?) (*) IIUC, you suggested to use "standard packages" := packages which are attached by default in R, apart from package 'base' because that does come immediately after the imports anyway (and because you cannot explicity import from base). Martin Maechler ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dimnames returned by function apply
> Fischer, Bernd
> on Wed, 29 Apr 2015 20:22:44 +0200 writes:
> Dear all,
> I noticed that the dimnames returned by apply are different in the new
release.
> In the following example. The returned row-names are c(“S”,”T”), but
shouldn’t they be c(“X”,”Y”) as in the old release?
Not quite : They were c("X.S", "Y.T")
Still
.
..
...
.
..
---> Tada !!
Congratulations on your finding the first "bad" bug in R 3.2.0 !
"bad": a true regression, i.e., a bug not present in earlier versions of R.
I'm almost sure it is my fault, and I'm going to look into fixing it!
For the curious ones: It was introduced with the following
new feature (which implied fixing apply()'s treatment of named dimnames):
• apply(m, 2, identity) is now the same as the matrix m when it has
_named_ row names.
> Best,
> Bernd
Thank you, Bernd, for the report!
Martin Maechler,
ETH Zurich
>> X = array(1:8, dim=c(4,2))
>> dimnames(X) = list(c("A","B","C","D"),c("S","T"))
>> apply(X, 1, function(x) { c(X=x[1]*5,Y=x[2]*5) } )
> A B C D
> S 5 10 15 20
> T 25 30 35 40
>> sessionInfo()
> R version 3.2.0 (2015-04-16)
[...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] --interactive and -f/-e
On 4/29/15 3:20 AM, Martin Maechler wrote: Mick Jordan on Tue, 28 Apr 2015 18:11:54 -0700 writes: So, in principle it should not seem hard to make --interactive work for '-e' and '-f' as well, but I don't see quickly how. Just changing the line in unix/system.c you've mentioned above is clearly not enough. Martin Maechler ETH Zurich Thanks for the detailed assessment. When implementing a feature (I'm on the FastR project) I usually go by what the manual says, then check it against GnuR, and then if they don't match, read the source code. I'd be just as happy for the manual to be fixed rather than the code. Mick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dimnames returned by function apply
> Martin Maechler
> on Thu, 30 Apr 2015 18:23:58 +0200 writes:
> Fischer, Bernd
> on Wed, 29 Apr 2015 20:22:44 +0200 writes:
>> Dear all, I noticed that the dimnames returned by apply
>> are different in the new release.
>> In the following example. The returned row-names are
>> c(“S”,”T”), but shouldn’t they be c(“X”,”Y”) as in the
>> old release?
> Not quite : They were c("X.S", "Y.T")
> Still
[]
> Congratulations on your finding the first "bad" bug in R
> 3.2.0 ! "bad": a true regression, i.e., a bug not present
> in earlier versions of R.
> I'm almost sure it is my fault, and I'm going to look into
> fixing it!
Fix committed to R-devel and R-patched, svn revision
68282 and 68283, respectively.
So if you get R 3.2.0 patched in a day or so, you'll get a
version of apply() which behaves as previously in this case.
Martin Maechler
> For the curious ones: It was introduced with the following
> new feature (which implied fixing apply()'s treatment of
> named dimnames):
> • apply(m, 2, identity) is now the same as the matrix
> m when it has _named_ row names.
>> Best, Bernd
> Thank you, Bernd, for the report!
> Martin Maechler, ETH Zurich
>>> X = array(1:8, dim=c(4,2)) dimnames(X) =
>>> list(c("A","B","C","D"),c("S","T")) apply(X, 1,
>>> function(x) { c(X=x[1]*5,Y=x[2]*5) } )
>> A B C D S 5 10 15 20 T 25 30 35 40
>>> sessionInfo()
>> R version 3.2.0 (2015-04-16)
> [...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
