[R-pkg-devel] Strange timings reported from R CMD check
Dear all,
When we prepared a release candidate form package mboost (see
https://github.com/hofnerb/mboost/tree/master/pkg/mboostPatch for the
code) we we found a strange issue regarding the timings. When running
R CMD check --as-cran
on the package mboost we found the following timings:
Linux (x86_64-pc-linux-gnu):
Examples with CPU or elapsed time > 5s
user system elapsed
mboost 14.791 9.274 11.75
If I run on the Linux machine in R --vanilla the following command:
system.time({ library("mboost"); example("mboost", ask = FALSE) })
i.e., load the package AND run the example I get a timing of
user system elapsed
2.840 1.374 3.051
To check the timings, I also used a Mac.
MacOS (x86_64-apple-darwin10.8.0):
--
Examples with CPU or elapsed time > 5s
user system elapsed
mboost 2.629 2.644 2.9
The MacOS note is very strange as it complains that time > 5s which it
isn't. The Linux note is also strange as I cannot reproduce these timing
at all if I run the code separately.
We have now shortened the example to comply with the CRAN policies (in
any case) but wonder where these very different timings come from.
Is it a bug in R CMD check? Or does anyone know what the reason for
these strange timings is?
Best,
Benjamin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Redefinition of generic for plot function breaks plot.formula
Dear all,
CRAN policies do not allow that single methods (for generic functions)
which are defined in base or recommended packages are replaced. They
advice package authors to replace the standard generic and use a
xxx.default method which then calls the original standard generic.
Using the following code
## overwrite standard generic
plot <- function(x, y, ...)
UseMethod("plot")
## per default fall back to standard generic
plot.default <- function(x, y, ...)
graphics::plot(x, y, ...)
## now specify modified plot function for data frames
plot.data.frame <- function(x, variables = names(x), ...)
essentially works for all tested plot.xxx functions. Yet, it breaks
plot.formula. How can I proceed to overwrite plot.data.frame without
breaking plot.formula. Any help is greatly appreciated.
For a detailed description of the problem with syntax highlighting and
code to reproduce the problem please see:
http://stackoverflow.com/questions/32246361/redefinition-of-generic-for-plot-function-breaks-plot-formula
Best,
Benjamin
--
**
Dr. rer. nat. Benjamin Hofner
Institut für Medizininformatik, Biometrie und Epidemiologie
Friedrich-Alexander-Universität Erlangen-Nürnberg
Waldstr. 6 - 91054 Erlangen - Germany
Tel: +49-9131-85-22707
Fax: +49-9131-85-25740
Büro:
Raum 3.036
Universitätsstraße 22
(Eingang linke Seite des Gebäudes; Wegweiser IMBE)
benjamin.hof...@fau.de
http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html
http://www.benjaminhofner.de
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Redefinition of generic for plot function breaks plot.formula
Dear Gavin,
unfortunately, I cannot overwrite plot.data.frame only. If I do this I
get the following warning from R CMD check:
* checking use of S3 registration ... WARNING
Registered S3 method from a standard package overwritten by 'papeR':
method from
plot.data.frame graphics
The reason for this is given in the following statement by Prof. Ripley:
> Do not replace registered S3 methods from base/recommended packages,
> something which is not allowed by the CRAN policies and will mean
> that everyone gets your method even if your namespace is unloaded.
The route I am taking is one of the advised routes to go (see
https://github.com/hofnerb/papeR/issues/5). So I am still looking for a
fix of this issue.
Your warning regarding the changed user experience is well noted.
However, I think (and am aware that this is my personal opinion) that a
lot of users will not miss the standard plot.data.frame method which is
only well defined for numerics anyway and not very informative in many
situations. After your comment I am thinking of adding an option to my
plot.data.frame function which allows to fall back to the original user
experience.
Thanks,
Benjamin
Am 01.09.2015 um 04:37 schrieb Gavin Simpson:
Why do you even need to take over `plot`, `plot.default`? You can just
register/export the plot.data.frame method from our package without
touching the generic or default method. The part of WRE that you refer
to is about making functions that are *not* S3 methods in one of base R
or it's packages into S3 generics. You are just providing a method for
an existing generic so you don't need to follow that code.
That said, it wouldn't be good form to fundamentally alter the way
plot.data.frame worked as users might expect certain functionality.
HTH
G
On 31 August 2015 at 04:03, Benjamin Hofner mailto:benjamin.hof...@fau.de>> wrote:
Dear all,
CRAN policies do not allow that single methods (for generic
functions) which are defined in base or recommended packages are
replaced. They advice package authors to replace the standard
generic and use a xxx.default method which then calls the original
standard generic.
Using the following code
## overwrite standard generic
plot <- function(x, y, ...)
UseMethod("plot")
## per default fall back to standard generic
plot.default <- function(x, y, ...)
graphics::plot(x, y, ...)
## now specify modified plot function for data frames
plot.data.frame <- function(x, variables = names(x), ...)
essentially works for all tested plot.xxx functions. Yet, it breaks
plot.formula. How can I proceed to overwrite plot.data.frame without
breaking plot.formula. Any help is greatly appreciated.
For a detailed description of the problem with syntax highlighting
and code to reproduce the problem please see:
http://stackoverflow.com/questions/32246361/redefinition-of-generic-for-plot-function-breaks-plot-formula
Best,
Benjamin
--
******
Dr. rer. nat. Benjamin Hofner
Institut für Medizininformatik, Biometrie und Epidemiologie
Friedrich-Alexander-Universität Erlangen-Nürnberg
Waldstr. 6 - 91054 Erlangen - Germany
Tel: +49-9131-85-22707
Fax: +49-9131-85-25740
Büro:
Raum 3.036
Universitätsstraße 22
(Eingang linke Seite des Gebäudes; Wegweiser IMBE)
benjamin.hof...@fau.de <mailto:benjamin.hof...@fau.de>
http://www.imbe.med.uni-erlangen.de/cms/benjamin_hofner.html
http://www.benjaminhofner.de
__
R-package-devel@r-project.org <mailto:R-package-devel@r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Gavin Simpson, PhD
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Redefinition of generic for plot function breaks plot.formula
I am using it this way as I want to be able to plot data.frames but have
a better display and more options. Thus, using plot.data.frame seems
rather natural. A different function or new classes are just a work
around. I do not want to use a new class as these functions should work
on ANY data frame without coercion.
Additionally, I had the function plot.data.frame [*] in an old versions
of the package and would like to keep it for backward compatibility.
[*] admittedly the function was plot.labeled.data.frame but I dropped
the class labeled.data.frame as all my functions now work on regular
data frames as well. If labels are present, these are used. If not, not.
Benjamin
Am 01.09.2015 um 15:44 schrieb Gavin Simpson:
...or have an object that is a data.frame but to which you add an
additional class
class(obj) <- c("my_df", "data.frame")
Then you can include plot.my_df() in your package, plus a function to
create a my_df object from a data frame, and you don't have to worry
about all this and your objects will still work like data frames
G
On Sep 1, 2015 07:15, "Hadley Wickham" mailto:h.wick...@gmail.com>> wrote:
Why don't you just create your own function?
Hadley
On Tue, Sep 1, 2015 at 8:08 AM, Benjamin Hofner
mailto:benjamin.hof...@fau.de>> wrote:
> Dear Gavin,
>
> unfortunately, I cannot overwrite plot.data.frame only. If I do
this I
> get the following warning from R CMD check:
>
> * checking use of S3 registration ... WARNING
> Registered S3 method from a standard package overwritten by 'papeR':
> method from
> plot.data.frame graphics
>
> The reason for this is given in the following statement by Prof.
Ripley:
>
>> Do not replace registered S3 methods from base/recommended packages,
>> something which is not allowed by the CRAN policies and will mean
>> that everyone gets your method even if your namespace is unloaded.
>
> The route I am taking is one of the advised routes to go (see
> https://github.com/hofnerb/papeR/issues/5). So I am still looking
for a fix
> of this issue.
>
> Your warning regarding the changed user experience is well noted.
However, I
> think (and am aware that this is my personal opinion) that a lot
of users
> will not miss the standard plot.data.frame method which is only
well defined
> for numerics anyway and not very informative in many situations.
After your
> comment I am thinking of adding an option to my plot.data.frame
function
> which allows to fall back to the original user experience.
>
> Thanks,
> Benjamin
>
> Am 01.09.2015 um 04:37 schrieb Gavin Simpson:
>>
>> Why do you even need to take over `plot`, `plot.default`? You
can just
>> register/export the plot.data.frame method from our package without
>> touching the generic or default method. The part of WRE that you
refer
>> to is about making functions that are *not* S3 methods in one of
base R
>> or it's packages into S3 generics. You are just providing a
method for
>> an existing generic so you don't need to follow that code.
>>
>> That said, it wouldn't be good form to fundamentally alter the way
>> plot.data.frame worked as users might expect certain functionality.
>>
>> HTH
>>
>> G
>>
>> On 31 August 2015 at 04:03, Benjamin Hofner
mailto:benjamin.hof...@fau.de>
>> <mailto:benjamin.hof...@fau.de <mailto:benjamin.hof...@fau.de>>>
wrote:
>>
>> Dear all,
>>
>> CRAN policies do not allow that single methods (for generic
>> functions) which are defined in base or recommended packages are
>> replaced. They advice package authors to replace the standard
>> generic and use a xxx.default method which then calls the
original
>> standard generic.
>>
>> Using the following code
>>
>>
>> ## overwrite standard generic
>> plot <- function(x, y, ...)
>> UseMethod("plot")
>>
>> ## per default fall back to standard generic
>> plot.default <- function(x, y, ...)
>> graphics::plot(x, y, ...)
>>
>> ## now specify modified plot function for data frames
>> plot.data.frame <- function(x, variables = names(x), ...)
>>
>>
>> essentially works
Re: [R-pkg-devel] Redefinition of generic for plot function breaks plot.formula
Dear Gavin,
you and Hadley seem to be right. It looks like a problem which is buried
deeper within R and the method dispatch. It seems like I have to
reintroduce the class labeled.data.frame and plot.labeled.data.frame.
However, I will post on R-devel to try to understand this issue.
Thanks a lot!
Benjamin
Am 01.09.2015 um 17:54 schrieb Gavin Simpson:
It's not just plot.formula that is broken; plot.lm is dead too for
example. It's seems that just unexported methods fail to be called. This
works plot(ts(1:100)), correctly calling the plot.ts method.
What you must be doing overwriting the plot generic seems to be
clobbering S3 dispatch or killing the registration of those methods such
that they never get called.
I think you might need to take this to R Devel to ask what is happening
to S3 dispatch when you modify the generic (by providing your own),
unless someone else here knows what is going on?
If this isn't a problem in R, it looks like it would be easier all round
to follow Prof. Ripley's other advice/option and add a new class to
data.frame objects and provide a method for that new class...
HTH
G
On 1 September 2015 at 07:53, Benjamin Hofner mailto:benjamin.hof...@fau.de>> wrote:
I am using it this way as I want to be able to plot data.frames but
have a better display and more options. Thus, using plot.data.frame
seems rather natural. A different function or new classes are just a
work around. I do not want to use a new class as these functions
should work on ANY data frame without coercion.
Additionally, I had the function plot.data.frame [*] in an old
versions of the package and would like to keep it for backward
compatibility.
[*] admittedly the function was plot.labeled.data.frame but I
dropped the class labeled.data.frame as all my functions now work on
regular data frames as well. If labels are present, these are used.
If not, not.
Benjamin
Am 01.09.2015 um 15:44 schrieb Gavin Simpson:
...or have an object that is a data.frame but to which you add an
additional class
class(obj) <- c("my_df", "data.frame")
Then you can include plot.my_df() in your package, plus a
function to
create a my_df object from a data frame, and you don't have to worry
about all this and your objects will still work like data frames
G
On Sep 1, 2015 07:15, "Hadley Wickham" mailto:h.wick...@gmail.com>
<mailto:h.wick...@gmail.com <mailto:h.wick...@gmail.com>>> wrote:
Why don't you just create your own function?
Hadley
On Tue, Sep 1, 2015 at 8:08 AM, Benjamin Hofner
mailto:benjamin.hof...@fau.de>
<mailto:benjamin.hof...@fau.de <mailto:benjamin.hof...@fau.de>>>
wrote:
> Dear Gavin,
>
> unfortunately, I cannot overwrite plot.data.frame only.
If I do
this I
> get the following warning from R CMD check:
>
> * checking use of S3 registration ... WARNING
> Registered S3 method from a standard package overwritten
by 'papeR':
> method from
> plot.data.frame graphics
>
> The reason for this is given in the following statement
by Prof.
Ripley:
>
>> Do not replace registered S3 methods from
base/recommended packages,
>> something which is not allowed by the CRAN policies and
will mean
>> that everyone gets your method even if your namespace
is unloaded.
>
> The route I am taking is one of the advised routes to go
(see
> https://github.com/hofnerb/papeR/issues/5). So I am
still looking
for a fix
> of this issue.
>
> Your warning regarding the changed user experience is
well noted.
However, I
> think (and am aware that this is my personal opinion)
that a lot
of users
> will not miss the standard plot.data.frame method which
is only
well defined
> for numerics anyway and not very informative in many
situations.
After your
> comment I am thinking of adding an option to my
plot.data.frame
function
> which allows to fall back to the original user experience.
>
> Thanks,
> Benjamin
>
> Am 01.09.2015 um 04:37 schrieb Gavin Simpson:
>>
>&
