Re: [Rd] NA warnings for r() {aka "patch for random.c"}
G'day Martin and others,
On Mon, 10 Mar 2008 12:06:01 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:
> > "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> > on Fri, 7 Mar 2008 23:54:06 +0800 writes:
>
> BAT> After all,
>
> >> 1:2 + Inf
> BAT> [1] Inf Inf
>
> BAT> does not create any warning either.
>
> but it doesn't give NA either.
> A bit more relevant (and I'm sure you meant implicitly)
You give me more credit than I deserve. :)
I was guided by what rexp() was doing when I chose that example, i.e.
(potentially) warning about NAs being created when actually +/- Infs
were created. In this thread I was already once or twice tempted to
comment on the appropriateness of the warning message but for various
reasonx always refrained from doing so.
> BTW, I've also found that I
> rnorm(n, mu=Inf) |--> NA was not ok, and changed that to
> rnorm(n, mu=Inf) |--> Inf
>
> More feedback is welcome,
> but please now "start" with R-devel rev >= 44715
While I agree with this change, I think it opens a whole can of worms,
since it invites a rethink about all distributions. At the moment
we have:
R version 2.7.0 Under development (unstable) (2008-03-10 r44730)
> set.seed(1) ; exp(rnorm(2))
[1] 0.5344838 1.2015872
> set.seed(1) ; rlnorm(2)
[1] 0.5344838 1.2015872
> set.seed(1) ; exp(rnorm(2, mean=c(-Inf,Inf)))
[1] 0 Inf
> set.seed(1) ; rlnorm(2, mean=c(-Inf,Inf))
[1] NaN NaN
Warning message:
In rlnorm(2, mean = c(-Inf, Inf)) : NAs produced
The first two lines give identical results, as one could reasonably
expect. But the other two do not and I would argue that a user could
reasonably expect that the commands in these two lines should lead to
identical results.
Likewise, coming back to the one-parameter distribution used in this
thread for illustration purposes, the *exp() functions in R are
parameterised by the rate and an exponential random variable with rate
r has mean (1/r) and variance (1/r^2). Thus, I would argue that
rexp(2, Inf) should return 0's and not NaN's, since in the limit
a rate of Inf seems to refer to a variable with mean 0 and variance 0,
i.e. the constant 0. And it would also be "more consistent" with the
behaviour of rexp() when the rate parameter is "large but finite".
Then one can argue about rgeom() when p=0. But I guess in that case
the limit is a "random" variable with "infinite mean" and "infinite
variance" and hence it is o.k. to return NaNs and not Infs. After all,
your comments in rnorm.c seem to indicate that you think that reporting
+/- Inf back is only o.k. if the mean is +/- Inf but the variance is
finite.
I did not look at (or think about) extreme cases for any other
distributions, but further discussion/feedback would indeed be helpful
it seems. :)
And the attached patch would address the behaviour of rlnorm() and
rexp() that I have raised above. With these changes, on my machine,
"make check FORCE=FORCE" succeeds.
BTW, I was surprised to realise that the *exp() functions in the
underlying C code use the opposite parameterisation from the
corresponding functions at R level. Perhaps it would be worthwhile to
point this out in section 6.7.1 of the Writing R extension manual? In
particular since the manual states:
Note that these argument sequences are (apart from the names and that
@code{rnorm} has no @var{n}) exactly the same as the corresponding
@R{} functions of the same name, so the documentation of the @R{}
functions can be used.
Well, as I noticed the hard way, for *exp() the documentation of the
corresponding R functions cannot be used. ;-)
Thanks for you patience.
Cheers,
Berwin
Index: src/library/stats/R/distn.R
===
--- src/library/stats/R/distn.R (revision 44730)
+++ src/library/stats/R/distn.R (working copy)
@@ -19,7 +19,7 @@
.Internal(pexp(q, 1/rate, lower.tail, log.p))
qexp <- function(p, rate=1, lower.tail = TRUE, log.p = FALSE)
.Internal(qexp(p, 1/rate, lower.tail, log.p))
-rexp <- function(n, rate=1) .Internal(rexp(n, 1/rate))
+rexp <- function(n, rate=1) .Internal(rexp(n, ifelse(rate==-Inf, -Inf,
1/rate)))
dunif <- function(x, min=0, max=1, log = FALSE)
.Internal(dunif(x, min, max, log))
Index: src/nmath/rexp.c
===
--- src/nmath/rexp.c(revision 44730)
+++ src/nmath/rexp.c(working copy)
@@ -32,7 +32,7 @@
double rexp(double scale)
{
-if (!R_FINITE(scale) || scale <= 0.0)
+if (!R_FINITE(scale) || scale < 0.0)
ML_ERR_return_NAN;
return scale * exp_rand();
Index: src/nmath/rlnorm.c
===
--- src/nmath/rlnorm.c (revision 44730)
+++ src/nmath/rlnorm.c (working copy)
@@ -31,8 +31,9 @@
double rlnorm(double logmean, double logsd)
{
-if(!R_FINITE(logmean) || !R_FINITE(logsd) || logsd < 0.)
+/* synchronise with changes to rnorm
Re: [Rd] Check errors using R2.6.2
On Mon, 10 Mar 2008, Rossi, Peter E. wrote: > great. sorry to have bothered. > > btw, the MinGW windows .exe installer installs 3.4.5 not 4.2.1 so you > have What installer? *We* provide one with both in, and document it in the manual. > to download the untar the files one by one from sourceforge. > > moving to Leopard soon so, hopefully, this garbage will go away. No, Leopard also does not come with the tools you need (like a Fortran compiler). > p > > > Peter E. Rossi > Joseph T. and Bernice S. Lewis Professor of Marketing and Statistics > Director, Kilts Center for Marketing > Editor, Quantitative Marketing and Economics > Rm 353, Graduate School of Business, U of Chicago > 5807 S. Woodlawn Ave, Chicago IL 60637 > Tel: (773) 702-7513 | Fax: (773) 834-2081 > WWW: http://ChicagoGsb.edu/fac/peter.rossi > SSRN: http://ssrn.com/author=22862 > > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2008 1:12 PM > To: Uwe Ligges > Cc: Rossi, Peter E.; r-devel@r-project.org > Subject: Re: [Rd] Check errors using R2.6.2 > > On Mon, 10 Mar 2008, Uwe Ligges wrote: > >> >> >> Rossi, Peter E. wrote: >>> I can successfully "check" a package with source under 2.5.1, > including >>> compiling source files and running examples with no errors or > warnings. >>> >>> when I try with R2.6.2, I get make errors: >>> >>> making bayesmc.d from bayesmc.c >>> make[3]:gcc-sjlj: Command not found >>> >>> etc. >>> >>> my gcc is version 3.4.2 >>> >>> I'm using Windows XP. >>> >>> Any thoughts? >> >> Yes: Upgrade gcc as the R Administration and Installation manual >> suggets. R >= 2.6.0 is built under gcc-4.2.1. > > Alternatively, read the MkRules file and set the macros as needed for > your > compiler (as the manual suggested). > > However, gcc 3.4.2 is ancient and has known bugs that means it cannot > even > compile R correctly on Windows. If you must use gcc 3, at least use > 3.4.5. > > > -- > 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 > -- 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] Check errors using R2.6.2
great. sorry to have bothered. btw, the MinGW windows .exe installer installs 3.4.5 not 4.2.1 so you have to download the untar the files one by one from sourceforge. moving to Leopard soon so, hopefully, this garbage will go away. p Peter E. Rossi Joseph T. and Bernice S. Lewis Professor of Marketing and Statistics Director, Kilts Center for Marketing Editor, Quantitative Marketing and Economics Rm 353, Graduate School of Business, U of Chicago 5807 S. Woodlawn Ave, Chicago IL 60637 Tel: (773) 702-7513 | Fax: (773) 834-2081 WWW: http://ChicagoGsb.edu/fac/peter.rossi SSRN: http://ssrn.com/author=22862 -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:12 PM To: Uwe Ligges Cc: Rossi, Peter E.; r-devel@r-project.org Subject: Re: [Rd] Check errors using R2.6.2 On Mon, 10 Mar 2008, Uwe Ligges wrote: > > > Rossi, Peter E. wrote: >> I can successfully "check" a package with source under 2.5.1, including >> compiling source files and running examples with no errors or warnings. >> >> when I try with R2.6.2, I get make errors: >> >> making bayesmc.d from bayesmc.c >> make[3]:gcc-sjlj: Command not found >> >> etc. >> >> my gcc is version 3.4.2 >> >> I'm using Windows XP. >> >> Any thoughts? > > Yes: Upgrade gcc as the R Administration and Installation manual > suggets. R >= 2.6.0 is built under gcc-4.2.1. Alternatively, read the MkRules file and set the macros as needed for your compiler (as the manual suggested). However, gcc 3.4.2 is ancient and has known bugs that means it cannot even compile R correctly on Windows. If you must use gcc 3, at least use 3.4.5. -- 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] Check errors using R2.6.2
On Mon, 10 Mar 2008, Uwe Ligges wrote: > > > Rossi, Peter E. wrote: >> I can successfully "check" a package with source under 2.5.1, including >> compiling source files and running examples with no errors or warnings. >> >> when I try with R2.6.2, I get make errors: >> >> making bayesmc.d from bayesmc.c >> make[3]:gcc-sjlj: Command not found >> >> etc. >> >> my gcc is version 3.4.2 >> >> I'm using Windows XP. >> >> Any thoughts? > > Yes: Upgrade gcc as the R Administration and Installation manual > suggets. R >= 2.6.0 is built under gcc-4.2.1. Alternatively, read the MkRules file and set the macros as needed for your compiler (as the manual suggested). However, gcc 3.4.2 is ancient and has known bugs that means it cannot even compile R correctly on Windows. If you must use gcc 3, at least use 3.4.5. -- 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] write.table with row.names=FALSE unnecessarily slow?
I neglected to include my test case,
> df <- data.frame(x=1:(10^7))
Martin
Martin Morgan <[EMAIL PROTECTED]> writes:
> write.table with large data frames takes quite a long time
>
>> system.time({
> + write.table(df, '/tmp/dftest.txt', row.names=FALSE)
> + }, gcFirst=TRUE)
>user system elapsed
> 97.302 1.532 98.837
>
> A reason is because dimnames is always called, causing 'anonymous' row
> names to be created as character vectors. Avoiding this in
> src/library/utils, along the lines of
>
> Index: write.table.R
> ===
> --- write.table.R (revision 44717)
> +++ write.table.R (working copy)
> @@ -27,13 +27,18 @@
>
> if(!is.data.frame(x) && !is.matrix(x)) x <- data.frame(x)
>
> +makeRownames <- is.logical(row.names) && !is.na(row.names) &&
> +row.names==TRUE
> +makeColnames <- is.logical(col.names) && !is.na(col.names) &&
> +col.names==TRUE
> if(is.matrix(x)) {
> ## fix up dimnames as as.data.frame would
> p <- ncol(x)
> d <- dimnames(x)
> if(is.null(d)) d <- list(NULL, NULL)
> -if(is.null(d[[1]])) d[[1]] <- seq_len(nrow(x))
> -if(is.null(d[[2]]) && p > 0) d[[2]] <- paste("V", 1:p, sep="")
> +if (is.null(d[[1]]) && makeRownames) d[[1]] <- seq_len(nrow(x))
> +if(is.null(d[[2]]) && p > 0 && makeColnames)
> +d[[2]] <- paste("V", 1:p, sep="")
> if(is.logical(quote) && quote)
> quote <- if(is.character(x)) seq_len(p) else numeric(0)
> } else {
> @@ -53,8 +58,8 @@
> quote <- ord[quote]; quote <- quote[quote > 0]
> }
> }
> -d <- dimnames(x)
> -if(is.null(d[[1]])) d[[1]] <- seq_len(nrow(x))
> +d <- list(if (makeRownames==TRUE) row.names(x) else NULL,
> + if (makeColnames==TRUE) names(x) else NULL)
> p <- ncol(x)
> }
> nocols <- p==0
>
> improves performance at least in proportion to nrow(x):
>
>> system.time({
> + write.table(df, '/tmp/dftest1.txt', row.names=FALSE)
> + }, gcFirst=TRUE)
>user system elapsed
> 8.132 0.608 8.899
>
> Martin
> --
> Martin Morgan
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M2 B169
> Phone: (206) 667-2793
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.table with row.names=FALSE unnecessarily slow?
write.table with large data frames takes quite a long time
> system.time({
+ write.table(df, '/tmp/dftest.txt', row.names=FALSE)
+ }, gcFirst=TRUE)
user system elapsed
97.302 1.532 98.837
A reason is because dimnames is always called, causing 'anonymous' row
names to be created as character vectors. Avoiding this in
src/library/utils, along the lines of
Index: write.table.R
===
--- write.table.R (revision 44717)
+++ write.table.R (working copy)
@@ -27,13 +27,18 @@
if(!is.data.frame(x) && !is.matrix(x)) x <- data.frame(x)
+makeRownames <- is.logical(row.names) && !is.na(row.names) &&
+row.names==TRUE
+makeColnames <- is.logical(col.names) && !is.na(col.names) &&
+col.names==TRUE
if(is.matrix(x)) {
## fix up dimnames as as.data.frame would
p <- ncol(x)
d <- dimnames(x)
if(is.null(d)) d <- list(NULL, NULL)
-if(is.null(d[[1]])) d[[1]] <- seq_len(nrow(x))
-if(is.null(d[[2]]) && p > 0) d[[2]] <- paste("V", 1:p, sep="")
+if (is.null(d[[1]]) && makeRownames) d[[1]] <- seq_len(nrow(x))
+if(is.null(d[[2]]) && p > 0 && makeColnames)
+d[[2]] <- paste("V", 1:p, sep="")
if(is.logical(quote) && quote)
quote <- if(is.character(x)) seq_len(p) else numeric(0)
} else {
@@ -53,8 +58,8 @@
quote <- ord[quote]; quote <- quote[quote > 0]
}
}
-d <- dimnames(x)
-if(is.null(d[[1]])) d[[1]] <- seq_len(nrow(x))
+d <- list(if (makeRownames==TRUE) row.names(x) else NULL,
+ if (makeColnames==TRUE) names(x) else NULL)
p <- ncol(x)
}
nocols <- p==0
improves performance at least in proportion to nrow(x):
> system.time({
+ write.table(df, '/tmp/dftest1.txt', row.names=FALSE)
+ }, gcFirst=TRUE)
user system elapsed
8.132 0.608 8.899
Martin
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Check errors using R2.6.2
Rossi, Peter E. wrote: > I can successfully "check" a package with source under 2.5.1, including > compiling source files and running examples with no errors or warnings. > > when I try with R2.6.2, I get make errors: > > making bayesmc.d from bayesmc.c > make[3]:gcc-sjlj: Command not found > > etc. > > my gcc is version 3.4.2 > > I'm using Windows XP. > > Any thoughts? Yes: Upgrade gcc as the R Administration and Installation manual suggets. R >= 2.6.0 is built under gcc-4.2.1. Uwe Ligges > > thanks! > > peter r > > > > Peter E. Rossi > Joseph T. and Bernice S. Lewis Professor of Marketing and Statistics > Director, Kilts Center for Marketing > Editor, Quantitative Marketing and Economics > Rm 353, Graduate School of Business, U of Chicago > 5807 S. Woodlawn Ave, Chicago IL 60637 > Tel: (773) 702-7513 | Fax: (773) 834-2081 > WWW: http://ChicagoGsb.edu/fac/peter.rossi > SSRN: http://ssrn.com/author=22862 > > __ > 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
[Rd] Check errors using R2.6.2
I can successfully "check" a package with source under 2.5.1, including compiling source files and running examples with no errors or warnings. when I try with R2.6.2, I get make errors: making bayesmc.d from bayesmc.c make[3]:gcc-sjlj: Command not found etc. my gcc is version 3.4.2 I'm using Windows XP. Any thoughts? thanks! peter r Peter E. Rossi Joseph T. and Bernice S. Lewis Professor of Marketing and Statistics Director, Kilts Center for Marketing Editor, Quantitative Marketing and Economics Rm 353, Graduate School of Business, U of Chicago 5807 S. Woodlawn Ave, Chicago IL 60637 Tel: (773) 702-7513 | Fax: (773) 834-2081 WWW: http://ChicagoGsb.edu/fac/peter.rossi SSRN: http://ssrn.com/author=22862 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bindings for updated widgets in Tk 8.5.x
Tk 8.5.x is starting to trickle down to Linux distributions and the next release of R for Windows will ship with 8.5.1 (the binary builds of R-devel already do). According to http://www.tkdocs.com the new themed widget set has much to recommend it, and it certainly looks much better on MacOS and Windows. I've added bindings to package tcltk for R-devel, and taken a quick look at what would be needed to convert package Rcmdr to make use of them. in many uses they are a drop-in replacement (e.g. ttkbutton for tkbutton), but some of the customizations (fg="red") have different names (foreground="red", which also works for tkbutton) and others are replaced by the theme. -- 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] [patch] add=TRUE in plot.default()
On 3/9/2008 5:58 PM, Andrew Clausen wrote:
> On Sun, Mar 09, 2008 at 04:04:08PM -0400, Duncan Murdoch wrote:
>> Part of the reason I didn't like your patch is that it was incomplete:
>> it didn't patch the plot.default.Rd file.
>
> Fair enough -- I wasn't sure whether I was fixing a bug or not. ("..."
> spreads the documentation around a bit.)
>
>> That function already has
>> around 16 parameters; do we really want to add another one, that
>> interacts with some of the ones that are there?
>
> Yes. The ability to plot things on top of each other is important.
> The simplicity created by having a single interface for adding to plots
> outweighs the complexity of yet another parameter.
>
> The add parameter only interacts with other parameters superficially --
> some parameters of "plot" (like log) are related to the shape of the axes,
> and should be inherited from what is on the plot already.
I'd say causing some parameters to be completely ignored without a
warning is more than a superficial interaction. Really, add=TRUE is not
a great design: it would be better to say "plot methods draw a new
plot" (so they need args for all the decorations like axes, titles,
etc.), and have other ways to add things to plots. Hadley was right on
this, his ggplot2 has a better thought-out design than classic graphics.
However, we have what we have.
>> What you really seem to want is to add it to the generic plot(),
>
> Agreed.
>
>> but it's way too late to go modifying that particular generic.
>
> I agree. Adding an "add=FALSE" parameter to plot() would generate errors for
> methods that don't implement it, so they would all have to be changed
> simultaneously, including in private/unreleased code.
>
> So I'd like to settle for second best: adding add=FALSE parameters to many
> plot
> methods.
I like that suggestion better than adding it here and there, one at a
time. So, to advance the discussion: can you take a look at the plot
methods that are in the base and recommended packages, and work out how
many already have it, how many would be improved if it was added, and in
how many cases it just wouldn't make sense? (You could also do this on
all the CRAN and Bioconductor packages, but that would be about 100
times more work: about 50 times as many packages, and much less
consistency in the programming and documentation standards. Maybe on a
subset of popular ones, e.g. those that Rcmdr suggests?)
Data like that could make a convincing argument that the effort of
adding this to the base packages is worthwhile. (To get it added to
non-base packages will require you to convince their maintainers that
it's a good idea.) Another helpful part of the argument will be for you
to volunteer to do the work of both code and documentation updates.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re Bessel functions of complex argument
On 10 Mar 2008, at 11:03, Prof Brian Ripley wrote:
> On Mon, 10 Mar 2008, Martin Maechler wrote:
>
>> {Diverted from an R-help thread}
>>
>>> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
>>>on Mon, 10 Mar 2008 08:49:06 + writes:
>>
>> Robin> Hello Baptiste Bessel functions with complex
>> Robin> arguments are not supported in R.
>>
>> Hi Robin,
>> have you looked at *how* pari/gp does this?
>> If they have a C routine, it might be worth considering to add
>> ``the'' complex Bessel functionality to R.
>
> To an R package, surely? They hardly seem important enough for base
> R.
>
> There are C implementations in several places, e.g. ACM algorithm
> 644 (also netlib.org/amos).
>
Thanks for this. I'll have a look at netlib. Perhaps a wrapper for
netlib,
along the lines of the gsl package, would be possible. I also need
the gamma function with complex arguments and I suspect
that this is included.
PARI/GP is a large multi-developer effort, and provides an
environment not unlike R but geared towards pure mathematics rather
than statistics. It includes arbitrary-precision arithmetic and many
pure maths constructs such as number theory and p-adic metrics.
(I must confess to being not terribly familiar with the
Bessel suite; I only really know about PARI/GP's elliptic
functions). There
is no easy way to access the code for any specific functionality
in isolation, AFAICS.
One of my "longer-term" plans is to write a package that includes
a wrapper for GP (PARI is the front end, a command line wrapper) but
this is not entirely straightforward. Implementing a useful wrapper
proved
to be rather tricky. I expected that the methodology would
approximate the gsl package but this was not the case:
many of the features of PARI/GP are alien to the precepts and
tenets of R. My attempts stalled a couple of years ago after
I finished the elliptic package which included a fit-for-purpose, but
very very basic, wrapper for two or three functions.
Notwithstanding this, I think that an R wrapper for PARI/GP would
be very desirable. Comments anyone?
--
Robin Hankin
Uncertainty Analyst and Neutral Theorist,
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extract function "[" and empty index
Beware x[TRUE] returns the same as x[] only if x is NOT a zero-length vector (at least until R 2.5.1): > numeric(0)[] numeric(0) > numeric(0)[TRUE] [1] NA Enrique > -Original Message- > -- > > Message: 7 > Date: Mon, 10 Mar 2008 02:29:32 +0800 > From: "Laurent Gautier" <[EMAIL PROTECTED]> > Subject: Re: [Rd] extract function "[" and empty index > To: "Gabor Grothendieck" <[EMAIL PROTECTED]> > Cc: r-devel@r-project.org > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Thanks, I was forgetting the recycling rule. > > > L. > > > 2008/3/9, Gabor Grothendieck <[EMAIL PROTECTED]>: > > Use TRUE. > > > > > > On Sun, Mar 9, 2008 at 5:05 AM, Laurent Gautier > <[EMAIL PROTECTED]> wrote: > > > Dear list, > > > > > > I am having a question regarding the extract function "[". > > > > > > The man page says that one usage with k-dimensional arrays is to > > > specify k indices to "[", with an empty index indicating that all > > > entries in that dimension are selected. > > > > > > The question is the following: is there an R object > qualifying as an > > > "empty index" ? I understand that the lazy evaluation of > parameters > > > allows one to > > > have genuinely missing parameters, but I would like to > have an object > > > instead. I understand that one can always have an > if/else workaround, > > > but I thought should ask, just in case. > > > > > > I tried with NULL but with little success, as it appears > to give the > > > same results > > > as an empty vector. > > > > m = matrix(1, 2, 2) > > > > m[1, NULL] > > > numeric(0) > > > > m[1, integer(0)] > > > numeric(0) > > > > > > Since I was at it, I noted that the result obtained with > "numeric(0)" > > > definitely makes sense but could as well be seen as > challenging the > > > concept of an empty index presented in the man page (One > could somehow > > > expect the presence of an object meaning "everything" > rather than > > > "missingness" meaning it). > > > > > > > > > Thanks, > > > > > > > > > Laurent > > > > > > > > __ > > > 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] NA warnings for r() {aka "patch for random.c"}
> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> on Fri, 7 Mar 2008 23:54:06 +0800 writes:
BAT> G'day Martin (and "listeners"), On Fri, 7 Mar 2008
BAT> 15:01:26 +0100 Martin Maechler
BAT> <[EMAIL PROTECTED]> wrote:
BAT> [...]
>> >> If you feel like finding another elegant patch...
>>
BAT> Well, elegance is in the eye of the beholder. :-)
>>
BAT> I attach two patches. One that adds warning messages
BAT> at the other places where NAs can be generated.
>>
>> ok. The result is very simple ``hence elegant''.
>>
>> But actually, part of the changed behavior may be
>> considered undesirable:
>>
>> rnorm(2, mean = NA)
>>
>> which gives two NaN's would now produce a warning, where
>> I could argue that 'arithmetic with NAs should give NAs
>> without a warning' since 1:2 + NA also gives NAs without
>> a warning.
>>
>> So we could argue that a warning should *only* be
>> produced in a case where the parameters of the
>> distribution are not NA.
>>
>> What do others (particularly R-core !) think?
BAT> I can agree with that point of view. But then, should
BAT> a warning not be issued only if one of the parameters
BAT> of the distribution is NA, or should it also not be
BAT> issued if any non-finite parameter is encountered?
BAT> After all,
>> 1:2 + Inf
BAT> [1] Inf Inf
BAT> does not create any warning either.
but it doesn't give NA either.
A bit more relevant (and I'm sure you meant implicitly)
> Inf/Inf
[1] NaN
However, I think we shouldn't go as far.
BAT> In that case, a patch as the attached should do, it
BAT> checks all parameters for finiteness and then checks
BAT> whether the generated number is not finite.
BAT> Thus, with the patch applied I see the following
BAT> behaviour:
>> rnorm(2, mean=NA)
BAT> [1] NaN NaN
>> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
BAT> [1] 1.897874 NaN NaN NaN NaN
>> rbinom(2, size=20, p=1.2)
BAT> [1] NaN NaN Warning message: In rbinom(2, size = 20, p
BAT> = 1.2) : NAs produced
>> rexp(2, rate=-2)
BAT> [1] NaN NaN Warning message: In rexp(2, rate = -2) :
BAT> NAs produced
I've committed a bit a different patch for now (svn rev 44715),
because I felt we were getting too sophisticated.
The current (since about 20 minutes) situation is to
warn when the *result* is NA or NaN and not to warn in any other
cases.
This maybe not be perfect, but at least is very consistent and
in particular consistent to what the warning itself "says".
BTW, I've also found that I
rnorm(n, mu=Inf) |--> NA was not ok, and changed that to
rnorm(n, mu=Inf) |--> Inf
More feedback is welcome,
but please now "start" with R-devel rev >= 44715
Martin
BAT> Without the patch:
>> rnorm(2, mean=NA)
BAT> [1] NaN NaN
>> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
BAT> [1] -0.1719657 NaN NaN NaN NaN
>> rbinom(2, size=20, p=1.2)
BAT> [1] NaN NaN
>> rexp(2, rate=-2)
BAT> [1] NaN NaN Warning message: In rexp(2, rate = -2) :
BAT> NAs produced
BAT> On my machine, "make check FORCE=FORCE" passes with
BAT> this patch.
BAT> [...]
>> For now, I will ignore this second patch.
>>
>> - it does bloat the code slightly (as you conceded)
BAT> Fair enough. :) I also proved my point that more
BAT> complicated code is harder to maintain. In the two
BAT> parameter case I was testing twice na for being one
BAT> instead of testing na and nb...
BAT> [...]
>> but most importantly:
>>
>> - we have no idea if the speedup (when is TRUE)
>> is in the order of 10%, 1% or 0.1%
>>
>> My guess would be '0.1%' for rnorm(), and that would
>> definitely not warrant the extra check.
BAT> I would not bet against this. Probably even with all
BAT> the additional checks for finiteness of parameters
BAT> there would be not much speed difference. The question
BAT> might be whether you want to replace the (new)
BAT> R_FINITE()'s rather by ISNA()'s (or something else).
BAT> One could also discuss in which order the checks should
BAT> be made (first generated number then parameters of
BAT> distribution or vice versa). But I will leave this to
BAT> R-core to decide. :)
>> >> Thank you Berwin, for your contribution!
>>
>> and thanks again!
BAT> Still my pleasure. :)
BAT> Cheers,
BAT>Berwin Index: src/main/random.c
BAT> ===
BAT> --- src/main/random.c (revision 44693) +++
BAT> src/main/random.c (working copy) @@ -44,7 +44,7 @@ for
BAT> (i = 0; i < n; i++) { ai = a[i % na]; x[i] = f(ai); -
BAT> if (!R_FINITE(x[i])) naflag = 1; + if (!R_FINITE(x[i])
BAT> && R_FINITE(ai)) naflag = 1; } return(naflag); } @@
BAT> -81,6 +81,7 @@ if (na
Re: [Rd] Re Bessel functions of complex argument
On Mon, 10 Mar 2008, Martin Maechler wrote:
{Diverted from an R-help thread}
"Robin" == Robin Hankin <[EMAIL PROTECTED]>
on Mon, 10 Mar 2008 08:49:06 + writes:
Robin> Hello Baptiste Bessel functions with complex
Robin> arguments are not supported in R.
Robin> Neither matlab nor the Gnu Scientific Library support
Robin> them either.
Robin> . . . but . . .
Robin> the pari/gp system (released on the GPL) does:
Robin> ? besselj(1+I,3)
Robin> %3 = 0.6919067491368555819808728680 + 0.4484268613977010268818252591*I
Robin> ?
Robin> You can access some pari/gp functionality from within R
Robin> by using the elliptic package, although unfortunately
Robin> its wrapper function, P.pari(), is not quite flexible enough
Robin> to deal with besselj().
Robin> I'd be happy to discuss this offline; P.pari() will need only
Robin> minor changes to accommodate besselj().
Hi Robin,
have you looked at *how* pari/gp does this?
If they have a C routine, it might be worth considering to add
``the'' complex Bessel functionality to R.
To an R package, surely? They hardly seem important enough for base R.
There are C implementations in several places, e.g. ACM algorithm 644
(also netlib.org/amos).
We have seen several occasions where people had a clear usage
need for them.
{{I have a vague déjà-vue feeling on this whole topic }}
Martin Maechler, ETH Zurich
--
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] Re Bessel functions of complex argument
{Diverted from an R-help thread}
> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Mon, 10 Mar 2008 08:49:06 + writes:
Robin> Hello Baptiste Bessel functions with complex
Robin> arguments are not supported in R.
Robin> Neither matlab nor the Gnu Scientific Library support
Robin> them either.
Robin> . . . but . . .
Robin> the pari/gp system (released on the GPL) does:
Robin> ? besselj(1+I,3)
Robin> %3 = 0.6919067491368555819808728680 +
0.4484268613977010268818252591*I
Robin> ?
Robin> You can access some pari/gp functionality from within R
Robin> by using the elliptic package, although unfortunately
Robin> its wrapper function, P.pari(), is not quite flexible enough
Robin> to deal with besselj().
Robin> I'd be happy to discuss this offline; P.pari() will need only
Robin> minor changes to accommodate besselj().
Hi Robin,
have you looked at *how* pari/gp does this?
If they have a C routine, it might be worth considering to add
``the'' complex Bessel functionality to R.
We have seen several occasions where people had a clear usage
need for them.
{{I have a vague déjà-vue feeling on this whole topic }}
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
