From maechler at stat.math.ethz.ch  Mon Aug 16 14:19:16 2004
From: maechler at stat.math.ethz.ch (maechler@stat.math.ethz.ch)
Date: Mon Aug 16 14:19:24 2004
Subject: [Rd] bus error /segmentation fault from 'approx' (PR#7177)
Message-ID: <20040816121916.D7EB610EA8@slim.kubism.ku.dk>

>>>>> "PD" == Peter Dalgaard <p.dalgaard@biostat.ku.dk>
>>>>>     on 16 Aug 2004 12:01:20 +0200 writes:

    PD> j.van_den_hoff@fz-rossendorf.de writes:
    >> follow up to ID 7166. something like
    >> 
    >> approx(c(1,2),c(NA,NA),1.5,rule=2)
    >> 
    >> crashes 1.9.1 on both systems (MacOS 10.3.5.: bus error,  SunOS 5.9:
    >> segmentation fault) even if xout is within given x range (as in example above)
    >> where rule=2 seems not be relevant anyway.

    PD> Yes, this is a silly bug in the R driver routine:


    PD> if (nx < 2 && method == "linear")
    PD> stop("approx requires at least two values to interpolate")
    PD> if (any(na <- is.na(x) | is.na(y))) {
    PD> ok <- !na
    PD> x <- x[ok]
    PD> y <- y[ok]
    PD> nx <- length(x)
    PD> }

    PD> You want to do the check after removing NAs! 

    PD> Also, we should probably have a check for (nx == 0 && method != "linear")
yes (2 times)  *and*  'method' is not a string anymore at that
moment because it has been pmatch()ed.

I'm going to match.arg() it instead.
And I see there's more cleanup possible, since,
xy.coords() already makes sure to return 2 equal length numeric
components.

When I do this now, it breaks back compatibility since things
like (PR#6809)
	approx(list(x=rep(NaN, 9), y=1:9), xout=NaN)
would give an error instead of (NaN, NaN).

OTOH, the stop("....") message you cite above was obviously
*intended* to be triggered for such a case.
I presume we rather intend to be back compatible?

Martin


[Rd] bus error /segmentation fault from 'approx' (PR#7177)
maechler@stat.math.ethz.ch