Wrong triangulation for a specific dataset in devel 0.4.0

[Jean-Romain]

Hi again,

I just spent so much time to figure out why a bug appeared in my package but actually the bug occurs since I installed the devel version of geometry to check bug #10.

I'm not able to reproduce the bug with dummy data such as randomly spread points so I shared you my data in Rdata file: points.Rdata.zip

library(geometry)

load("~/Bureau/points.Rdata")

t = delaunayn(cbind(x,y))

plot(x,y, cex = 0.1, col = "red")
trimesh(t, x, y, add = T)

As you can see below the triangulation is completely wrong. Removing v0.4.0 and reinstalling 0.3.6 everything is fine. I tryied to reproduce the bug with random points but each test leaded to a correct triangulation.

[davidcsterratt]

Nice (or nasty) catch! The immediate problem seems to be the Qz option, which was added in this commit: https://github.com/davidcsterratt/geometry/commit/8a1d495a0b70d355ed83d2e7cf2ba816b46a2854

Try t = delaunayn(cbind(x,y), options="Qt Qc") and you should get the right result.

I added the Qz option for compatibility with octave and scipy and because, IIRC, it fixes the edge case in issue #10. I'll think more about this...

[Jean-Romain]

Well I don't really have an opinion on this question. Maybe the original code was better (without Qz) since co spherical points is a very specific case. I mean it is ok for users to add an option Qz for a specific case but less intuitive to add two options Qt Qc because of some kind of random fails.

[davidcsterratt]

I've gone upstream with this - I'd rather understand why this behaviour occurs before making a decision about whether to drop the Qz option.

[cbbarber]

This will be fixed in Qhull 2019.1. See my note for #25 'Qz option can lead...'

Thanks Jean-Romain for reporting this problem, and David for not letting it go.