Re: [Rd] cat() in system.time() ?
On Fri, 15 Jul 2016, Martin Maechler wrote:
Hi Ben (and everyone else),
as this did not attract attention yet, let me start
Ben Bolker
on Mon, 4 Jul 2016 11:49:40 -0400 writes:
> Does anyone know if there's a reason that proc.time() uses cat()
> rather than message() to print the output when there has been an error
> in the process of timing?
This is really not about proc.time(), but about system.time()
[ and I have corrected the 'Subject' accordingly ] ..
> line 31 of time.R,
>
https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/library/base/R/time.R#L31
> on.exit(cat("Timing stopped at:", ppt(proc.time() - time), "\n"))
> This means that as far as I can tell the general way to make sure
> there is no output from a timed statement is ...
> tt1 <- capture.output(tt0 <- suppressMessages(suppressWarnings(
> try(, silent=TRUE
> (I know I could/should be using tryCatch() instead of try(), but I don't
> think it really matters here ... ?)
> What would people think of a request to change this to message()
> rather than cat() in the future ... ? (This would mess up code that is
> already using capture.output() to store this information ...)
[I think that (last issue) would be acceptable.]
One reason of the current cat() may just be historical:
message() did not exist yet when system.time() was created.
However, I agree that that is not good enough a reason to keep
it. Much more important is the fact that it is *nice* that the
message
Timing stopped at: ...
is printed in many cases when a system.time()d call is stopped
early. Quite often for me this is *not* when an error happens
as your suppress*() contortions (;-) suggest, but rather when I
interrupt the long lasting call.
And the current setup nicely gives
> i <- 0; system.time( while(TRUE) i <- i+1 )
C-c C-c
Timing stopped at: 1.001 0.084 1.086
>
However, at least this simple case, also works fine with
message() instead of cat() ... as I just tried now.
A harder case are the "bad errors", e.g., memory overflow and
similar bad things...
cat() seems to be pretty robust, where as message() does invoke
a handler (exactly *why* you want it, right?) and that may be
harder to keep working correctly after certain errors than a
simple cat().
I hope that some real experts (on "context switching", "long
jumps", etc) would chime in now.
I don't have a strong opinion on whether message would be better or
not. But now that the on.exit code is executed after unwinding the C
call back to the point of the system.time call there is no longer such
a robustness issue.
Best,
luke
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cat() in system.time() ?
On 17.07.2016 18:13, luke-tier...@uiowa.edu wrote:
On Fri, 15 Jul 2016, Martin Maechler wrote:
Hi Ben (and everyone else),
as this did not attract attention yet, let me start
Ben Bolker
on Mon, 4 Jul 2016 11:49:40 -0400 writes:
> Does anyone know if there's a reason that proc.time() uses cat()
> rather than message() to print the output when there has been an
error
> in the process of timing?
This is really not about proc.time(), but about system.time()
[ and I have corrected the 'Subject' accordingly ] ..
> line 31 of time.R,
>
https://github.com/wch/r-source/blob/e5b21d0397c607883ff25cca379687b86933d730/src/library/base/R/time.R#L31
> on.exit(cat("Timing stopped at:", ppt(proc.time() - time), "\n"))
> This means that as far as I can tell the general way to make sure
> there is no output from a timed statement is ...
> tt1 <- capture.output(tt0 <- suppressMessages(suppressWarnings(
>try(, silent=TRUE
> (I know I could/should be using tryCatch() instead of try(), but
I don't
> think it really matters here ... ?)
> What would people think of a request to change this to message()
> rather than cat() in the future ... ? (This would mess up code
that is
> already using capture.output() to store this information ...)
[I think that (last issue) would be acceptable.]
One reason of the current cat() may just be historical:
message() did not exist yet when system.time() was created.
However, I agree that that is not good enough a reason to keep
it. Much more important is the fact that it is *nice* that the
message
Timing stopped at: ...
is printed in many cases when a system.time()d call is stopped
early. Quite often for me this is *not* when an error happens
as your suppress*() contortions (;-) suggest, but rather when I
interrupt the long lasting call.
And the current setup nicely gives
> i <- 0; system.time( while(TRUE) i <- i+1 )
C-c C-c
Timing stopped at: 1.001 0.084 1.086
>
However, at least this simple case, also works fine with
message() instead of cat() ... as I just tried now.
A harder case are the "bad errors", e.g., memory overflow and
similar bad things...
cat() seems to be pretty robust, where as message() does invoke
a handler (exactly *why* you want it, right?) and that may be
harder to keep working correctly after certain errors than a
simple cat().
I hope that some real experts (on "context switching", "long
jumps", etc) would chime in now.
I don't have a strong opinion on whether message would be better or
not. But now that the on.exit code is executed after unwinding the C
call back to the point of the system.time call there is no longer such
a robustness issue.
I am not sure how much some "R CMD check" extras for reporting
example/test/vignette runtimes are affected. In case anybody is going to
change this, please take a careful look or expect to back it out if we
expewrience problems and have to change code.
Best,
Uwe
Best,
luke
Martin
__
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
