Re: [Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values
On 5/23/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: [...] > It really is the case that writing out a number to > 15 significant digits > and reading it back in again is not required to give exactly the same > IEC60559 (sic) number, and furthermore there are R platforms for which > this does not happen. What Mr Weinberg claimed is 'now impossible' never > was possible in general (and he seems to be berating the R developers for > not striving to do better than the C standard requires of OSes). In fact, > I believe this to be impossible unless you have access to extended > precsion arithmetic, as otherwise printf/scanf have to use the same > arithmetic as the computations. I did not intend to berate anyone - I may have come across that way because I was frustrated, in which case I apologize. I *do* think it is reasonable to expect a numerical analysis program to have numerically stable, 100% accurate, perfectly roundtripping floating-point-to-text conversion, even if the system's runtime libraries don't get it right, even if the hardware does not provide extended precision to make it easier. In the worst case you have to muck around with software-emulated extended-precision FP, and even that really isn't that hard. There is code in GCC that does exactly this, it's only about 5000 LOC, and it does quite a bit more than R would need. If there were interest I could see about porting it across. zw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Bioc-devel] promptClass
> "MartinMo" == Martin Morgan <[EMAIL PROTECTED]>
> on Sat, 26 May 2007 21:44:27 -0700 writes:
MartinMo> promptClass fails to identify methods associated
MartinMo> with the class. Here is a fix:
Thank you, Martin;
I've applied your patch to my working copy of R-devel,
and I can confirm it solves the problem for class "AffyBatch"
(from bioconductor package 'affy').
However it does not seem to fix the problem in my case:
library(Matrix)
promptClass("sparseMatrix")
which still produces a sparseMatrix-class.Rd file which
contains
\section{Methods}{
No methods defined with class "sparseMatrix" in the signature.
}
so there's at least another bug there.
One difference: "sparseMatrix" is a virtual class, "AffyBatch"
not, but then showMethods(classes = "..") works for both.
I'd be glad if you have time to find another patch ;-) :-)
Martin Maechler
>> cstrato <[EMAIL PROTECTED]> writes:
>>
>>> Dear all,
>>>
>>> What is the best way to write the docs for S4 classes?
>>>
>>> Concretely, is it possible to include the methods in the
>>> class documentation? For example, the documentation for
>>> class "AffyBatch" contains all methods. However, when I
>>> do: promptClass("AffyBatch") the relevant output of file
>>> "AffyBatch-class.Rd" is: \section{Methods}{ No methods
>>> defined with class "AffyBatch" in the signature. }
>> promptClass used to provide more useful output. You
>> might want to report the issue on one of the R lists.
>>
>>> Since PromptClass() contains a parameter "where" is it
>>> possible to use it, and how?
>> I'm not sure that is relevant here.
>>
>> One thing that can be useful here is
>> showMethods(classes="AffyBatch"). The problem with
>> static documentation for methods is that what methods are
>> available can change based on what packages are attached.
>>
>> If showMethods or a wrapper for it could be convinced to
>> output a link to a help file, then it might actually be a
>> good way to go...
>>
>> + seth
>>
>> --
>> Seth Falcon | Computational Biology | Fred Hutchinson
>> Cancer Research Center http://bioconductor.org
>>
>> ___
>> [EMAIL PROTECTED] mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
MartinMo> -- Martin Morgan Bioconductor / Computational
MartinMo> Biology http://bioconductor.org
MartinMo> __
MartinMo> R-devel@r-project.org mailing list
MartinMo> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Merge (PR#9699)
Full_Name: Edward McNeil Version: 2.5.0 OS: Windows XP Submission from: (NULL) (203.170.234.5) This is a new bug introduced to R2.5.0. Scenario: If one of the data frames to merge contains two variables that have the same name, then the data in first variable (of the same name) is copied to the second variable in the resulting merged data frame. In R2.4.1, the second variable name is automatically renamed (in the resulting data frame) by adding ".1" to the end. R2.5.0 doesn't seem to do this anymore. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] When loading evir after evd, dgumbel gives an error (PR#9704)
Full_Name: Ronald van Nooijen Version: 1.4.1 and 1.5.0, evd 2.2-3 OS: windows xp Submission from: (NULL) (130.161.12.43) In an empty workspace first load package evd, then load package evir. a call to any of the routines dgumberl, qgumbel etcetera will now result in an error message of the form Error in qgev(p, loc = loc, scale = scale, shape = 0, lower.tail = lower.tail) : unused argument(s) (loc = 0, scale = 1, shape = 0, lower.tail = TRUE) (It seems that evir::dgev masks evd::dgev and that the different parameter names create a problem in the implementation of dgumbel) >From [EMAIL PROTECTED] Thu May 24 23:44:33 2007 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on hypatia.math.ethz.ch X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=FORGED_YAHOO_RCVD,NO_REAL_NAME autolearn=no version=3.1.8 Received: from slim.kubism.ku.dk (slim.kubism.ku.dk [192.38.18.21]) by hypatia.math.ethz.ch (8.13.6/8.13.6) with ESMTP id l4OLiW8s011180 for <[EMAIL PROTECTED]>; Thu, 24 May 2007 23:44:32 +0200 Received: from slim (slim.kubism.ku.dk [192.38.18.21]) by slim.kubism.ku.dk (Postfix) with ESMTP id 02AC4474B1 for <[EMAIL PROTECTED]>; Thu, 24 May 2007 23:44:31 +0200 (CEST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problem with mtrace(mvbutils) (PR#9709) Cc: [EMAIL PROTECTED] X-Loop: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 23:44:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new at stat.math.ethz.ch Full_Name: Andrew Zachary Version: 2.5.0 OS: XP SP2 Submission from: (NULL) (69.182.9.186) When using mtrace under R 2.5.0, I consistently get the error: Error in all.levs[[jj]]: Subscript out of bounds. The routine is currently unusable. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Merge (PR#9699)
On Mon, 21 May 2007, [EMAIL PROTECTED] wrote: > Full_Name: Edward McNeil > Version: 2.5.0 > OS: Windows XP > Submission from: (NULL) (203.170.234.5) > > > This is a new bug introduced to R2.5.0. > > Scenario: If one of the data frames to merge contains two variables that have > the same name, then the data in first variable (of the same name) is copied to > the second variable in the resulting merged data frame. This is probably o [i, j] could sometimes select the wrong column when j is numeric if there are duplicate column names. from NEWS and hence already fixed in R-patched. > In R2.4.1, the second variable name is automatically renamed (in the resulting > data frame) by adding ".1" to the end. R2.5.0 doesn't seem to do this anymore. This is not reproducible: A <- data.frame(x=1:3, y=4:6, y=7:9, check.names=FALSE) B <- data.frame(x=1:3, a=3:1) merge(A, B) works correctly in R-patched. You were asked for a reproducible example: if you have one in current R-patched, please supply it now (using PR#9699 early in your subject line). -- 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] When loading evir after evd, dgumbel gives an error (PR#9704)
Please do not - report on ancient versions of R. - use R-bugs for reports on contributed packages. It is hard to see why you think this is a bug, but you could ask the authors of the two packages to work together to avoid this (or add namespaces to protect the packages against this). On Wed, 23 May 2007, [EMAIL PROTECTED] wrote: > Full_Name: Ronald van Nooijen > Version: 1.4.1 and 1.5.0, evd 2.2-3 > OS: windows xp > Submission from: (NULL) (130.161.12.43) > > > In an empty workspace first load package evd, then load package evir. > a call to any of the routines dgumberl, qgumbel etcetera will now result in an > error message of the form > > Error in qgev(p, loc = loc, scale = scale, shape = 0, lower.tail = > lower.tail) : > >unused argument(s) (loc = 0, scale = 1, shape = 0, lower.tail = TRUE) > > (It seems that evir::dgev masks evd::dgev and that the different parameter > names > create a problem in the implementation of dgumbel) [part of another report deleted.] -- 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
[Rd] How to correctly write a package?
I am writing a package. Please, study the sequence of my actions below, and comment, what's incorrect. The package contains pure R code. 1. At the one level up from the package directory, from the system command prompt: R CMD build --binary ac9 This produces the file ac9_0.1.zip (The package name is ac9, and the package's DESCRIPTION file says its version is 0.1) 2. Then I run Rgui in the other directory and "Install package(s) from local zip files" 3. Issue the following commands in the command of Rgui from step 2 : library(ac9) [calls to functions from the package] 4. If I see errors, I quit Rgui from step 2, then change (hopefully) properly the source package code, and go to step 1. What would happen if I don't quit Rgui from the step 2? Would it reload the new function definitions? Is there any other methods to refine a packaged code, which experienced package writers use in their routine work? I have created package source using package.skeleton, and have documented the functions. Updating of the function body and re-use of the package.skeleton with force=TRUE overwrites the documentation files. This disallows often use of this function, or requires keeping the backup copy of the package sources. -- View this message in context: http://www.nabble.com/How-to-correctly-write-a-package--tf3828586.html#a10837938 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to correctly write a package?
Vladimir Eremeev wrote: > I am writing a package. > > Please, study the sequence of my actions below, and comment, what's > incorrect. > The package contains pure R code. > > 1. At the one level up from the package directory, from the system command > prompt: > R CMD build --binary ac9 > > This produces the file ac9_0.1.zip (The package name is ac9, and the > package's DESCRIPTION file says its version is 0.1) > > 2. Then I run Rgui in the other directory and "Install package(s) from local > zip files" I'd rather do a) R CMD build ac9 b) R CMD INSTALL ac9_01.tar.gz c) If a) and b) worked: R CMD check ac9_01.tar.gz > 3. Issue the following commands in the command of Rgui from step 2 : > > library(ac9) > [calls to functions from the package] > > 4. If I see errors, I quit Rgui from step 2, then change (hopefully) > properly the source package code, and > go to step 1. > > What would happen if I don't quit Rgui from the step 2? > Would it reload the new function definitions? Depends on some details on the package. In principle, you can detach() the package and load it later without closing R in the meantime. Of course, when closing R you are on the very safe side. > Is there any other methods to refine a packaged code, which experienced > package writers use in their routine work? Some of the "experienced package writers" probably use svn, cvs or some other version control system and so have the sources therein. They are simply updating the source code directly without using package.skeleton() after they once used it for a first skeleton of the package. Uwe Ligges > I have created package source using package.skeleton, and have documented > the functions. > Updating of the function body and re-use of the package.skeleton with > force=TRUE overwrites the documentation files. This disallows often use of > this function, or requires keeping the backup copy of the package sources. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Merge (PR#9699)
Yes, it appears to have been resolved in R2.5.0pat, although the
counter-example provided *does* fail in R2.5.0.
A <- data.frame(x=1:3, y=4:6, y=7:9, check.names=FALSE)
B <- data.frame(x=1:3, a=3:1)
A
x y y
1 1 4 7
2 2 5 8
3 3 6 9
B
x a
1 1 3
2 2 2
3 3 1
merge(A, B)
x y y.1 a
1 1 4 4 3
2 2 5 5 2
3 3 6 6 1
---
Prof Brian Ripley wrote:
> On Mon, 21 May 2007, [EMAIL PROTECTED] wrote:
>
>> Full_Name: Edward McNeil
>> Version: 2.5.0
>> OS: Windows XP
>> Submission from: (NULL) (203.170.234.5)
>>
>>
>> This is a new bug introduced to R2.5.0.
>>
>> Scenario: If one of the data frames to merge contains two variables
>> that have
>> the same name, then the data in first variable (of the same name) is
>> copied to
>> the second variable in the resulting merged data frame.
>
> This is probably
>
> o[i, j] could sometimes select the wrong column
> when j is numeric if there are duplicate column names.
>
> from NEWS and hence already fixed in R-patched.
>
>> In R2.4.1, the second variable name is automatically renamed (in the
>> resulting
>> data frame) by adding ".1" to the end. R2.5.0 doesn't seem to do this
>> anymore.
>
> This is not reproducible:
>
> A <- data.frame(x=1:3, y=4:6, y=7:9, check.names=FALSE)
> B <- data.frame(x=1:3, a=3:1)
> merge(A, B)
>
> works correctly in R-patched. You were asked for a reproducible
> example: if you have one in current R-patched, please supply it now
> (using PR#9699 early in your subject line).
>
>
--
This message has been scanned for viruses and\ dangerous con...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
