[Rd] predict.smooth.spline.fit and Recall() (Was: Re: Return function from function and Recall())

[Prof Brian Ripley]

On Wed, 5 Apr 2006, Henrik Bengtsson wrote:

> On 4/5/06, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>> On Wed, 5 Apr 2006, Henrik Bengtsson wrote:
>>
>>> On 4/5/06, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>>>> On Wed, 5 Apr 2006, Henrik Bengtsson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> forget about the below details.  It is not related to the fact that
>>>>> the function is returned from a function.  Sorry about that.  I've
>>>>> been troubleshooting soo much I've been shoting over the target.  Here
>>>>> is a much smaller reproducible example:
>>>>>
>>>>> x <- 1:10
>>>>> y <- 1:10 + rnorm(length(x))
>>>>> sp <- smooth.spline(x=x, y=y)
>>>>> ypred <- predict(sp$fit, x)
>>>>> # [1]  2.325181  2.756166  ...
>>>>> ypred2 <- predict(sp$fit, c(0,x))
>>>>> # Error in Recall(object, xrange) : couldn't find
>>>>> # function "predict.smooth.spline.fit"
>>>>
>>>> It seems Recall is not searching (via findFun) from the right environment,
>>>> but at a quick glance it is not obvious to me why.
>>>> You can replace Recall by predict.smooth.spline.fit for now.
>>>
>>> More troubleshooting shows that by dispatching directly on 'sp' and
>>> not 'sp$fit' works.  The reason that I do not want to do this is
>>> related to my questions yesterday that I want to keep the memory usage
>>> down and 'sp' hold quite some extra data even with keep.data=FALSE.
>>
>> Ahah!  So you are not using this as intended, and I had not spotted this.
>
> Neither did I ;)
>
>> Now I understand: you are calling predict, which finds
>> predict.smooth.spline.fit via method registration, and dispatches it in
>> the environment used to call predict, .GlobalEnv, where of course it is
>> not visible. Then Recall uses that environment, but attempts to call the
>> method directly.
>>
>> If you call this as intended, predict is called from the body of
>> predict.smooth.spline where predict.smooth.spline.fit is visible.
>>
>> I am afraid that you should not be expecting to be able to subvert things
>> this way.
>
> One could argue that it should not be possible to dispatch to a
> non-exported method the way I did.  If UseMethod() would use the same
> search path as the calling expression in the parent frame (and not
> from "within" the environment where the generic function lives),

It *does* do the former: method dispatch is dynamically scoped.
NB: 'via method registration'.

> then the predict() would fail right away.  However, I think it is a very 
> risky business to make such modifications to UseMethod(), because there 
> are probably unknown side effects to this.

One could argue that the particular method should not have been 
registered, so it could only be found from within the namespace.

However, there are several other examples (such as cophenetic.dendrogram) 
which are intended to work and fall foul of the same trap.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
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, UK                Fax:  +44 1865 272595