Skip to content

[R-pkg-devel] "crossprod" is not a BUILTIN function

7 messages · Plamen Mirazchiyski, Duncan Murdoch, Ivan Krylov

Plamen Mirazchiyski
# 
Dear All,

Today I was preparing a new version for the RALSA package. I have built 
a Windows package using "devtools::check_win_devel()". I took the built 
Windows package and tested it on a Windows 10 machine to see if 
everything works as intended before submitting the source to CRAN. The 
machine has R 4.3.1, the latest official release. After I load the test 
RALSA package, R displays a message saying "Package RALSA built under R 
version 4.4.0", I guess this is what the win-builder uses when the 
source is sent via "devtools::check_win_devel()".

When testing one of the functions of the newly built RALSA package 
(lsa.corsstabs"), it crashes with the following message:

     Error in crossprod(x = sweep(x = as.matrix(replicated.averages),
     MARGIN = 2, : "crossprod" is not a BUILTIN function

I checked if it is a builtin by:

     grep(pattern = "cross", x = builtins(), value = TRUE)

This returned:

     [1] "tcrossprod" "crossprod"

I am not sure I understand, the "crossprod" function is in the base 
package and is builtin in 4.3.1, is it dropped in 4.4.0? If yes, how to 
overcome this?

Please advise.

Best,
Plamen
Duncan Murdoch
# 
The sources show that crossprod has become a primitive function. I don't 
think this should affect any R code that calls crossprod(); are you 
trying to call .Internal(crossprod( ... )) directly?

This was in the news a few weeks ago:

"The matrix multiplication functions ?crossprod()? and ?tcrossprod()? 
are now also primitive and S3 generic, as ?%*%? had become in R 4.3.0."

Duncan Murdoch
On 25/10/2023 3:02 p.m., Plamen Mirazchiyski wrote:
Ivan Krylov
# 
? Wed, 25 Oct 2023 21:02:00 +0200
Plamen Mirazchiyski <plamen.mirazchiyski at ineri.org> ?????:
Can you use R CMD build to make a .tar.gz source package and then
install that on the Windows 10 machine running R 4.3.1? There is
convenience and a lot of added value in both Win-Builder and devtools,
but it shouldn't be necessary to rely on 96 CRAN packages and an online
service just to build a package.

crossprod(x,y) has indeed been recently changed from
.Internal(crossprod(x, y)) to .Primitive("crossprod"). This makes it
possible for a binary package prepared using R-devel (with a call to
.Primitive('crossprod')) to misbehave on a released version of R (which
does have .Internal(crossprod(...)) but not .Primitive('crossprod')).

Installing from source will avoid this problem. So will building the
binary package using R-4.3.1 to run it on a different machine with
R-4.3.1.
Plamen Mirazchiyski
# 
Thank you very much for your responses Duncan and Ivan.

I do not call .Internal(crossprod( ... )) directly. I use crossprod() 
just once in the entire package, the actual line of code is

unname(obj = crossprod(x = sweep(x = as.matrix(replicated.averages), 
MARGIN = 2, mean.replicate.averages, FUN = "-"))*des.scale.fac)

I followed Ivan's advice, built a binary package from source in R 4.3.1 
on Windows 10, then tested it on another Windows 10 machine with R 
4.3.1. The problem did not occur et all.

If I understand Ivan's email, my package should work on R 4.3.1, but 
what about newer versions? I checked some packages that were released 
today, e.g. abn, these were built by CRAN "using R Under development 
(unstable) (2023-10-24 r85407 ucrt)". Does this mean mine will fail on 
the current released version (4.3.1) if built by CRAN. As far as I see 
from the R Developer Page (https://developer.r-project.org), there is a 
new version (4.3.2) scheduled for October 31, 2023. Should I better wait 
until then?

Best,
Plamen
On 10/25/23 21:26, Ivan Krylov wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
There are two kinds of builds:  source builds (producing the .tar.gz 
file) and binary builds (producing the .zip file on Windows).  Binary 
builds are specific to R minor versions:  if you build on R version 
x.y.z, you can't expect the package to work if either x or y changes.

Source builds should work on other R versions, though sometimes moving 
to earlier versions will cause problems (because the format of files in 
the .tar.gz file may have changed), or your package relies on features 
that weren't present earlier.  Generally .tar.gz files will work on 
later versions (though changes in R might break it).

So if you did a binary build on R 4.4.x and tested it on R 4.3.1, it's 
not at all surprising that it failed.  If you did a source build on R 
4.4.x and it failed on R 4.3.1, that's more surprising.

Duncan Murdoch

        
On 26/10/2023 9:43 a.m., Plamen Mirazchiyski wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
? Thu, 26 Oct 2023 15:43:54 +0200
Plamen Mirazchiyski <plamen.mirazchiyski at ineri.org> ?????:

            

      
      
      
    

        
The source package (the .tar.gz file obtained using R CMD build) will
keep working fine on both R 4.3 and R 4.4.

The binary package (the .zip file obtained using R CMD INSTALL --build
and produced on Win-Builder) is only guaranteed to work with the R
version that was used to build the binary package.

This is the reason why https://CRAN.R-project.org/package=RALSA offers
a single download of the source package...

            

      
      
      
    

        
...but multiple, separate downloads of binary versions of the package,
for R-4.4, R-4.3, and R-4.2:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Plamen Mirazchiyski
    

    

      
      #
    

  


  

      
I apologize for misreading Ivan's first email. I now installed from the 
tar.gz source file, everything worked as expected.

Thank you both for the thorough explanations.

Best,
Plamen

        
On 10/26/23 16:20, Ivan Krylov wrote: