A bug/error when "MaxArea" is small. about rtriangle

[chris-english]

triangulate(p, a = NULL, q = NULL, Y = FALSE, j = FALSE,
D = FALSE, S = 10000, V = 0, Q = TRUE)

setting S to a reasonable number greater than default, guessed at by looking at V =2 output * approximately 3, essentially giving steiner points additional elbow room to operate:

tp <- triangulate(p, a=ia[i], S=90000)

print(nc)
[1] 6549 7816 9788 13028 19530 38919 # as @davidcsterratt above

So, even with changing triangle.c to #define LINUX and fiddling with interface.c to pull in ftu_control.h, got same results as @shulele, until adjusting Stiener.

[mdsumner]

I will defer to @davidcsterratt of course, but @shulele can you provide an example of the problem? I've run your code and checked and I see very clear results that the max triangle area is always under the threshold.

[shulele]

I will defer to @davidcsterratt of course, but @shulele can you provide an example of the problem? I've run your code and checked and I see very clear results that the max triangle area is always under the threshold.

@mdsumner
Thanks for your reply.
I run my example code on Mac 10.13 Mojave.

The output figure is like this:

Output of sessioninfo() is the following.

sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods  
[7] base     

other attached packages:
[1] RTriangle_1.6-0.11

loaded via a namespace (and not attached):
[1] compiler_3.6.1 tools_3.6.1

[mdsumner]

Ah, I definitely don't see that! Thanks for replying, I will explore.

[davidcsterratt]

Thanks for the report. Unfortunately, I don't see this on my Linux (ubuntu) machine, and I don't have a Mac available to test on, so I'm a bit stuck and help will be appreciated.

This is what I see:

> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 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.0

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8    
 [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8   
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] RTriangle_1.6-0.10

loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3   

[chris-english]

I get the same. Sorry, blew up my fontconfig at some time.

print(nc)
[1] 6549 7816 9788 11469 12597 10026
benchmarkme::get_cpu()
$vendor_id
[1] "GenuineIntel"

$model_name
[1] "Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz"

$no_of_cores
[1] 4

library(RTriangle)
sessionInfo()
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.so

locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] RTriangle_1.6-0.11

loaded via a namespace (and not attached):
[1] compiler_4.0.0

I git cloned and R CMD INSTALL. Reading JR Shewchuk's code, papers, and Makefile, it seemed pretty clear that I should be making suggested adjustments in the build to de-fang Pentium floating point registers to enable/preserve the benefits of his exact geometry predicates. But I didn't compile it yet, installed RTriangle, copied and pasted @shulele 's code (to reassure me why I don't work on Mac), and then... Are you @davidcsterratt and Michael @mdsumner on AMD boxes? Or is my Pentium suggestion a red herring?

[shulele]

triangulate(p, a = NULL, q = NULL, Y = FALSE, j = FALSE, D = FALSE, S = 10000, V = 0, Q = TRUE)

setting S to a reasonable number greater than default, guessed at by looking at V =2 output * approximately 3, essentially giving steiner points additional elbow room to operate:

tp <- triangulate(p, a=ia[i], S=90000)

print(nc)
[1] 6549 7816 9788 13028 19530 38919 # as @davidcsterratt above

So, even with changing triangle.c to #define LINUX and fiddling with interface.c to pull in ftu_control.h, got same results as @shulele, until adjusting Stiener.

This is a perfect solution. Thank you, @chris-english .