[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
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
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] Problem with console in Windows GUI (PR#4381)
On Thu, 02 Oct 2003 12:58:01 -0400, "Liaw, Andy" <[EMAIL PROTECTED]> wrote : >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> 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. > >Have you not noticed the "Save" button? To expand on that: by default, Save puts the preferences in a file called Rconsole in the current directory; on startup, R looks for Rconsole in the R_USER directory (which defaults to the current directory), and if it doesn't find one there, in the R_HOME/etc directory. However, there's a bug in the current beta: near the end it writes out the lines ## Initial position of the graphics window ## (pixels, <0 values from opposite edge) xgraphics = ygraphics = but it can't read those because of the missing values. I'll try to get that fixed for 1.8.0. >> 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. That would make sense, but it's not likely to happen (and certainly won't for 1.8.0): we've more or less stopped adding features to the current Rgui. If I (or someone else) ever gets time, I intend to replace it with an all new one. Duncan Murdoch __ [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] Problem with console in Windows GUI (PR#4381)
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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. Have you not noticed the "Save" button? Andy > 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 > __ [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
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] 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] warnings() generates error if there never were any (PR#4389)
> "Greg" == gregory r warnes <[EMAIL PROTECTED]>
> on Thu, 2 Oct 2003 08:46:09 +0200 (MET DST) writes:
Greg> This message is in MIME format. Since your mail reader does not understand
Greg> this format, some or all of this message may not be legible.
Greg> --_=_NextPart_000_01C388B0.D441A780
Greg> Content-Type: text/plain; charset="iso-8859-1"
[ please *never* attach anything for bug reports.
The current bug-management system messes up the MIME ]
Greg> In debugging a long-running function where I
Greg> occasionally call warnings() to write out any warnings
Greg> that have occurred, I discovered that calling
Greg> warnings() before any warnings have ever been
Greg> generated causes an error:
>> warnings()
Greg> Error in warnings() : Object "last.warning" not found
Greg> The problem is that warnings() attemts to check the
Greg> length of the variable 'last.warning' without first
Greg> checking for its existance.
Greg> This problem exists in R 1.7.1 as well as in the new 1.8.0 beta code.
Greg> A simple patch fixes the problem:
Greg> --- warnings.R.orig 2003-10-02 02:35:04.359451000 -0400
Greg> +++ warnings.R 2003-10-02 02:42:08.900717000 -0400
Greg> @@ -1,6 +1,6 @@
Greg> warnings <- function(...)
Greg> {
Greg> -if(!(n <- length(last.warning)))
Greg> +if(!exists("last.warning") || !(n <- length(last.warning)))
Greg> return()
Greg> names <- names(last.warning)
Greg> cat("Warning message", if(n > 1)"s", ":\n", sep="")
Thank you Greg!
Fortunately, this falls into the category of "trivial bug fix"
(it cannot break anything), and hence still goes into 1.8.0
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
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 from " text() " 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
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
