>>>>> "TL" == Thomas Lumley <[EMAIL PROTECTED]>
>>>>> on Fri, 9 Feb 2007 08:13:54 -0800 (PST) writes:
TL> On 2/9/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>>> The other reason why pmin/pmax are preferable to your functions is that
>>> they are fully generic. It is not easy to write C code which takes into
>>> account that <, [, [<- and is.na are all generic. That is not to say
that
>>> it is not worth having faster restricted alternatives, as indeed we do
>>> with rep.int and seq.int.
>>>
>>> Anything that uses arithmetic is making strong assumptions about the
>>> inputs. It ought to be possible to write a fast C version that worked
for
>>> atomic vectors (logical, integer, real and character), but is there
>>> any evidence of profiled real problems where speed is an issue?
TL> I had an example just last month of an MCMC calculation where profiling
showed that pmax(x,0) was taking about 30% of the total time. I used
TL> function(x) {z <- x<0; x[z] <- 0; x}
TL> which was significantly faster. I didn't try the
TL> arithmetic solution.
I did - eons ago as mentioned in my message earlier in this
thread. I can assure you that those (also mentioned)
pmin2 <- function(k,x) (x+k - abs(x-k))/2
pmax2 <- function(k,x) (x+k + abs(x-k))/2
are faster still, particularly if you hardcode the special case of k=0!
{that's how I came about these: pmax(x,0) is also denoted x_+, and
x_+ := (x + |x|)/2
x_- := (x - |x|)/2
}
TL> Also, I didn't check if a solution like this would still
TL> be faster when both arguments are vectors (but there was
TL> a recent mailing list thread where someone else did).
indeed, and they are faster.
Martin
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
