Thomas Lumley wrote:
> On 2/9/07, Prof Brian Ripley <ripley@(protected):
>>> 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?
>
>
> 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
>
>    function(x) {z <- x<0; x[z] <- 0; x}
>
> which was significantly faster. I didn't try the arithmetic solution. Also, I didn't check if a solution like this would still be faster when both arguments are vectors (but there was a recent mailing list thread where someone else did).
>
>
>     -thomas

I looked in all the code for the Hmisc and Design packages and didn't
find a single example where pmin or pmax did not have 2 arguments. So I
think it is important to have pmin2 and pmax2.

Frank
>
> Thomas Lumley      Assoc. Professor, Biostatistics
> tlumley@(protected)
--
Frank E Harrell Jr  Professor and Chair       School of Medicine
              Department of Biostatistics  Vanderbilt University

______________________________________________
R-help@(protected)
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.