[Rd] warnings() generates error if there never were any (PR#4389)
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--_=_NextPart_000_01C388B0.D441A780
Content-Type: text/plain; charset=iso-8859-1
In debugging a long-running function where I occasionally call warnings() to
write out any warnings that have occurred, I discovered that calling
warnings() before any warnings have ever been generated causes an error:
warnings()
Error in warnings() : Object last.warning not found
The problem is that warnings() attemts to check the length of the variable
'last.warning' without first checking for its existance.
This problem exists in R 1.7.1 as well as in the new 1.8.0 beta code.
A simple patch fixes the problem:
--- warnings.R.orig 2003-10-02 02:35:04.359451000 -0400
+++ warnings.R 2003-10-02 02:42:08.900717000 -0400
@@ -1,6 +1,6 @@
warnings - function(...)
{
-if(!(n - length(last.warning)))
+if(!exists(last.warning) || !(n - length(last.warning)))
return()
names - names(last.warning)
cat(Warning message, if(n 1)s, :\n, sep=)
-Greg
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wrong results in dist.binary (library ade4) (PR#4384)
[EMAIL PROTECTED] wrote: Full_Name: Christian D?ring Version: 1.6.2 [Outdated versions are not appropiate for bug reports - irrelevant here, though.] OS: win32 Submission from: (NULL) (62.224.59.150) Function dist.binary in add-on library ade4 yields wrong results due to wrong association of method number and index formula. Examples: method=6 should be 5 (S7, Soerensen index) method=7 should be 6 (S9 index) Ochiai index is missing Same in current version of ade4 (ade4_1.04.zip). Please do report bugs of contributed packages to the package maintainer, but *not* to R-Bugs. Uwe Ligges __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] colours in dotchart (PR#4343)
UweL == Uwe Ligges [EMAIL PROTECTED]
on Wed, 1 Oct 2003 11:33:40 +0200 (MET DST) writes:
...
UweL b) The argument color works for the points, but not so for their
UweL labels. The proposal (by Ian) is to remove the loops. Does that break
UweL anything? At least, I cannot imagine any point right now.
I think you (Ian Uwe) have a good point here.
This might (or may not) still go as a trivial bug fix for 1.8.0.
{If you want to help, please try to use diff -u (or diff -c)
for a patch.. }
But I first need to get my grips on dendrogram buggyness.
Martin
UweL So here's a proposal for dotchart.R
I have committed it just now as simple bug fix to R
1.8.0beta.
UweL (Anyone who can imagine why the loop had been
UweL introduced? Are we breaking anything when rempoving
UweL the loop?):
dotchart() is a very old R function and has a peculiar history.
It was there in the very first R version I think I have ever
seen (Jul 1995, pre alpha, no version number) -- however with text() {and
no for()} there. Later it was renamed to dotplot() {I don't know
why} and in Apr 2001 was renamed *back* to dotchart() in order
not to resolve a naming conflict with the lattice dotplot()
function.
Here is the revision text {for dotplot.R back then} where Ross
changed fromtext() to for(.) mtext()
Revision 1.3 , Tue May 5 08:39:30 1998 UTC (5 years, 4 months ago) by ihaka
Branch: MAIN
Changes since 1.2: +88 -79 lines
Fixes to dotplot code. Updates to mtext and text.
Now, the graphical argument recycling has been in R from early
on (as a clear improvement over S-plus!), too, but not as
consistently as it became around version 1.2 or so, and
particularly not with mtext(). Hence I assume , the change from
text() to mtext() needed to introduce the for() loop back then.
(so far the archeological/historical account from digging in old stuff ..)
Martin Maechler [EMAIL PROTECTED] http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Are package maintainers responsible for name-mangling class names?
The following came up when Roger Bivand and I discussed R's name spaces and overlap in packages, in the bus to the field trip during StatGIS, last Tuesday: If two packages create the same class, say variogram, and both are loaded, then using a method for an object of class variogram cannot discriminate between them and will call the method in the package loaded last. See example below. I know what is happening, but for average users this may be extremely confusing, especially when loading the second package does not result in a warning that plot.variogram in the first is masked (gstat uses name spaces and exports plot.variogram through S3method(plot, variogram), geoR does not) Shouldn't R know that objects created by functions in library x prefer there methods to be picked from library x, rather than the first in the search path? Isn't that one of the ideas behind name spaces? Shouldn't R give an error message when a loaded library masks a method in another library, as it does when an object is masked (such as it does when loading gstat after spatial)? If we are not going to deal with this, shouldn't CRAN reject (for now?) packages that create new classes and methods with names that are allready in other packages? -- Edzer Executing the following commands: library(gstat) data(meuse) v = variogram(log(zinc)~1, ~x+y, meuse) plot(v) # calls plot.variogram() in library gstat library(geoR) plot(v) # error: calls plot.variogram() in library geoR gives the following output: R library(gstat) Loading required package: lattice Loading required package: grid R data(meuse) R v = variogram(log(zinc) ~ 1, ~x + y, meuse) R plot(v) R library(geoR) - geoR - functions for geostatistical data analysis geoR version 1.3-16 (2003-09-17) is now loaded - R plot(v) Error in if (x$output.type == bin) Ldots$type - p : argument is of length zero In addition: Warning message: no finite arguments to max; returning -Inf __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Are package maintainers responsible for name-mangling class names?
On Thu, 2 Oct 2003, Edzer J. Pebesma wrote: The following came up when Roger Bivand and I discussed R's name spaces and overlap in packages, in the bus to the field trip during StatGIS, last Tuesday: If two packages create the same class, say variogram, and both are loaded, then using a method for an object of class variogram cannot discriminate between them and will call the method in the package loaded last. See example below. I know what is happening, but for average users this may be extremely confusing, especially when loading the second package does not result in a warning that plot.variogram in the first is masked (gstat uses name spaces and exports plot.variogram through S3method(plot, variogram), geoR does not) Shouldn't R know that objects created by functions in library x prefer there methods to be picked from library x, rather than the first in the search path? Isn't that one of the ideas behind name spaces? I think this can only happen if method registration is compulsory (and if you want S4 methods, you know where to find them). Shouldn't R give an error message when a loaded library masks a method in another library, as it does when an object is masked (such as it does when loading gstat after spatial)? Yes. I don't know whether this is an oversight or something that would be nice but is too difficult. I think it's unlikely to be fixed by next week for 1.8.0, though. If we are not going to deal with this, shouldn't CRAN reject (for now?) packages that create new classes and methods with names that are allready in other packages? I hope not. Note that it is probably not easy to come up with an automated system that can distinguish a package that uses classes from other packages from one that overrides classes from other packages. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with console in Windows GUI (PR#4381)
Full_Name: Andrew Zachary Version: 1.7.1 OS: XP Pro Submission from: (NULL) (24.44.128.138) The R-console window in the Windows GUI has a nice feature that lets you save your preferences for font sizes and background and foreground colors. Unhappily, there is no way to load these preferences back in when starting a new session. Also, the scroll window for selecting colors is very small and awkward. If I want to select a color which is towards the top or the bottom of the list, I have to scrolls (slowly) through all the entries to get to it. Would make more sense to have a color window with user-selectable colors. Thanks! Andrew Zachary __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] hist (PR#4395)
It is not really a bug but a strange choice. When the option freq=F chosen, hist should plot relative frequency. It plots proportional to relative frequency by the factor of bin width. Is there a reason for this? A more normal choice seems to be to have it independent of the bin width. Yash Mittal University of Arizona This message was sent using IMP, the Internet Messaging Program. __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist (PR#4395)
On Thursday 02 October 2003 20:48, [EMAIL PROTECTED] wrote: It is not really a bug but a strange choice. So why do you file it as a bug? When the option freq=F chosen, hist should plot relative frequency. It plots proportional to relative frequency by the factor of bin width. Is there a reason for this? Yes. A more normal choice seems to be to have it independent of the bin width. No, because then the histogram could not be used as a density estimate which is possible if the relative frequencies are proportional to the are and not the height of the segments. Z __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist (PR#4395)
On Thu, 2 Oct 2003 20:48:33 +0200 (MET DST), [EMAIL PROTECTED] wrote : It is not really a bug but a strange choice. Please don't post discussion to r-bugs. Each post to r-bugs ends up in the bug repository, and requires manual handling. When the option freq=F chosen, hist should plot relative frequency. It plots proportional to relative frequency by the factor of bin width. Is there a reason for this? A more normal choice seems to be to have it independent of the bin width. No, that would result in misleading plots. For example, if one bar is twice as wide as another but they are the same height, then the natural interpretation is that the wide bar represents twice as many observations, or twice the probability. This is the way densities work, and is how histograms should work. (However, since not everyone interprets histograms this way, it's safest not to use variable width bars.) If you just want to plot some bars where the area of the bar has no meaning, use barplot() instead of hist(). Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Leaving 'Package:' out of description deletes entire library (PR#4398)
Full_Name: Byron Ellis Version: R-devel (1.8.0) OS: OS X Submission from: (NULL) (209.150.60.78) I recently left out the 'Package' field out of the DESCRIPTION file (yes, I know about package.skeleton() ) only to discover that when you leave this out R CMD INSTALL fails and _deletes the entire library_: bash-2.05a$ R CMD INSTALL twclust * Installing *source* package '' ... Error in .installPackageDescription(., /Users/bellis/sandbox/R/library/) : required fields missing from DESCRIPTION: Package Execution halted ERROR: installing package DESCRIPTION failed ** Removing '/Users/bellis/sandbox/R/library/' __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
