[Rd] Improvements (?) in stats::poly and stats::polym.
Martin Maechler
maechler at stat.math.ethz.ch
Thu Jul 23 16:25:30 CEST 2015
>>>>> "MM" == Martin Maechler <maechler at stat.math.ethz.ch>
>>>>> on Fri, 17 Jul 2015 18:00:28 +0200 writes:
MM> Dear Keith,
>>>>> <Keith.Jewell at campdenbri.co.uk>
>>>>> on Thu, 16 Jul 2015 08:58:11 +0000 writes:
>> Dear R Core Team,
>> Last week I made a post to the R-help mailing list
>> “predict.poly for multivariate data”
>> <https://stat.ethz.ch/pipermail/r-help/2015-July/430311.html>
>> but it has had no responses so I’m sending this to the
>> email address of package:stats maintainer. Please feel
>> free to tell me that this is inappropriate.
MM> Asking R Core in your case is ok ...
MM> { though still slightly "sub optimal" (but *not* "inappropriate"!):
MM> Ideallly you'd have followed the posting guide
MM> (http://www.r-project.org/posting-guide.html) here,
MM> namely to send your original post to R-devel instead of R-help.
MM> Then it would have been noticed by me and most probably
MM> several other R core members ...
MM> }
>> IMHO the reproducible code I presented in that post:
>> #############
>> library(datasets)
>> alm <- lm(stack.loss ~ poly(Air.Flow, Water.Temp, degree=3), stackloss)
>> alm$fitted.values[1:10] # "correct" prediction values [1:10]
>> predict(alm, stackloss)[1:10] # gives correct values
>> predict(alm, stackloss[1:10,]) # gives wrong values
>> #########
>> ... clearly demonstrates something wrong, the two predicts should not differ.
>> I hesitate to call it a bug, it might be viewed as inappropriate usage. But it's easy to get wrong answers, fairly small changes to poly and polym correct the wrongness, and I think the changes are backwards compatible. Perhaps appending the altered codes made the R-help post too long for easy comprehension, I attach them to this email.
MM> Thank you!
MM> I had started to look at your R-help post and noticed that you
MM> changed the *printout* of the R functions, instead of the
MM> source
MM> The current development version of that part of the R
MM> source code is always at
MM> https://svn.r-project.org/R/trunk/src/library/stats/R/contr.poly.R
MM> and if you look carefully, you see that there are comments in
MM> the sources that are lost in the process (of parsing,
MM> byte-compiling, saving in binary, ....),
MM> but never mind:
MM> you've marked your changes well and I can use your version to
MM> modify the sources.
>> From what I've understood, the changes make much sense and look
MM> good; and if no problem surfaces should make it into R - with an
MM> acknowledgement to you, of course.
I've now committed corresponding changes to R-devel, changes
which indeed have evolved from your (Keith) contributions, thank
you very much. My additional changes were trying to slightly simplify
the code logic, (and a new argument 'simple' to gain some
speed).
If the changes do not have visible negative effects on existing
CRAN/Bioconductor code (which *is* possible, after all, the results now sometimes
are different in the attributes),
we may consider porting the changes to 'R 3.2.1 patched' which
will become R 3.2.2 in three weeks.
Thank you again,
Martin Maechler
> [............................]
More information about the R-devel
mailing list