[Rd] Documentation bug in complex.Rd (PR#8218)
Dear all,
I noticed a documentation error in complex.Rd. A patch that corrects
the error is as follows:
[bossiaea:R-devel-src]$ svn diff
Index: src/library/base/man/complex.Rd
===
--- src/library/base/man/complex.Rd (revision 35935)
+++ src/library/base/man/complex.Rd (working copy)
@@ -52,7 +52,8 @@
complex values. Modulus and argument are also called the \emph{polar
coordinates}. If \eqn{z = x + i y} with real \eqn{x} and \eqn{y},
\code{Mod}\eqn{(z) = \sqrt{x^2 + y^2}}, and for
- \eqn{\phi= Arg(z)}, \eqn{x = \cos(\phi)} and \eqn{y = \sin(\phi)}.
+ \eqn{\phi= \code{Arg}(z)}, \eqn{x = \code{Mod}(z)\cos(\phi)} and
+ \eqn{y = \code{Mod}(z)\sin(\phi)}.
They are all generic functions: methods can be defined
for them individually or via the \code{\link{Complex}} group generic.
Cheers,
Berwin
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 2.0
year = 2005
month = 10
day = 06
svn rev = 35749
language = R
Locale:
C
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] can't start csh (scripts) (PR#8220)
Dear R developers,
after upgrading from R 2.1.1 to 2.2.0 I can't start csh (scripts) anymore.
While the following commands work fine
> system("tcsh -c pwd")
/hom1/users/gloeckler
> system("bash -c pwd")
/hom1/users/gloeckler
> system("ksh -c pwd")
/hom1/users/gloeckler
csh (in contrast to the shells used above) doesn't give any result:
> system("csh -c pwd")
>
Outside of R csh and csh scripts do not cause any problems.
I tracked down a problem with starting an HTML browser down to this
problem with the invocation of any csh process.
The csh used is the normal C-Shell shipped with Solaris 9.
Thanks in advance,
Jens Gloeckler
--please do not edit the information below--
Version:
platform = sparc-sun-solaris2.9
arch = sparc
os = solaris2.9
system = sparc, solaris2.9
status =
major = 2
minor = 2.0
year = 2005
month = 10
day = 06
svn rev = 35749
language = R
Locale:
C
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency with matrix indexing (PR#8214)
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Tue, 18 Oct 2005 09:50:59 -0400 writes:
Duncan> On 10/18/2005 9:32 AM, [EMAIL PROTECTED] wrote:
>> Dear Duncan,
>>
>> you are right. In both R 2.2.0 and 2.1.1 you get the same result. What
has
>> actually changed is the following:
>> In R 2.1.1
>>> mat[1, , drop = FALSE][1]
>> r1
>> 1
>>
>> While in R 2.2.0
>>> mat[1, , drop = FALSE][1]
>> [1] 1
Duncan> I don't agree with your suggestion. mat[1, , drop = FALSE]
Duncan> is a 1x3 matrix, with both row and column
Duncan> names. Indexing it by [1] says that you want to
Duncan> treat it as a vector, and give the first element.
Duncan> How could R know whether to keep the row or column
Duncan> name for that [1,1] element? What should it do with
Duncan> the expression
Duncan> mat[1,1 , drop = FALSE][1]
Duncan> ?
Duncan> If you are really concerned about the names, you should use matrix
Duncan> indexing in both places with drop = FALSE:
>> mat[1, , drop = FALSE][1,1,drop=FALSE]
Duncan> c1
Duncan> r1 1
Duncan> Duncan Murdoch
yes, definitely. There's no bug here, and there was rather a
bug in previous behavior.
Just a simpler example {"for posteriority"}:
> (M <- cbind(a=0:1, b=c(A=2, B=3)))
a b
A 0 2
B 1 3
> M[1,2, drop=FALSE]
b
A 2
> M[1,2]
[1] 2
> M[2] ### treat M as vector -> lose names
[1] 1
> M[2:3]
[1] 1 2
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] can't start csh (scripts) (PR#8220)
This works perfectly correctly in four separate configurations (32-/64-bit
x gcc/cc) on our Solaris 8, and I can see no change in the R sources for
do_system since Mar 2004.
Are you sure that it is not something in your build environment that has
changed since 2.1.1 was built?
Please confirm that if you build 2.1.1 and 2.2.0 with the same tools they
behave differently, and if so tell us what those tools are.
All R is doing here is to call the C system call and the output comes from
the shell directly to the terminal, without any intervention from R. You
might try a command that actually does something permanent to confirm that
csh is executing it: if that is the case the issue is how csh writes to
your terminal.
On Wed, 19 Oct 2005 [EMAIL PROTECTED] wrote:
> Dear R developers,
>
> after upgrading from R 2.1.1 to 2.2.0 I can't start csh (scripts) anymore.
>
> While the following commands work fine
>
> > system("tcsh -c pwd")
> /hom1/users/gloeckler
> > system("bash -c pwd")
> /hom1/users/gloeckler
> > system("ksh -c pwd")
> /hom1/users/gloeckler
>
> csh (in contrast to the shells used above) doesn't give any result:
>
> > system("csh -c pwd")
> >
>
> Outside of R csh and csh scripts do not cause any problems.
>
> I tracked down a problem with starting an HTML browser down to this
> problem with the invocation of any csh process.
>
> The csh used is the normal C-Shell shipped with Solaris 9.
>
> Thanks in advance,
> Jens Gloeckler
>
>
>
> --please do not edit the information below--
>
> Version:
> platform = sparc-sun-solaris2.9
> arch = sparc
> os = solaris2.9
> system = sparc, solaris2.9
> status =
> major = 2
> minor = 2.0
> year = 2005
> month = 10
> day = 06
> svn rev = 35749
> language = R
>
> Locale:
> C
>
> Search Path:
> .GlobalEnv, package:methods, package:stats, package:graphics,
> package:grDevices, package:utils, package:datasets, Autoloads, package:base
>
> __
> 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] [ subscripting sometimes loses names (PR#8192)
Andy,
that's interesting, but honestly your posting only *talked*
about your perceptions of bogous behavior of R and gave link to
a quite extensive S source file --- which re-defines basic
functions so it's not a file I'd just want to source into my R
session.
Proper R bug reports provide short "cut & paste" executable
example code {i.e. no prompt, no output} or at least the
transcript of such code {transcript : input (+ prompt) + output}.
Also your script is for R and S-plus and at least in some places
it seems you think R has a bug because it behaves differently
than S or S-plus.
Now I'm sure you know from the R-FAQ that there are quite a few
intentional differences between the two dialects of S,
and dealing with data frames is definitely one situation where
we have tried to do better than "the prototype", so we would say
the bug is with S(-plus).
In spite of all the above, I'd well expect that you still know
about problematic or even bogous behavior of "[" subscripting,
but we'd rather see small reproducible code snippets rather than
scripts that redefine "[" and "[.data.frame" and further assume
a patched all.equal()..
Best regards,
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Socks under R
Hi
when I use
con1 <- socketConnection(...)
in R and want to send text from another application written in Delphi to
R, do I just have to send the text or do I have to implement more
control characters and so on?
Is
con1 <- socketConnection(port=6011, server=TRUE)
writeLines("plot(rnorm(100))", con1)
just sending the text in "plot(rnorm(100))" to the socket or is it doing
more (R specific protocoll for socks comminication)?
Thanks,
Rainer
--
NEW TELEPHONE NUMBER
Tel:+27 - (0)72 808 2975 (w)
Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation
Biology (UCT)
Department of Conservation Ecology
University of Stellenbosch
Matieland 7602
South Africa
Tel:+27 - (0)72 808 2975 (w)
Fax:+27 - (0)21 808 3304
Cell: +27 - (0)83 9479 042
email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extending lattice to S4 classes
On 10/18/05, ernesto <[EMAIL PROTECTED]> wrote:
> Prof Brian Ripley wrote:
>
> > I think you are confusing us: xyplot is an S3 generic with no 'data'
> > argument. It is xyplot.formula that you want to add dispatch on its
> > 'data' argument. I don't really see why you want to mix S3 and S4
> > systems, but you could make xyplot.formula an S3 or S4 generic and
> > dispatch on 'data', just as you did earlier with xyplot.
> >
> > Other xyplot methods need not (and probably do not) have a 'data'
> > argument.
> >
> > On Fri, 14 Oct 2005, ernesto wrote:
> >
> >> ernesto wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm writing methods for a package called FLCore (see
> >>> http://flr-project.org/) in particular for a class called "FLQuant"
> >>> which extends array.
> >>>
> >>> Previously I was able to write methods based on the class of "data" but
> >>> now I can not do it due to the single parameter "x". Is there a way to
> >>> do this ?
> >>
> >
> >> I found an hack (see below) to make it work but it's terrible and hugly
> >> ... some suggestions are welcome. It simply tests if data belongs to
> >> class "FLQuant" and transforms it into a data.frame before ploting.
> >>
> >> Regards
> >>
> >> EJ
> >>
> >> if (!isGeneric("xyplot")) {
> >>setGeneric("xyplot", useAsDefault = xyplot)
> >> }
> >>
> >>
> >> setMethod("xyplot", signature("formula"), function(x, ...){
> >>
> >>dots <- list(...)
> >>if(class(dots$data)=="FLQuant") dots$data <- as.data.frame(dots$data)
> >>call.list <- c(x = x, dots)
> >>
> >> # needed this to avoid an infinite loop because xyplot is defined only
> >> for "x"
> >>xyplot <- lattice::xyplot
> >>ans <- do.call("xyplot", call.list)
> >>ans$call <- match.call()
> >>ans
> >>
> >> })
> >
> >
>
> Hi,
>
> Sorry to get back to this problem so late.
>
> I want to use lattice plots for an array. In this specific case this
> array is of class FLQuant which is defined by package FLCore.
>
> This array has 5 dimensions age, year, unit, season and area. My aim is
> to use formula to define what to plot and what to condition on. So
> procedures like used for barchart.table are not usefull for me because
> the user loses the option of defining the model to plot.
>
> With the previous version of lattice I was able to use formula and data
> to dispatch. So I defined S4 generic methods for most high level methods
> (bwplot, stripplot, dotplot, xyplot, histogram, etc) and simply
> transform FLQuant objects into dataframes that were passed to the
> lattice methods. No harm done to other data objects.
>
> With the new version only one object is available for dispatching "x" so
> if I define some xyplot.FLQuant I will miss the formula argument.
>
> My question is if there is a way of doing this or not.
Prof Ripley gave you one (redefine xyplot.formula etc). You could
always add new arguments to your methods, so you could have (the S4
equivalent of)
xyplot.FLQuant <- function(x, formula, ...)
{
xyplot(formula, data = as(x, "data.frame"), ...)
}
and then call
xyplot(flq.obj, formula = y ~ x, [...])
The cleanest solution would be to have a data argument in the xyplot
generic (with the expectation that it could be non-missing only for
methods where x is a formula). I'll try to implement that and see if
it causes any problems.
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ subscripting sometimes loses names (PR#8192)
On Wed, Oct 19, 2005 at 02:33:50PM +0200, Martin Maechler wrote:
> Proper R bug reports provide short "cut & paste" executable
> example code {i.e. no prompt, no output} or at least the
> transcript of such code {transcript : input (+ prompt) + output}.
My patch includes the function dtk.test.brace.names() which
demonstrates the problem. If you source just that function into a
completely stock R, you can see the losing names problem by running:
dtk.test.brace.names(return.results.p=T ,only="all")
To make it easier to see just what the problem is, I'll send example
output in my next email.
> Also your script is for R and S-plus and at least in some places
> it seems you think R has a bug because it behaves differently
> than S or S-plus.
No, I don't think that. If comments in my code give that impression
then that's a bug in my comments, it was not my intention.
My coworkers and I originally fixed the name losing problem in S-Plus,
then later did so in R, so in some places I might have sloppily said,
"R is different than S-Plus" when what I REALLY meant was, "Stock R is
different than our fixed/patched S-Plus where we've already solved
these name-losing problems."
Stock S-Plus and R both suffer from losing names when they shouldn't.
Since I use both dialects, I've included (ugly) fixes for both. Of
course you probably only care about the R part, but I didn't think it
would hurt to include both.
> Now I'm sure you know from the R-FAQ that there are quite a few
> intentional differences between the two dialects of S,
Yes, I'm aware of that FAQ. I also just finished porting a large body
of code from S-Plus to R a few months ago, so I have a very concrete
appreciation of the MANY little S-Plus vs. R differences, many more
than are mentioned in that FAQ.
Some of those differences are simply arbitrary or accidental, but
others are places where S-Plus was basically doing something dumb and
the R behavior is better. I have no complaints about this. :)
(The converse, where R's behavior is definitely inferior to that of
S-Plus, seems to be a lot less common, and are usually more minor.)
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ subscripting sometimes loses names (PR#8192)
Here is an example of the losing names problem in stock R 2.2.0. Note that below, only stock R packages are loaded, and then I manually source in just my dtk.test.brace.names() testing function, nothing else. Since the list-of-lists output of dtk.test.brace.names() is very lengthy, I've manually cut-and-pasted it into a tabular format to save space and make inspection easier. As you can see, out of its 15 test cases, stock R 2.2.0 fails 4 of them while the other 12 are Ok. Too see what these simple subscripting tests actually DO, please refer to the body of dtk.test.brace.names() from my previous emails above. R : Copyright 2005, The R Foundation for Statistical Computing Version 2.2.0 (2005-10-06 r35749) > search() [1] ".GlobalEnv""package:methods" "package:graphics" [4] "package:grDevices" "package:datasets" "package:utils" [7] "package:stats" "Autoloads" "package:base" > dtk.test.brace.names(return.results.p=T ,only="all") Ok? Actual Result Desired Result --- ---- $vec.1 BAD $vec.1[[1]] $vec.1[[2]] ac a c no 13 NA 1 3 NA $diag.1 Ok $diag.1[[1]] $diag.1[[2]] [1] 1 7 13 19 25[1] 1 7 13 19 25 $diag.2 Ok $diag.2[[1]] $diag.2[[2]] [1] 1 7 13 19 25[1] 1 7 13 19 25 $df.a.1 Ok $df.a.1[[1]] $df.a.1[[2]] a b a b 4 5 4 5 $df.b.1 BAD $df.b.1[[1]] $df.b.1[[2]] [1] 4 5 a b 4 5 $df.a.2 Ok $df.a.2[[1]] $df.a.2[[2]] c b a c b a 6 5 4 6 5 4 $df.b.2 BAD $df.b.2[[1]] $df.b.2[[2]] [1] 6 5 4 c b a 6 5 4 $df.a.3 Ok $df.a.3[[1]] $df.a.3[[2]] a b a b 3 4 3 4 $df.b.3 BAD $df.b.3[[1]] $df.b.3[[2]] [1] 3 4 a b 3 4 $df.a.4 Ok $df.a.4[[1]] $df.a.4[[2]] col1 col2 col1 col2 2424 $df.b.4 Ok $df.b.4[[1]] $df.b.4[[2]] col1 col2 col1 col2 b24 b24 $df.a.5 Ok $df.a.5[[1]] $df.a.5[[2]] col1 col2 col1 col2 2424 $df.b.5 Ok $df.b.5[[1]] $df.b.5[[2]] $df.b.5[[1]]$col1 $df.b.5[[2]]$col1 [1] 2 [1] 2 $df.b.5[[1]]$col2 $df.b.5[[2]]$col2 [1] 4 [1] 4 $df.a.6 Ok $df.a.6[[1]] $df.a.6[[2]] col1 col2 col1 col2 b24 b24 $df.b.6 Ok $df.b.6[[1]] $df.b.6[[2]] col1 col2 col1 col2 b24 b24 -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Socks under R
Rainer,
On Oct 19, 2005, at 3:29 PM, Rainer M. Krug wrote:
> when I use
>
> con1 <- socketConnection(...)
>
> in R and want to send text from another application written in
> Delphi to R, do I just have to send the text or do I have to
> implement more control characters and so on?
Sockets are just reliable bi-directional communication channels (in
the default mode), so their use is entirely up to you (both on R side
and other application's side).
> Is
>
> con1 <- socketConnection(port=6011, server=TRUE)
> writeLines("plot(rnorm(100))", con1)
>
> just sending the text in "plot(rnorm(100))" to the socket or is it
> doing more (R specific protocoll for socks comminication)?
It basically equivalent to using "send" on the socket API level [i.e.
the above effectively does send(s, "plot(rnorm(100))\n", 17, 0)], so
it's up to the other side to receive it properly. There is no "R
specific protocol" - socket connections in R use regular TCP (neither
red nor white "socks" ;)), so the literature on socket programming is
your friend (e.g. using readLines(con1) for incoming traffic in your
example would be a bad idea).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] spaces in application name of external editor (PR#8221)
Full_Name: Franklin Parlamis Version: 2.1.1 (R.app 1.1.2) OS: Mac OS X 10.4.2 Submission from: (NULL) (24.161.129.74) Cocoa GUI 1.12 appears to have a problem opening an external editor when the application name contains a space. I use Aquamacs Emacs, which upon installation names itself "Aquamacs Emacs.app" Choosing that app as an external editor on the Preference Pane causes the following error when I try to open a file from the Toolbar in the R Console: 2005-10-18 00:59:49.985 open[9985] No such file: /Users/Franklin/R/Working Directory/Emacs.app However, if I rename the application "Aquamacs_Emacs.app" no error is returned and the file opens. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
If you're looking for a GUI toolkit that: 1. Is cross-platform, 2. Has a good collection of widgets that look good on all platforms, and 3. Is easy to work with from R then it is hopeless. There is no such toolkit. As one poster mentioned, most of the better GUI toolkits are very object-oriented, because that paradigm is a good fit for GUI programming. There are a few programming environments out there that do have nice GUI abilities, but they all use base languages that are not very R-like, and so the potential R GUI programmer is faced with having to use two very different languages for his creation. And even if that obstacle is surmounted, there remains the difficulty of trying to package up his work in such a way as to make it easily installed by others. Things are always breaking in the interfaces between R and whatever you're using. Trying to keep it all running and packaging it for deployment are thankless, gargantuan tasks. There is a better way, and that is to give up on R. Start over with a better programming environment, one that is object oriented, as flexible and dynamic as R, is cross platform, easy to program in, and has decent GUI facilities already. Then port the stuff in R that does statistical programming, and you have the best of all worlds. The environment I am thinking about is VisualWorks Smalltalk, which is free for noncommercial use. As a language, Smalltalk is both simpler and more powerful than R, and the VM it runs on is much faster than the R interpreter. It has superior garbage collection and the best IDE in the business. Callouts to C are just as easy as they are in R, but would likely not be needed as often due to the faster VM and much better programming facilities. Interfaces to various databases are possible, and the most powerful web toolkit (Seaside) is written in Smalltalk and runs under VisualWorks. There are a couple of other Smalltalk environments around that could also be considered. Squeak is an open source cross-platform Smalltalk that is not as fast as VisualWorks, but still must faster and more robust than the R interpreter. Smalltalk/X is another possibility, though it works only on Windows and Unix. Think about it. Once you have a basic math package that can handle matrix programming and various mathematical functions, building the various statistical modeling tools on top of them is not that hard. What makes S and R so much better than SAS is their programmability. Smalltalk is like that, only better. Jeff Hallman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Ah. Let the language wars begin. Although I agree that going with R is basically a sad mistake http://www.jstatsoft.org/index.php?vol=13 giving up on R/S is no longer an option, I hope. Too much investment from the community. Reculer pour mieux sauter, indeed. On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: > If you're looking for a GUI toolkit that: > >1. Is cross-platform, >2. Has a good collection of widgets that look good on all > platforms, and >3. Is easy to work with from R > > then it is hopeless. There is no such toolkit. > > As one poster mentioned, most of the better GUI toolkits are very > object-oriented, because that paradigm is a good fit for GUI > programming. > There are a few programming environments out there that do have > nice GUI > abilities, but they all use base languages that are not very R- > like, and so > the potential R GUI programmer is faced with having to use two very > different > languages for his creation. And even if that obstacle is > surmounted, there > remains the difficulty of trying to package up his work in such a > way as to > make it easily installed by others. Things are always breaking in the > interfaces between R and whatever you're using. Trying to keep it > all running > and packaging it for deployment are thankless, gargantuan tasks. > > There is a better way, and that is to give up on R. Start over with > a better programming environment, one that is object oriented, as > flexible and > dynamic as R, is cross platform, easy to program in, and has decent > GUI > facilities already. Then port the stuff in R that does statistical > programming, and you have the best of all worlds. > > The environment I am thinking about is VisualWorks Smalltalk, which > is free > for noncommercial use. As a language, Smalltalk is both simpler > and more > powerful than R, and the VM it runs on is much faster than the R > interpreter. > It has superior garbage collection and the best IDE in the business. > Callouts to C are just as easy as they are in R, but would likely > not be > needed as often due to the faster VM and much better programming > facilities. > Interfaces to various databases are possible, and the most powerful > web > toolkit (Seaside) is written in Smalltalk and runs under VisualWorks. > > There are a couple of other Smalltalk environments around that > could also be > considered. Squeak is an open source cross-platform Smalltalk that > is not as > fast as VisualWorks, but still must faster and more robust than the R > interpreter. Smalltalk/X is another possibility, though it works > only on > Windows and Unix. > > Think about it. Once you have a basic math package that can handle > matrix > programming and various mathematical functions, building the various > statistical modeling tools on top of them is not that hard. What > makes S and > R so much better than SAS is their programmability. Smalltalk is > like that, > only better. > > > Jeff Hallman > > __ > 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] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
> "K" == Kasper Daniel Hansen <[EMAIL PROTECTED]> writes: K> On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: K> >> Think about it. Once you have a basic math package that can handle >> matrix >> programming and various mathematical functions, building the various >> statistical modeling tools on top of them is not that hard. What >> makes S and >> R so much better than SAS is their programmability. Smalltalk is >> like that, >> only better. >> >> >> Jeff Hallman K> I would claim that this quote kind of shows that you have no idea K> what you are talking about regarding good, debugged and trustworthy K> statistical procedures. Why do you think people are actually using R? Kasper, a few minutes spent Googling my name should disabuse you of the notion that I have no idea of what I'm talking about. But to answer your question: I think people are using R because it's readily available, with a lot of good stuff already built in. I am not suggesting that you tell undergraduate statistics students to write everything in Smalltalk, since the class libraries to support statistical programming in Smalltalk do not exist yet. What I am saying is that if you compare the languages themselves, along with their programming environments, Smalltalk is superior to R. What it lacks are class libraries implementing statistical procedures. I do maintain that those really are not that hard, once you have the matrix and math libraries. My experience with S and R goes way back to the days of blue book S version 3. S called out to C code to handle matrix and mathmetical stuff, but used S code itself to glue it all together in a somewhat object-oriented way. K> I could say "well, given an environment that could interface to C, K> building a GUI on top of that is not really that hard", but that K> would be incredible naive as well. Indeed it would be. But statistical programming is easier than that. Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is.na<- problem
In the following the first element of xx should have been set to 0 but remains NA. Any comments? > xx <- c(NA,1) > is.na(xx) <- 0 > xx [1] NA 1 > R.version.string # Windows XP [1] "R version 2.2.0, 2005-09-20" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
> On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: > > There is a better way, and that is to give up on R. Start > > over with a better programming environment, one that is > > object oriented, as flexible and dynamic as R, is cross > > platform, easy to program in, and has decent GUI facilities > > already. Then port the stuff in R that does statistical > > programming, and you have the best of all worlds. > > > > The environment I am thinking about is VisualWorks > > Smalltalk, which is free for noncommercial use. As a > > language, Smalltalk is both simpler and more powerful than > > R, and the VM it runs on is much faster than the R > > interpreter. It has superior garbage collection and the best > > IDE in the business. Callouts to C are just as easy as they > > are in R, but would likely not be needed as often due to the > > faster VM and much better programming facilities. Interfaces > > to various databases are possible, and the most powerful web > > toolkit (Seaside) is written in Smalltalk and runs under > > VisualWorks. My advice about VisualWorks Smalltalk: don't. It may work well on Windows. On Linux, it is a disaster. Nothing works the way it is supposed to on Linux. I have tried one application in VisualWorks: BottomFeeder. Dozens of versions and bug fixed. But there are no fixed for the incompatibility between the virtual machine and my Linux box. It can't display jpeg's. Windows keep jumping around the screen. It doesn't know about size of fonts, so on many parts of the interface, parts of text are missing. Standard key combinations, copy and paste, all work completely different from other Linux applications. You can't install the program in the Unix way. It saves its internal state in a binary form that gets being corrupted, and you have to make a clean install regularly, loosing all your old data. Mind you, this is software developed by someone from VisualWorks, presenting this as the prize horse of what VisualWorks is capable of. > > There are a couple of other Smalltalk environments around > > that could also be considered. Squeak is an open source > > cross-platform Smalltalk that is not as fast as VisualWorks, > > but still must faster and more robust than the R > > interpreter. Smalltalk/X is another possibility, though it > > works only on Windows and Unix. Squeak works much better on Linux than VisualWorks, but it still shares many disadvantages with VisualWorks. The main obstacle is its use of a virtual machine for everything. It is like working in a completely different environment, were none of the rules of your usual environment apply. You cannot use your favourite software to do your programming and organising. I write programs in Python, C, PostScript, R, and half a dozen other regularly, all from Emacs. If I want to program VisualWorks or Squeak, I have to do so from within VisualWorks or Squeak, with its own editor. I can use none of the tools I rely on for all my other tasks. And of course, something written in VisualWorks is completely useless in Squeak, and vice versa. > > Think about it. Once you have a basic math package that can > > handle matrix programming and various mathematical > > functions, building the various statistical modeling tools > > on top of them is not that hard. What makes S and R so much > > better than SAS is their programmability. Smalltalk is like > > that, only better. No. A program should respect the user's chose of platform. I write a program in Python with Tk. On Linux it looks and feels like a Linux program. On Windows, it looks and feels like a Windows program. Why would you want a GUI for something like R in the first place? It is a programming language. That is its force. Nothing beats the command line. A GUI can never offer the same power, unless it offers the same openness as the OS it is running on. It has to incorporate an editor to do the programming. Except without the GUI, I can use any editor I like. I don't need a GUI. Linux running X and my favourite windows manager is all the GUI I need. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.na<- problem
On 19-Oct-05 Gabor Grothendieck wrote: > In the following the first element of xx should have > been set to 0 but remains NA. Any comments? > >> xx <- c(NA,1) >> is.na(xx) <- 0 >> xx > [1] NA 1 >> R.version.string # Windows XP > [1] "R version 2.2.0, 2005-09-20" I wonder, has it ever worked? I get the same as you on R.version.string #Linux [1] "R version 1.6.2, 2003-01-10" R.version.string #Linux [1] "R version 1.8.0, 2003-10-08" R.version.string #Linux [1] "R version 2.1.0, 2005-04-08" with the exception of R.version.string #Linux [1] "R version 1.2.3, 2001-04-26" which does know about is.na()<- at all. Hmmm Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 20-Oct-05 Time: 01:11:45 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.na<- problem
Hi, It does seem to be working as advertised, but not particulary intuitively. From ?is.na The generic function 'is.na<-' sets elements to 'NA' In fact: xx <- c(NA, 1) is.na(xx) <- 2 xx [1] NA NA or is.na(xx) <- 5 [1] NA 1 NA NA NA Looks like this was introduced in 1.4.0; from NEWS: o New generic function is.na<-(), from S4. This is by default equivalent to x[value] <- NA but may differ, e.g. for factors where "NA" is a level. Cheers, Rich On 10/20/05, Ted Harding <[EMAIL PROTECTED]> wrote: > On 19-Oct-05 Gabor Grothendieck wrote: > > In the following the first element of xx should have > > been set to 0 but remains NA. Any comments? > > > >> xx <- c(NA,1) > >> is.na(xx) <- 0 > >> xx > > [1] NA 1 > >> R.version.string # Windows XP > > [1] "R version 2.2.0, 2005-09-20" > > I wonder, has it ever worked? I get the same as you on > > R.version.string #Linux > [1] "R version 1.6.2, 2003-01-10" > > R.version.string #Linux > [1] "R version 1.8.0, 2003-10-08" > > R.version.string #Linux > [1] "R version 2.1.0, 2005-04-08" > > with the exception of > > R.version.string #Linux > [1] "R version 1.2.3, 2001-04-26" > > which does know about is.na()<- at all. > > > Hmmm > Ted. > > > > > > > > E-Mail: (Ted Harding) <[EMAIL PROTECTED]> > Fax-to-email: +44 (0)870 094 0861 > Date: 20-Oct-05 Time: 01:11:45 > -- XFMail -- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Rich FitzJohn rich.fitzjohn gmail.com |http://homepages.paradise.net.nz/richa183 You are in a maze of twisty little functions, all alike __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.na<- problem
On Thu, 2005-10-20 at 01:13 +0100, Ted Harding wrote: > On 19-Oct-05 Gabor Grothendieck wrote: > > In the following the first element of xx should have > > been set to 0 but remains NA. Any comments? > > > >> xx <- c(NA,1) > >> is.na(xx) <- 0 > >> xx > > [1] NA 1 > >> R.version.string # Windows XP > > [1] "R version 2.2.0, 2005-09-20" > > I wonder, has it ever worked? I get the same as you on > > R.version.string #Linux > [1] "R version 1.6.2, 2003-01-10" > > R.version.string #Linux > [1] "R version 1.8.0, 2003-10-08" > > R.version.string #Linux > [1] "R version 2.1.0, 2005-04-08" > > with the exception of > > R.version.string #Linux > [1] "R version 1.2.3, 2001-04-26" > > which does know about is.na()<- at all. > > > Hmmm > Ted. According to the documentation in ?is.na: The generic function is.na<- sets elements to NA. and in the details section: Function is.na<- may provide a safer way to set missingness. It behaves differently for factors, for example. In reviewing the Green Book on the top of page 143, it shows an example in which the RHS of the assignment are the indices into the LHS object which are to be set to NA. For example: > xx <- c(0:5) > xx [1] 0 1 2 3 4 5 > is.na(xx) <- c(3, 4) > xx [1] 0 1 NA NA 4 5 Thus, back to Gabor's example, the proper approach would of course be: > xx <- c(NA,1) > xx [1] NA 1 > xx[is.na(xx)] <- 0 > xx [1] 0 1 HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.na<- problem
On 10/19/05, Marc Schwartz <[EMAIL PROTECTED]> wrote: > On Thu, 2005-10-20 at 01:13 +0100, Ted Harding wrote: > > On 19-Oct-05 Gabor Grothendieck wrote: > > > In the following the first element of xx should have > > > been set to 0 but remains NA. Any comments? > > > > > >> xx <- c(NA,1) > > >> is.na(xx) <- 0 > > >> xx > > > [1] NA 1 > > >> R.version.string # Windows XP > > > [1] "R version 2.2.0, 2005-09-20" > > > > I wonder, has it ever worked? I get the same as you on > > > > R.version.string #Linux > > [1] "R version 1.6.2, 2003-01-10" > > > > R.version.string #Linux > > [1] "R version 1.8.0, 2003-10-08" > > > > R.version.string #Linux > > [1] "R version 2.1.0, 2005-04-08" > > > > with the exception of > > > > R.version.string #Linux > > [1] "R version 1.2.3, 2001-04-26" > > > > which does know about is.na()<- at all. > > > > > > Hmmm > > Ted. > > According to the documentation in ?is.na: > > The generic function is.na<- sets elements to NA. > > and in the details section: > > Function is.na<- may provide a safer way to set missingness. It behaves > differently for factors, for example. > > > In reviewing the Green Book on the top of page 143, it shows an example > in which the RHS of the assignment are the indices into the LHS object > which are to be set to NA. For example: > > > xx <- c(0:5) > > > xx > [1] 0 1 2 3 4 5 > > > is.na(xx) <- c(3, 4) > > > xx > [1] 0 1 NA NA 4 5 > > > Thus, back to Gabor's example, the proper approach would of course be: > > > xx <- c(NA,1) > > > xx > [1] NA 1 > > > xx[is.na(xx)] <- 0 > > > xx > [1] 0 1 > > > HTH, > > Marc Schwartz > > > Thanks. I actually had read ?is.na but obviously not closely enough. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.na<- problem
On Wed, 2005-10-19 at 21:09 -0400, Gabor Grothendieck wrote: > On 10/19/05, Marc Schwartz <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-10-20 at 01:13 +0100, Ted Harding wrote: > > > On 19-Oct-05 Gabor Grothendieck wrote: > > > > In the following the first element of xx should have > > > > been set to 0 but remains NA. Any comments? > > > > > > > >> xx <- c(NA,1) > > > >> is.na(xx) <- 0 > > > >> xx > > > > [1] NA 1 > > > >> R.version.string # Windows XP > > > > [1] "R version 2.2.0, 2005-09-20" > > > > > > I wonder, has it ever worked? I get the same as you on > > > > > > R.version.string #Linux > > > [1] "R version 1.6.2, 2003-01-10" > > > > > > R.version.string #Linux > > > [1] "R version 1.8.0, 2003-10-08" > > > > > > R.version.string #Linux > > > [1] "R version 2.1.0, 2005-04-08" > > > > > > with the exception of > > > > > > R.version.string #Linux > > > [1] "R version 1.2.3, 2001-04-26" > > > > > > which does know about is.na()<- at all. > > > > > > > > > Hmmm > > > Ted. > > > > According to the documentation in ?is.na: > > > > The generic function is.na<- sets elements to NA. > > > > and in the details section: > > > > Function is.na<- may provide a safer way to set missingness. It behaves > > differently for factors, for example. > > > > > > In reviewing the Green Book on the top of page 143, it shows an example > > in which the RHS of the assignment are the indices into the LHS object > > which are to be set to NA. For example: > > > > > xx <- c(0:5) > > > > > xx > > [1] 0 1 2 3 4 5 > > > > > is.na(xx) <- c(3, 4) > > > > > xx > > [1] 0 1 NA NA 4 5 > > > > > > Thus, back to Gabor's example, the proper approach would of course be: > > > > > xx <- c(NA,1) > > > > > xx > > [1] NA 1 > > > > > xx[is.na(xx)] <- 0 > > > > > xx > > [1] 0 1 > > > > > > HTH, > > > > Marc Schwartz > > > > > > > > > Thanks. I actually had read ?is.na but obviously not closely enough. Happy to help. In all honesty, while I understood the concept from reading the help page, it was not truly clear until I read the Green Book and saw the example as to how to actually use the function. It would probably be worthwhile to add an example of use to the help page. Best regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
And I so wanted to stay out of this particular discussion, I hope you're proud of what you've done. *cracks knuckles* Right, lets get to it then. On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: > If you're looking for a GUI toolkit that: > >1. Is cross-platform, >2. Has a good collection of widgets that look good on all > platforms, and >3. Is easy to work with from R > > then it is hopeless. There is no such toolkit. There is in fact such a toolkit. I'll give you a hint, its name ends in "step" and its heavily used under a different name by a company named after a fruit. It works quite well from R, doesn't require another language and frankly the binding between it and R was actually pretty pleasant as these things go. By my count it took 2727 lines of C and 411 lines of R to bind, a good half of which are technically unnecessary. Right now it probably doesn't run under Windows and Linux/BSD/Solaris/Your Favorite POSIX Compliant UNIX at the present time, but thats mostly because I don't care rather than because it can't. > > As one poster mentioned, most of the better GUI toolkits are very > object-oriented, because that paradigm is a good fit for GUI > programming. > There are a few programming environments out there that do have > nice GUI > abilities, but they all use base languages that are not very R- > like, and so > the potential R GUI programmer is faced with having to use two very > different > languages for his creation. And even if that obstacle is > surmounted, there This is only a problem because people seem to insist on using R's object system in a way that is not actually very compatible with R's. To misquote Robert at DSC, "their primary complaint about R is that its not Java." If you think about it for a moment, R's environment is actually quite well suited to GUI tasks because, well, because it has environments. Imagine drawing into a window (you're a plotting tool or something). Really, you're a function executing in an environment (oh ho!) that has access to certain system resources, in this case a canvas of a certain physical and logical dimension. Responding to events could take on a similar structure---you're really executing in an Event environment that has certain bound symbols. Obviously you get to keep your lexical environment so event handlers that need to share state can in the usual way. Its not particularly difficult and doesn't even need to involve objects in any real way, except as little stubby things with attributes you can modify or poll. > remains the difficulty of trying to package up his work in such a > way as to > make it easily installed by others. Things are always breaking in the > interfaces between R and whatever you're using. Trying to keep it > all running > and packaging it for deployment are thankless, gargantuan tasks. How is this different than releasing any piece of software? > > There is a better way, and that is to give up on R. Start over with > a better programming environment, one that is object oriented, as > flexible and > dynamic as R, is cross platform, easy to program in, and has decent > GUI > facilities already. Then port the stuff in R that does statistical > programming, and you have the best of all worlds. > > The environment I am thinking about is VisualWorks Smalltalk, which > is free > for noncommercial use. As a language, Smalltalk is both simpler > and more Did you just use the words "cross platform" and "VisualWorks Smallktalk" in the same email? Have you ever used VisualWorks on something other than Win32? I'd rather use Squeak. At least then I know it'll have an equally childish interface on every platform. > powerful than R, and the VM it runs on is much faster than the R > interpreter. Contrary to popular belief the speed of R's interpreter is rarely the limiting factor to R's speed. People treating R like C is typically the limiting factor. You have vector operations, USE THEM. > It has superior garbage collection and the best IDE in the business. > Callouts to C are just as easy as they are in R, but would likely > not be > needed as often due to the faster VM and much better programming > facilities. But not portable across Smalltalks. Whoops. Oh, and there's still a helluva lot of Fortran code out there that nobody wants to port. > Interfaces to various databases are possible, and the most powerful > web > toolkit (Seaside) is written in Smalltalk and runs under VisualWorks. Because I spend all my time writing web shopping carts in R? > > There are a couple of other Smalltalk environments around that > could also be > considered. Squeak is an open source cross-platform Smalltalk that > is not as > fast as VisualWorks, but still must faster and more robust than the R > interpreter. Smalltalk/X is another possibility, though it works > only on > Windows and Unix. > > Think about it.
Re: [Rd] cross-compiling tools
I have been told (off-list) that cross-compiling c++ no longer works. Because of this, the c++ stuff is left out from the new tar ball. And I have also been corrected: most of the work on the cross- compiling tools were in fact done by Brian Ripley. Kasper On Oct 18, 2005, at 10:45 AM, A.J. Rossini wrote: > Technically, "Jun Yan, based on work and documentation most likely by > Brian Ripley, with Tony prodding Jun". Though I'm sure even that > would be corrected. > > Sorry, no clue, as I'm not using R nor Linux at work these days. I'm > sure someone else knows. > > On 10/18/05, Kasper Daniel Hansen <[EMAIL PROTECTED]> wrote: > >> Hi >> >> We have been cross-compiling windows packages under Linux using the >> excellent Makefile and instructions by Tony Rossini and Jun Yan. >> Specifically we have been cross-compiling c++ code and it used to >> work. >> >> Now the minGW tools located at www.stats.ox.ac.uk/pub/Rtools have >> changed from version 4 to version 5, and our cross-compiling have >> stopped working. >> >> Inspecting the tarball we are unable to find the header files for c+ >> +, so it seems that c++ support has been left out. Has this been >> changed intentionally, because it used to work and in addition c++ is >> included in the list of "standard" minGW packages listed on >> www.murdoch-sutherland.com/Rtools >> >> If the change is intentionally, should be just get the c++ code from >> minGW and merge it into the tarball? >> >> Kasper and Jim >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > > -- > best, > -tony > > [EMAIL PROTECTED] > Muttenz, Switzerland. > "Commit early,commit often, and commit in a repository from which > we can easily > roll-back your mistakes" (AJR, 4Jan05). > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Hi Peter and everyone, [Hmmm, didn't I say I was not really interested in spending time getting into these discussions anymore? Oh well, I can't help myself. ;-) ] > Why would you want a GUI for something like R in the first > place? It is a programming language. That is its force. Nothing > beats the command line. I think there are many people who would strongly disagree with your suggestion that there is no point in developing GUIs for R. But there is also some ambiguity about what is meant by a GUI - an Interactive Development Environment (IDE) for developers or a GUI for users who are highly intelligent, but have no interest whatsoever in ever learning how to use a command-line interface, whilst still wanting to access some of the functionality in R/Bioconductor. Some statisticians / numerical computing specialists work in isolation and like to advertise that some of their work is very "applied" e.g. they are working on a project which will save the world or cure cancer or whatever [sorry for the exaggeration] but this is a natural way for them to market the importance of their field of research and feel good about themselves. On the otherhand, there are people like the bioinformatics group I work in who are a very successful research group, partly because we don't work in isolation. Instead we collaborate very closely with scientists from other fields (i.e. biomedical scientists), but there is an extreme danger here of being used as a service group (like I.T. support) by the biomedical scientists who don't appreciate how much work is involved in computer programming, statistics etc. So one solution is to use a language like R, with the philosophy "users become developers", i.e. rather than having to learn an intimidating hierarchy of 100's of classes in some object oriented language [OK, I'm exaggerating here], the user can begin using R quite gently (but still do some powerful statistical calculations) and then gradually become more advanced. Now some of the (extremely intelligent) biologists we collaborate with are very fearful of getting started in a command-line interface, so they keep asking us to do mundane things for them which are not going to lead to any research publications for us - i.e. we feel like we are just being used as I.T. support. So by providing a GUI to them, getting started in R is less intimidating for them, so then we can hopefully spend less time doing mundane numerical computing tasks for our collaborators and have more time to do our own serious research. And we can even publish our work on developing GUIs which we have - just a short article in Bioinformatics OUP so far - and John Fox has published a full-length article on Rcmdr in the Journal of Statistical Software - great stuff! Does that make sense? James __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cross-compiling tools
Though thanks to the obtuseness of the documentation, the makefile Jun wrote has helped a great deal of folks. While some have been appreciative, certain other folks have only bothered to make snide, hostile remarks and not bothered to be polite enough to suggest changes that might have prevented questions arising, as they prefer to demonstrate to the world that no one else can improve on their "satisfactory" work. On 10/20/05, Kasper Daniel Hansen <[EMAIL PROTECTED]> wrote: > I have been told (off-list) that cross-compiling c++ no longer works. > Because of this, the c++ stuff is left out from the new tar ball. > > And I have also been corrected: most of the work on the cross- > compiling tools were in fact done by Brian Ripley. > > Kasper > > On Oct 18, 2005, at 10:45 AM, A.J. Rossini wrote: > > > Technically, "Jun Yan, based on work and documentation most likely by > > Brian Ripley, with Tony prodding Jun". Though I'm sure even that > > would be corrected. > > > > Sorry, no clue, as I'm not using R nor Linux at work these days. I'm > > sure someone else knows. > > > > On 10/18/05, Kasper Daniel Hansen <[EMAIL PROTECTED]> wrote: > > > >> Hi > >> > >> We have been cross-compiling windows packages under Linux using the > >> excellent Makefile and instructions by Tony Rossini and Jun Yan. > >> Specifically we have been cross-compiling c++ code and it used to > >> work. > >> > >> Now the minGW tools located at www.stats.ox.ac.uk/pub/Rtools have > >> changed from version 4 to version 5, and our cross-compiling have > >> stopped working. > >> > >> Inspecting the tarball we are unable to find the header files for c+ > >> +, so it seems that c++ support has been left out. Has this been > >> changed intentionally, because it used to work and in addition c++ is > >> included in the list of "standard" minGW packages listed on > >> www.murdoch-sutherland.com/Rtools > >> > >> If the change is intentionally, should be just get the c++ code from > >> minGW and merge it into the tarball? > >> > >> Kasper and Jim > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > > > > > -- > > best, > > -tony > > > > [EMAIL PROTECTED] > > Muttenz, Switzerland. > > "Commit early,commit often, and commit in a repository from which > > we can easily > > roll-back your mistakes" (AJR, 4Jan05). > > > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] numerical issues in chisq.test(simulate=TRUE) (PR#8224)
Hi, This report deals with p-values coming from chisq.test using the simulate.p=TRUE option. The issue is numerical accuracy and was brought up in previous bug reports 3486 and 3896. The bug was considered fixed but apparently was only mostly fixed. Just the typical problem of two values that are mathematically equal not ending up numerically equivalent. Consider this series of three 2x2 tables: [1,]17 [2,]0 15 [1,]17 [2,]0 16 [1,]17 [2,]0 17 The pvals returned from chisq.test(m, sim=TRUE)$p.value are 0.3543228, 0.0004997501 and 0.3273363 respectively. The 2nd seems a bit unlikely, huh? I checked into it and the value I'm getting for the statistic (calculated in R code) is 4*.Machine$double.eps less than the value (which should be equal) that is returned from the C-code that does the simulation. Code for creating/testing the three matrices shown above: m <- matrix(c(1,0,7,15),2,2) ; chisq.test(m, sim=TRUE)$p.value m <- matrix(c(1,0,7,16),2,2) ; chisq.test(m, sim=TRUE)$p.value m <- matrix(c(1,0,7,17),2,2) ; chisq.test(m, sim=TRUE)$p.value Running SuSE9.3 on a AMD Athlon4000+ > version platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Patched major2 minor1.1 year 2005 month07 day 29 language R Thanks, Doug Douglas Grove Statistical Research Associate Fred Hutchinson Cancer Research Center Seattle WA 98109 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows 2000 crash while using rbind (PR#8225)
Windows 2000 reports that "Rgui.exe has generated errors and will be =
closed by Windows. You will need to restart the program." when using =
rbind.=20
df1 <- data.frame(cbind(x=3D1, y=3D1:1000), fac=3Dsample(LETTERS[1:3], =
1000, repl=3DTRUE))
df2 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], =
10, repl=3DTRUE))
df3 <- data.frame(cbind(x=3D1, y=3D1:100), =
fac=3Dsample(LETTERS[1:3], 100, repl=3DTRUE))
df4 <- rbind(df1,df2)
df5 <- rbind(df2,df3)
=20
=20
Since this only happens intermittantly and appears to be related to the =
size of the objects I ran the following code.
sink("rbind test.txt")
df1 <- data.frame(cbind(x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, =
repl=3DTRUE))
for (j in seq(10,100,1)){
df2 <- data.frame(cbind(x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, =
repl=3DTRUE))
print(j)
df3 <- rbind(df2,df1)
}
sink()
the output of rbind test.txt is
[1] 10
[1] 11
[1] 12
...
[1] 51
[1] 52
I then ran=20
sink("rbind test 2.txt")
df1 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
=3D 6, x=3D1, y=3D1:10), fac=3Dsample(LETTERS[4:6], 10, repl=3DTRUE))
for (j in seq(10,100,1)){
df2 <- data.frame(cbind(a =3D 1, b =3D 2, c =3D 3, d =3D 4, e =3D 5, f =
=3D 6, x=3D1, y=3D1:j), fac=3Dsample(LETTERS[1:3], j, repl=3DTRUE))
print(j)
df3 <- rbind(df2,df1)
}
sink()
which also stopped at 52.
I tried to narrow down where the crash takes place but it would appear =
that it is a moving feast, however both pieces of code always stopped =
with the same number, somewhere around 52.
> version
_ =20
platform i386-pc-mingw32
arch i386 =20
os mingw32 =20
system i386, mingw32 =20
status =20
major2 =20
minor2.0 =20
year 2005 =20
month10=20
day 06=20
svn rev 35749 =20
language R=20
One of the examples that has failed for me looks like
pop <- rbind(om.tp[,c(6,2,4,5,3)],eas[,c(2,1,3,4,5)])
> str(om.tp[,c(6,2,4,5,3)])
`data.frame': 1001384 obs. of 5 variables:
$ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 2 2 2 2 2 =
...
$ sex : Factor w/ 2 levels "Females","Males": 1 1 1 1 1 1 1 1 1 1 ...
$ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 21 21 21 =
21 21 21 21 21 21 21 ...
$ count: num 7.33 7.45 7.05 6.31 5.71 ...
$ year : Factor w/ 41 levels "2001","2002",..: 1 1 1 1 1 1 1 1 1 1 ...
> str(eas[,c(2,1,3,4,5)])
`data.frame': 25342 obs. of 5 variables:
$ age5 : Factor w/ 18 levels "0 to 4","5 to 9",..: 1 1 1 1 1 1 1 1 1 1 =
...
$ sex : Factor w/ 2 levels "Females","Males": 2 2 2 2 2 2 2 2 2 2 ...
$ lga : Factor w/ 142 levels "Albany (C)","Armadale (C)",..: 1 2 3 4 5 =
6 7 8 9 10 ...
$ count: num 1107 2163 532 294 479 ...
$ year : Factor w/ 5 levels "1991","1996",..: 1 1 1 1 1 1 1 1 1 1 ...
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 3255820 87.06193578 165.4 5266303 140.7
Vcells 22096825 168.6 32770865 250.1 32114295 245.1
Tom Mulholland
Senior Demographer
Spatial Information and Research
State and Regional Policy
Department for Planning and Infrastructure
Perth, Western Australia
+61 (08) 9264 7936
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
