I was trying to test equality of different R Objects and found that sometimes, when comparing objects in the wrong order, following error is occurring:
Error: C stack usage 7975620 is too close to the limit
Am I right that this is a Sign of too deep recursion?
It should be reproducible by following comparisons:
all.equal(mean, sd) # no error
all.equal(sd,mean) # Error: C stack usage 7975620 is too close to the limit
all.equal(NULL, mean) # no error
all.equal(mean,NULL) # Error: C stack usage 7975620 is too close to the limit
all.equal(mean, sum); all.equal(sd, sum) # no Error
all.equal(sum,NULL) # no error
all.equal(sd, var) # no error
all.equal(var, mean) # Error: C stack usage 7975620 is too close to the limit
all.equal(var, NULL) # Error: C stack usage 7975620 is too close to the limit
I am aware that the methods/functions I compared are implemented quite differently in R and there seems to be a pattern in comparison failure depending on how a given method is implemented, however I am wondering whether the behavior of the function is intended as such (I couldnt find a note on the order of objects to be compared within the documentation). I am also curious about it and would very appreciate if someone could explain this behavior to me.
I could also reproduce these issues within R --vanilla when from the terminal.
Session Info:
R version 4.1.3 (2022-03-10) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04.4 LTS
Matrix products: default BLAS:
/usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=de_DE.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=de_DE.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=Cattached base packages: [1] stats graphics grDevices utils
datasets methods baseloaded via a namespace (and not attached): [1] compiler_4.1.3
Edit: Tried the code samples on Rstudio Server and could NOT reproduce above behavior. Outputs of all.equal Function also differ
Session Info:
R version 4.0.3 (2020-10-10) Platform: x86_64-suse-linux-gnu (64-bit) Running under: openSUSE Leap 15.2
Matrix products: default BLAS: /usr/lib64/R/lib/libRblas.so LAPACK: /usr/lib64/R/lib/libRlapack.so
locale: [1] LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=C
LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8 [6] LC_MESSAGES=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8 LC_NAME=C LC_ADDRESS=C
LC_TELEPHONE=C [11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=Cattached base packages: [1] stats graphics grDevices utils
datasets methods baseloaded via a namespace (and not attached): [1] compiler_4.0.3 tools_4.0.3
I followed the error for all.equal(sd,mean), it actually stems from the call all.equal.environment(environment(sd), environment(mean), ignore.environment = FALSE).
From the documentation of all.equal(), we see that the environment method has the extra argument evaluate which is a
logical indicating if “promises should be forced”
This defaults to true, and seems to cause the stack usage problem.
To fix it, just call all.equal(..., evaluate = FALSE):
all.equal(mean, sd, evaluate = FALSE)
#> [1] "target, current do not match when deparsed"
#> [2] "names of environments differ: Lengths (1370, 1134) differ (string compare on first 1134) names of environments differ: 1134 string mismatches"
Created on 2022-03-29 by the reprex package (v2.0.1)
all.equal(mean, sd, evaluate = FALSE) # no Error
all.equal(sd,mean, evaluate = FALSE) # no Error
all.equal(NULL, mean, evaluate = FALSE) # no Error
all.equal(mean,NULL, evaluate = FALSE) # no Error
all.equal(mean, sum, evaluate = FALSE) # no Error
all.equal(sum,NULL, evaluate = FALSE) # no Error
all.equal(sd, var, evaluate = FALSE) # no Error
all.equal(var, mean, evaluate = FALSE) # no Error
all.equal(var, NULL, evaluate = FALSE) # no Error