[Rd] step() in sink() and Sweave()

Gavin Simpson gavin.simpson at ucl.ac.uk
Wed Jun 13 18:50:20 CEST 2007


On Wed, 2007-06-13 at 08:04 -0700, Seth Falcon wrote:
> Jari Oksanen <jarioksa at sun3.oulu.fi> writes:
> 
> > On Wed, 2007-06-13 at 13:33 +0100, Gavin Simpson wrote:
> >> Dear Developers,
> >> 
> >> This change also just bit me whilst updating Sweave documents for some
> >> computer classes.
> >> 
> >> Is there a work-around that can be employed so that we get both the
> >> message() bits and the print() bits in the same place for our Sweave
> >> files?
> >> 
> >> If not, is there any point in filing this as a bug in R? I see there
> >> have been no (public) responses to Jari's email, yet the change is
> >> rather annoying, and I do not see the rationale for "printing" different
> >> parts of the output from step() in two different ways.
> >> 
> > I think this is a bug. You should not use message() with optional trace.
> > The template for the usage in step() is first
> >
> > if (trace) message()
> >
> > and later
> >
> > if (trace) print()
> >
> > If you specifically request printing setting  trace = TRUE, then you
> > should not get message().
> >
> > Interestingly, message() seems to be a warning() that cannot be
> > suppressed by setting options.
> 
> message is a condition and so is a warning.  This means you have some
> control over them.  For example, you can create a wrapper for step
> that uses withCallingHandlers to cat out all messages (or print them,
> or email them to your friends :-)
> 
> mystep <- function(object, scope, scale = 0,
>                    direction = c("both", "backward", "forward"),
>                    trace = 1, keep = NULL, steps = 1000, k = 2, 
>                    ...)
> {
>     withCallingHandlers(step(object=object, scope=scope, scale=scale,
>                              direction=direction, trace=trace,
>                              keep=keep, steps=steps, k=k, ...),
>                         message=function(m) {
>                             cat(conditionMessage(m))
>                         })
> }
> 
> > This is so annoying that I haven't updated some of my Sweave documents.
> > It is better to have outdated documents than crippled documents.
> 
> I'm not trying to argue that the function shouldn't change, but if it
> is so annoying, you can also resolve this problem by defining your own
> step function and calling it (forgetting about withCallingHandlers).
> Clearly not ideal, but at the same time in the spirit of open source,
> no?

Thanks for the info on bypassing this issue Seth.

I disagree about your final comment though. If one is trying to teach
the use of step() to people in a computer practical class and you want
to show example output along with the commands used to produce it, you
can't do what you did and produce your own function - it wouldn't be a
good way to teach step() if I was using mystep() in the example code!

If this had been a report I was writing, I'd have just hacked my own
version of step that used print() all the time; one of the reasons I use
R in the first place is that I can go and do this. But this isn't an
option when teaching.

I am still a little mystified as to why the message() and print() bits
are used anyway. I mean, someone obviously felt this was a good idea or
they wouldn't have spent their time making the changes, and I accept
that I am probably not seeing the bigger picture here, but I don't see
the difference between the two bits of information and why you'd want to
treat them differently - why isn't the bit that is print()ed considered
a message for example?

Cheers,

G

> 
> + seth
> 
-- 
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
 Gavin Simpson                 [t] +44 (0)20 7679 0522
 ECRC, UCL Geography,          [f] +44 (0)20 7679 0565
 Pearson Building,             [e] gavin.simpsonATNOSPAMucl.ac.uk
 Gower Street, London          [w] http://www.ucl.ac.uk/~ucfagls/
 UK. WC1E 6BT.                 [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%



More information about the R-devel mailing list