Mac ARM64 build report for BioC 3.19 from 'kjohnson3' reporting ERROR which it does not happen in Linux
3
0
Entering edit mode
robersy • 0
@b291f47e
Last seen 6 months ago
United States

The 'kjohnson3' built report say: (https://bioconductor.org/checkResults/release/bioc-mac-arm64-LATEST/GenomAutomorphism/kjohnson3-checksrc.html)

The Failure ('test-aa_mutmat.R:7:6'): mat && aa is not TRUE

actual: FALSE expected: TRUE

I just run the current R script and it did not yield any error. This testing is in Ubuntu, I am not a Mac Computer user. Do I missing something?

library(GenomAutomorphism)
library(testthat)

data("aaindex2", package = "GenomAutomorphism" )
mat <- aa_mutmat(aaindex = "aaindex2", acc_list = TRUE)
mat <- grepl("MIYS930101", mat[37])
aa <- aa_mutmat(acc = "MIYS930101", aaindex = "aaindex2")
aa <- sum(aa[1,]) == -2.96
expect_true(mat && aa)  ##  No error from my side

sessionInfo( )

# R version 4.4.0 (2024-04-24)
# Platform: x86_64-pc-linux-gnu
# Running under: Ubuntu 22.04.4 LTS
# 
# Matrix products: default
# BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0 
# LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0
# 
# locale:
#     [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8       
# [4] LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
# [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
# [10] LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       
# 
# time zone: America/New_York
# tzcode source: system (glibc)
# 
# attached base packages:
#     [1] stats     graphics  grDevices utils     datasets  methods   base     
# 
# other attached packages:
#     [1] testthat_3.2.1.1        GenomAutomorphism_1.5.0
# 
# loaded via a namespace (and not attached):
#     [1] jsonlite_1.8.8          dplyr_1.1.4             compiler_4.4.0         
# [4] crayon_1.5.2            brio_1.1.5              tidyselect_1.2.1       
# [7] GenomicRanges_1.55.4    Biostrings_2.71.6       parallel_4.4.0         
# [10] IRanges_2.37.1          BiocParallel_1.37.1     R6_2.5.1               
# [13] XVector_0.43.1          generics_0.1.3          knitr_1.46             
# [16] GenomeInfoDb_1.39.14    BiocGenerics_0.49.1     iterators_1.0.14       
# [19] tibble_3.2.1            numbers_0.8-5           GenomeInfoDbData_1.2.12
# [22] pillar_1.9.0            rlang_1.1.3             utf8_1.2.4             
# [25] xfun_0.43               doParallel_1.0.17       cli_3.6.2              
# [28] magrittr_2.0.3          zlibbioc_1.49.3         foreach_1.5.2          
# [31] rstudioapi_0.16.0       lifecycle_1.0.4         waldo_0.5.2            
# [34] S4Vectors_0.41.7        vctrs_0.6.5             glue_1.7.0             
# [37] data.table_1.15.4       codetools_0.2-20        stats4_4.4.0           
# [40] fansi_1.0.6             httr_1.4.7              matrixStats_1.3.0      
# [43] tools_4.4.0             pkgconfig_2.0.3         UCSC.utils_0.99.7
GenomAutomorphism • 1.1k views
ADD COMMENT
3
Entering edit mode
@vincent-j-carey-jr-4
Last seen 9 weeks ago
United States

the test is not portable

> aa <- aa_mutmat(acc = "MIYS930101", aaindex = "aaindex2")
> str(aa)
 num [1:20, 1:20] 0.34 -0.08 -0.16 0.04 -0.51 -0.16 0.03 0.19 -0.21 -0.45 ...
 - attr(*, "dimnames")=List of 2
  ..$ : chr [1:20] "A" "R" "N" "D" ...
  ..$ : chr [1:20] "A" "R" "N" "D" ...
> sum(aa[1,])
[1] -2.96
> sum(aa[1,]) == -2.96
[1] FALSE
> sum(aa[1,]) - -2.96
[1] 4.440892e-16

please use another method to verify value of sum(aa[1,])

2
Entering edit mode

Indeed. Calculations involving floating point arithmetic are architecture-dependent, and testing the results should be done with all.equal() rather than == or identical() to leave room for some rounding error. E.g. on my 64-bit Intel Linux laptop:

> 2.3 == (2.3 + 1e-15)
[1] FALSE

> identical(2.3, (2.3 + 1e-15))
[1] FALSE

> all.equal(2.3, (2.3 + 1e-15))
[1] TRUE

The first two comparisons will give TRUE or FALSE depending on the architecture. Only the 3rd comparison is portable (i.e. should always be TRUE).

ADD REPLY
1
Entering edit mode

btw that was run on M1 mac

ADD REPLY
1
Entering edit mode
Mike Smith ★ 6.6k
@mike-smith
Last seen 9 hours ago
EMBL Heidelberg

The other answers here are all good and demonstrate the issue with floating point comparisons nicely.

I'd like to add that your particular test feels a bit obscure. If it fails, how do you know whether it's mat or aa or both that is causing the failure? I wonder if it would be more useful to write it as two tests e.g something like:

expect_true( grepl("MIYS930101", mat[37]) )
expect_equal( sum(aa[1,]) , -2.96 )

Using expect_equal has the added benefit of using all.equal() under the hood, which Hervé Pagès demonstrated was the correct way to test numeric values.

ADD COMMENT
0
Entering edit mode
robersy • 0
@b291f47e
Last seen 6 months ago
United States

Thank you all for your comments. I will follow your suggestions.

ADD COMMENT

Login before adding your answer.

Traffic: 390 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6