> On Jul 13, 2017, at 3:37 PM, Marc Schwartz <marc_schwa...@me.com> wrote:
>
>
>> On Jul 13, 2017, at 3:22 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
>>
>> On 13/07/2017 4:08 PM, Marc Schwartz wrote:
>>> Hi All,
>>>
>>> As per the discussion today on R-Help:
>>>
>>> https://stat.ethz.ch/pipermail/r-help/2017-July/448132.html
>>>
>>> I am attaching a proposed patch for poly.Rd to provide clarifying wording
>>> relative to naming the 'degree' argument explicitly, in the case where the
>>> 'x' argument is a matrix, rather than a vector.
>>>
>>> This is based upon the svn trunk version of poly.Rd.
>>
>> I don't think this is the right fix. The use of the unnamed 2nd arg as
>> degree happens whether the first arg is a matrix or not.
>>
>> I didn't read the whole thread in detail, but it appears there's a bug
>> somewhere, in the report or in the poly() code or in the plsr() code. That
>> bug should be reported on the bug list if it turns out to be in base R, and
>> to the package maintainer if it is in plsr().
>>
>> Duncan Murdoch
>
>
> Duncan,
>
> Thanks for your reply. You only really need to read that last post in the
> thread linked to above.
>
> I won't deny the possibility of a bug in poly(), relative to the handling of
> 'x' as a matrix. The behavior occurs in the poly() function in a pure stand
> alone fashion, without the need for plsr():
>
> x1 <- runif(20)
> x2 <- runif(20)
> mx <- cbind(x1, x2)
>
<snip>
Duncan,
Tracing through the code for poly() using debug once with:
poly(mx, 2)
and then with:
poly(mx, degree = 2)
there is a difference in the transformation of 'mx' internally by the use of:
if (is.matrix(x)) {
m <- unclass(as.data.frame(cbind(x, ...)))
return(do.call(polym, c(m, degree = degree, raw = raw, list(coefs =
coefs))))
}
In the first case, 'mx' ends up being transformed to:
Browse[2]> m
$x1
[1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
[7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
[13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
[19] 0.58641410 0.08858699
$x2
[1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
[7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
[13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
[19] 0.5110733 0.4122336
$V3
[1] 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
attr(,"row.names")
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Thus, when do.call() is used, m$V3 is passed as the 'x' argument on the third
iteration, essentially resulting in:
> polym(rep(2, 20), degree = 2)
Error in poly(dots[[1L]], degree, raw = raw, simple = raw && nd > 1) :
'degree' must be less than number of unique points
Note also that in this case, 'dots', which is the result of using list(...) on
the initial call, is:
Browse[2]> dots
[[1]]
[1] 2
In the second case:
Browse[2]> m
$x1
[1] 0.99056941 0.13953093 0.38965567 0.35353514 0.90838486 0.97552474
[7] 0.01135743 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
[13] 0.31333549 0.97488211 0.54952630 0.71747157 0.31164777 0.81694822
[19] 0.58641410 0.08858699
$x2
[1] 0.6628658 0.9221436 0.3162418 0.8494452 0.4665010 0.3403719
[7] 0.4040692 0.4916650 0.9091161 0.2956006 0.3454689 0.3331070
[13] 0.8788974 0.5614636 0.7794396 0.2304009 0.6566537 0.6875646
[19] 0.5110733 0.4122336
attr(,"row.names")
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
So, there is no m$V3.
Note also that 'dots' ends up being:
Browse[2]> dots
list()
In both cases, 'degree' is indeed 2, but the result of 'list(...)' on the
initial function call is quite different.
So, I may be hypo-caffeinated, but if there is a bug here, it may be due to the
way in which cbind() is being called in the code above, where the three dots
are being used?
I can replicate the presumably correct behavior by using:
m <- unclass(as.data.frame(cbind(x)))
instead of:
m <- unclass(as.data.frame(cbind(x, ...)))
But I am not sure if removing the three dots in the cbind() call may have other
unintended consequences.
Regards,
Marc
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
