[Rd] xy.coords(MATRIX) bug in code or documentation (PR#8937)
maechler at stat.math.ethz.ch
maechler at stat.math.ethz.ch
Mon Jun 5 22:10:49 CEST 2006
>>>>> "FrPi" == François Pinard <pinard at iro.umontreal.ca>
>>>>> on Mon, 5 Jun 2006 08:11:20 -0400 writes:
FrPi> [Martin Maechler]
>> Thanks a lot, Francois, for your careful reading and
>> careful report!
FrPi> Thanks for being receptive! :-)
FrPi> Another problem in the same area: the documentation
FrPi> lies about how the function acts when given a
FrPi> data.frame. From the code, a data.frame is processed
FrPi> as if it was a matrix. From the documentation, while
FrPi> the data.frame is not mentioned explicitely, it is
FrPi> implied in the paragraph explaining how a list is
FrPi> processed (because a data.frame is a list). Some
FrPi> reconciliation is needed here as well.
>> [ Though I do slightly mind the word "lies" since I do
>> value the 9th commandment.. Not telling the truth
>> *accidentally* is not "lying" ]
FrPi> Of course. You know, I merely forgot a smiley, there.
FrPi> You are right in that we should try a bit to spare the
FrPi> extreme susceptibility of some people! On the other
FrPi> hand, there should be limits to the feeling that we
FrPi> are always walking on eggs while writing to R-help or
FrPi> R-devel, some comfort and happiness is needed, after
FrPi> all. :-)
>> Yes; in this case, I propose to just amend the
>> documentation explainining that data.frames are treated
>> "as matrices".
FrPi> Let me add a small comment about data.frames. It
FrPi> would be a bit awkward if a data.frame had two columns
FrPi> "y" and "x" (in that order) and if they were
FrPi> interpreted differently after matrix coercion. I
FrPi> guess the problem would not exist if data.frames were
FrPi> really interpreted as lists, the "x" and "y" columns
FrPi> could even appear anywhere (untested).
you are right, but, as I now checked.
in S xy.coords() also behaves as it does now in R,
BTW, in both respects {data.frames and ">2-column" matrices and d.f.s}
Hence --- for back compatibility reasons -- I now tend to agree
with Duncan Murdoch, and would not change xy.coords() behavior
at all, but simply amend the documentation.
Martin
More information about the R-devel
mailing list