[Rd] Unfixed bugs in latest R-patched

Martin Maechler maechler at stat.math.ethz.ch
Tue Jun 24 15:08:09 CEST 2014


>>>>> Radford Neal <radford at cs.toronto.edu>
>>>>>     on Mon, 23 Jun 2014 11:24:35 -0400 writes:

    > A new version of pqR is now available at pqR-project.org, which fixes
    > several bugs that are also present in the latest R Core patch release
    > (r66002).  A number of bugs found previously during pqR development
    > are also unfixed in the latest R Core release.  Here is the list of
    > these bugs that are unfixed in r66002 (including documentation
    > deficiencies), taken from the pqR bug fix and documentation update
    > sections of the pqR NEWS file (pqR-project.org/NEWS.txt):

Duncan Murdoch has already mentioned that "unfixed bugs" is a
strong wording...

I'm commenting on one subtopic only:

[.........]

    > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
      
    > x <- t(5)
    > print (x %*% c(3,4))
    > print (crossprod(5,c(3,4)))

    > The call of crossprod produced an error, whereas the
    > corresponding use of %*% does not.

    > In pqR-2013-12-29, this bug also affected the expression t(5) %*%
    > c(3,4), since it is converted to the equivalent of
    > crossprod(5,c(3,4)).
(I'm not getting this last para... but that may be unimportant)

[........]

    > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
      
    > v <- c(1,2)
    > m <- matrix(c(3,4),1,2)
    > print(t(m)%*%v)
    > print(crossprod(m,v))

    > in which crossprod gave an error rather than produce the answer
    > for the corresponding use of %*%.

Both cases above concern  %*%, crossprod() {and also
tcrossprod()}, and always when one at least one operand is a
vector... 

As S and R's terminology has always been mathematically correct and
"knows" that a vector is not a 1-row matrix or 1-column matrix 
(which some people call row-vector and column-vector), R has
indeed much more freedom to be lenient in how to promote vectors
to matrices, and it has always done so tolerantly for some cases
of "%*%", but even there is room for discussion, see below.

Since about January, I have a corresponding entry in the TODO
file of the Matrix package (which I maintain), and I (at least
partly) agree with you, that we should *consider* changing the
current behavior.  The following is from my corresponding R
script :

  ### NOTA BENE:  vector %*% Matrix  _and_  Matrix %*% vector :
  ### ---------   -----------------         -----------------
  ## The k-vector is treated as  (1,k)-matrix *or* (k,1)-matrix
  ## on both sides  whenever it "helps fit" the matrix dimensions:

and one kind of reasoning would go to say that 
crossprod() and tcrossprod()  should do the same.   This would
even make more cases work than (I think) your proposal.

However, one can argue that the current behavior is quite
consistent {there is more than one kind of consistency here; in
this case it's the consistency of underlying C code IIRC}, and
not strictly a bug.
It is something which I am grateful you bring up for discussion,
and I'm happy to settle here.
Note that the Matrix package and many other packages that
implement matrix multiplication methods, should then also follow
the new semantic, and so this is typically rather for R-devel
than R-patched.

Note that from your first case example, one could also argue
-- at least from my 'NOTA BENE' rule above --
that    5 %*% 3:4
should work, since  
       5 %*% rbind(3:4)
does work, but
       5 %*% cbind(3:4)
does not.  So you see, there are quite a few cases one could
discuss, and have reasons pro and contra some of the changes.

I will be too busy till the end of 'useR! 2014' and would want
quite a bit of further thoughts before making a quick decision,
notably about the cases I have in the appended  products.Rout

Martin Maechler,
(ETH Zurich and R Core team)

---------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: products.Rout
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140624/25ab3c6d/attachment.pl>


More information about the R-devel mailing list