>>>>> "TL" == Thomas Lumley <tlumley@(protected)>
>>>>>   on Fri, 9 Feb 2007 08:13:54 -0800 (PST) writes:

  TL> 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?


  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

______________________________________________
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.