A bug/error when "MaxArea" is small.

[shulele]

I noticed a bug or an error when I try to use small 'MaxArea' in the package.

I tested it with the following code:

library(RTriangle)
p <- pslg(P=rbind(c(0, 0), c(0, 1), c(0.5, 0.5), c(1, 1), c(1, 0)) * 1000,
          S=rbind(c(1, 2), c(2, 3), c(3, 4), c(4, 5), c(5, 1)))

ia <- 30 * (6:1)
nc <-ia * 0
nx <- length(ia)
par(mfrow=c(3,2))
for(i in 1:nx){
  ## Triangulate it
  tp <- triangulate(p, a=ia[i])
  plot(tp, type='n')
  nc[i] <- nrow(tp$T)
  mtext(paste('a= ', ia[i], ' n=', nc[i]))
}
print(nc)

Printed results are:

6549  7816  9788 11469 12597 10026

When the MaxArea is larger than 120, the results are correct. When the MaxArea is less than 120, there are some triangles whose area is larger than the threshold.
The number of triangles should become more and more, along with the increasing MaxArea threshold.

I guess that is the issue from the size of 'int' in the code. But I cannot fix it yet.

Any thoughts or suggestions? Thank you.

[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?

[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.

[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 .