Re: [Rd] step() in sink() and Sweave()
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.
All the best,
Gav
On Wed, 2007-05-09 at 08:10 +, Jari Oksanen wrote:
> Dear developers,
>
> I just noticed that step() function currently prints the current model
> using message(), but the resulting model using print(). The relevant
> commands within the step() body are:
>
> if (trace) message("Start: AIC=", format(round(bAIC, 2)), "\n",
> cut.string(deparse(as.vector(formula(fit, "\n")
>
> (with example() output:)
> Start: AIC=190.69
> Fertility ~ Agriculture + Examination + Education + Catholic +
> Infant.Mortality
>
> And later:
>
> if (trace) print(aod[o, ])
>
> (with example() output:)
>
>Df Sum of SqRSSAIC
> - Examination 1 53.0 2158.1 189.9
> 2105.0 190.7
> - Agriculture 1 307.7 2412.8 195.1
> - Infant.Mortality 1 408.8 2513.8 197.0
> - Catholic 1 447.7 2552.8 197.8
> - Education 11162.6 3267.6 209.4
>
> This is a nuisance if you want to divert output to a file with sink() or
> use step() in Sweave: the header and the table go to different places,
> and without message() part the print() part is crippled. It may be that
> there is some way to avoid this, but obviously that needs some degree of
> acrobatic R skills.
>
> An example of the behaviour:
>
> sink(tempfile())
> example(step)
> sink()
>
> I assueme that the behaviour is intentional but searching NEWS did not
> give any information or reasoning. Would it be sensible to go back to
> the old behaviour? I found some Swoven files from R 2.4.0 that still put
> both parts of the output to the same place. For the sake of Sweave and
> sink, I'd prefer the one place to be stdout instead of stderr.
>
> Best wishes, Jari Oksanen
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
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
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] subset() only returns first of equally named columns from a data.frame (PR#9733)
Full_Name: Manfred Beier
Version: 2.5.0 (2007-04-23)
OS: linux-gnu
Submission from: (NULL) (134.99.204.101)
When multiple columns in a data.frame have the same name, only the first of them
is returned by the subset() function even when selected numerically.
> test <- data.frame(cbind(1,2,3))
> names(test) <- c("a","a","a")
> test
a a a
1 1 2 3
> subset(test, TRUE, c(2,3))
a a.1
1 1 1
For matrices subset() works correctly.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] step() in sink() and Sweave()
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. This is so annoying that I haven't updated some of my Sweave documents. It is better to have outdated documents than crippled documents. You can handle this in sink(), but I don't know any trick for Sweave (and it's a nuisance in sink() as well). cheers, jari oksanen -- Jari Oksanen -- Dept Biology, Univ Oulu, FI-90014 Oulu, Finland Ph. +358 85531526, cell +358 405136529, fax +358 85531061, skype jhoksane email [EMAIL PROTECTED], homepage http://cc.oulu.fi/~jarioksa/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] step() in sink() and Sweave()
> On Wed, 13 Jun 2007 16:43:32 +0300, > Jari Oksanen (JO) wrote: > 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. > This is so annoying that I haven't updated some of my Sweave documents. > It is better to have outdated documents than crippled documents. > You can handle this in sink(), but I don't know any trick for Sweave > (and it's a nuisance in sink() as well). The topic is on the agenda, but no released code yet. Hadley Wickham has code collecting all output, messages, warning etc that arise when an expression is evaluated which can be used in various places like sink or Sweave to solve this problem. We have already scheduled discussions for a workshop which we both attend in 3 weeks. Sorry for not replying to the original email. Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9733) subset() only returns first of equally named
>From NEWS for 2.5.0 patched:
o [i, j] could sometimes select the wrong column
when j is numeric if there are duplicate column names.
> subset(test, TRUE, c(2,3))
a a.1
1 2 3
Please do not report bugs that are already fixed (as asked in the FAQ).
On Wed, 13 Jun 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Manfred Beier
> Version: 2.5.0 (2007-04-23)
> OS: linux-gnu
> Submission from: (NULL) (134.99.204.101)
>
>
> When multiple columns in a data.frame have the same name, only the first of
> them
> is returned by the subset() function even when selected numerically.
>
>> test <- data.frame(cbind(1,2,3))
>> names(test) <- c("a","a","a")
>> test
> a a a
> 1 1 2 3
>> subset(test, TRUE, c(2,3))
> a a.1
> 1 1 1
>
> For matrices subset() works correctly.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] step() in sink() and Sweave()
Jari Oksanen <[EMAIL PROTECTED]> 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?
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Test for Equality of Coefficient of Variation
Hi ALL, Do R have any tools for testing equality of coefficients of variation for k normal populations ? Thank you, Gregory Kotler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.5.1 scheduled for June 28
This is to announce that we plan to release R version 2.5.1 on Thursday June 28, 2007. The following information is mainly for developers, package maintainers and repository maintainers. The planned procedure is June 14: Feature Freeze 2.5.1 beta June 21: Code Freeze 2.5.1 RC June 28: Release 2.5.1 FF: Feature set complete, only bugfixing from now on CF: Only critical bugfixes and platform build issues Maintainers of recommended packages should notice that as they become part of the final R tarball, we expect them to follow a similar freeze pattern (and beware of potential CRAN delays, so please do not cut it too close to the deadlines). The source beta/RC tarballs will be made available daily (barring build troubles) by a cron job running at 4AM CET, and the tarballs can be picked up at http://cran.r-project.org/src/base-prerelease/ a little later. The various freeze points are marked by changes to the VERSION file this is also done automatically by a cron job which runs just after midnight on the relevant days. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reported invalid memory references
While testing for leaks in my own code I noticed some reported memory problems from valgrind, invoked with $ R --vanilla -d "valgrind --leak-check=full" This is on Debian GNU/Linux (testing aka lenny) with a 2.6 kernel, R package version 2.4.1-2. I was running in an emacs shell. The immediate source of all the problems before I get to the prompt is the system dynamic loader ld-2.5.so, invoked from R. Then, when I exit, there are a bunch of reported leaks, some of which appear to be more directly from R (though some involve, e.g., readline). Are these reported errors actually problems? If so, do they indicate problems in R or some other component (e.g., ld.so). Put more practically, should I file one or more bugs, and if so, against what? Thanks. Ross Boylan ==30551== Invalid read of size 4 ==30551==at 0x4016503: (within /lib/ld-2.5.so) ==30551==by 0x4006009: (within /lib/ld-2.5.so) ==30551==by 0x40084F5: (within /lib/ld-2.5.so) ==30551==by 0x40121D4: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4414494: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF73E: __nss_lookup_function (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF82F: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43F1595: __nss_passwd_lookup (in /lib/i686/cmov/libc-2.5.so) ==30551== Address 0x4EFB560 is 32 bytes inside a block of size 34 alloc'd ==30551==at 0x40234B0: malloc (vg_replace_malloc.c:149) ==30551==by 0x4008AF3: (within /lib/ld-2.5.so) ==30551==by 0x40121D4: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4414494: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF73E: __nss_lookup_function (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF82F: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43F1595: __nss_passwd_lookup (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x439D87D: getpwuid_r (in /lib/i686/cmov/libc-2.5.so) ==30551== ==30551== Invalid read of size 4 ==30551==at 0x4016530: (within /lib/ld-2.5.so) ==30551==by 0x4006009: (within /lib/ld-2.5.so) ==30551==by 0x40084F5: (within /lib/ld-2.5.so) ==30551==by 0x400C616: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x400CBDA: (within /lib/ld-2.5.so) ==30551==by 0x4012234: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4414494: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.5.so) ==30551== Address 0x4EFB8A8 is 24 bytes inside a block of size 27 alloc'd ==30551==at 0x40234B0: malloc (vg_replace_malloc.c:149) ==30551==by 0x4008AF3: (within /lib/ld-2.5.so) ==30551==by 0x400C616: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x400CBDA: (within /lib/ld-2.5.so) ==30551==by 0x4012234: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4414494: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF73E: __nss_lookup_function (in /lib/i686/cmov/libc-2.5.so) ==30551== ==30551== Conditional jump or move depends on uninitialised value(s) ==30551==at 0x400B3CC: (within /lib/ld-2.5.so) ==30551==by 0x401230B: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4414494: __libc_dlopen_mode (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF73E: __nss_lookup_function (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43EF82F: (within /lib/i686/cmov/libc-2.5.so) ==30551==by 0x43F1595: __nss_passwd_lookup (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x439D87D: getpwuid_r (in /lib/i686/cmov/libc-2.5.so) ==30551==by 0x439D187: getpwuid (in /lib/i686/cmov/libc-2.5.so) ==30551== ==30551== Conditional jump or move depends on uninitialised value(s) ==30551==at 0x400B0CA: (within /lib/ld-2.5.so) ==30551==by 0x401230B: (within /lib/ld-2.5.so) ==30551==by 0x400E255: (within /lib/ld-2.5.so) ==30551==by 0x4011C5D: (within /lib/ld-2.5.so) ==30551==by 0x44142E1: (within /lib/i686/cmov/libc-2.5.so)
Re: [Rd] step() in sink() and Sweave()
On Wed, 2007-06-13 at 08:04 -0700, Seth Falcon wrote:
> Jari Oksanen <[EMAIL PROTECTED]> 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
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R.INSTALL on Windows
Hi, This has been addressed in R-2.5.0 and R-2.6.0. Thanks! H. Herve Pages wrote: > Hi, > > I'd like to point out a potential problem with the current R.INSTALL > directory created by 'R CMD INSTALL' when applied to a source package. > > On Windows (and, AFAIK, only on Windows), 'R CMD INSTALL > mypackage_1.0.0.tar.gz' > creates a temporary R.INSTALL directory in the current directory. This > directory is removed before the command terminates but only if it was > successful. > > One inconvenient of this behaviour is that you can get a clash when you try to > build 2 Windows binary packages (with 'R CMD INSTALL --build') at the same > time > in the same directory. I can circumvent the 00LOCK mechanism by providing > a different --library option to the 2 commands but, if I'm running the 2 > commands > in the same directory, then they will be creating and using the same > R.INSTALL. > Then, the first command who terminates will remove it and break the other > command. > > Is there an easy way to prevent this? > > Is there any reason why R.INSTALL is not kept at the end of 'R CMD INSTALL', > or why 'R CMD INSTALL' doesn't use a package specific directory name > (e.g. R.INSTALL.mypackage) like 'R CMD check' does, or why it doesn't > use one of the "standard" temp places (defined by env. var. TMP or TMPDIR). > > Thanks in advance! > > Cheers, > H. > > __ > 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] PATCH: install inst/ before doing lazyload on Windows
Seth Falcon <[EMAIL PROTECTED]> writes: > On Windows, package files in the inst/ subdir are installed after the > lazyload creation. This differs from Linux where inst/ is installed > _before_ lazyload creation. > > Since packages may need data in inst, I think the order on Windows > should be changed. Perhaps like this: This has been fixed in R devel and patched. Thanks! + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
