I just looked at the data at the URL you posted and it looks like it consists of all the points in a rectangular grid. When you triangulate a rectangle it is arbitrary whether you use the SW-NE or the SE-NW diagonal and that looks like the only difference between the various algorithms.
Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Jan 25, 2018 at 5:14 AM, Yuen, Kam <k.y...@fugro.com> wrote: > Bill, > > > > It wasn’t really the orientation I was worried about. > > I should perhaps have phrased the question better. It was really about the > fact that for the larger input example the triangles **are not** the same > for each implementation. > > They certainly differ from the Octave implementation (not that that is in > some way a gold standard). > > Anyhow the point made by yourself and others is well taken, i.e. I should > have no expectation that different implementations will produce the same > output. > > > > Regards, > > > > Kam > > > > > > *From:* William Dunlap [mailto:wdun...@tibco.com] > *Sent:* 24 January 2018 19:29 > *To:* Yuen, Kam <k.y...@fugro.com> > *Cc:* r-help@r-project.org > *Subject:* Re: [R] Geometry delaunayn and deldir results, differing > results from Octave due to decimal precision? > > > > All three results give the same collection of triangles. They > > don't all agree on whether the points in a triangle are in clockwise > > or counterclockwise order. If the orientation matters, it is a simple > > matter to reverse the order of points in those that described in > > the "wrong" orientation. > > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > > > On Wed, Jan 24, 2018 at 5:59 AM, Yuen, Kam <k.y...@fugro.com> wrote: > > The problem: > I would like to translate the Octave algorithm in griddata.m to R. > Within the griddata algorithm calls are made to the Delaunay function. For > the R translation I have found delaunayn within the "geometry" package and > also the deldir package. > Both do similar things but give slightly different results depending on > the input. > The question is, what is making the results for the R packages different > from each other? > And are those differences down to the decimal precision in the latter case > of using 9 d.p.? > In the following example I have defined x and y to be small vectors and > all three sets of results agree (but are in a different order), i.e. > Octave's delaunay, geometry.delaunayn, and deldir.deldir > > Octave > > x = [0.9554283 0.4695926 0.0769020 0.3033320 0.3553984 > 0.6051734 0.8661461 0.5511353 0.5214984 0.0061548] > > y = [0.851911 0.402087 0.704462 0.687721 0.939775 0.499157 > 0.077145 0.588351 0.454380 0.193425] > > tri = delaunay(x,y) > > tri = > > 2 7 10 > > 2 9 7 > > 6 7 1 > > 6 9 7 > > 4 2 9 > > 4 2 10 > > 8 5 1 > > 8 6 1 > > 8 4 5 > > 8 6 9 > > 8 4 9 > > 3 4 10 > > 3 4 5 > > > R With deldir package > x <- c(0.9554283,0.4695926,0.0769020,0.3033320,0.3553984,0. > 6051734,0.8661461,0.5511353,0.5214984,0.0061548) > y <- c(0.851911,0.402087,0.704462,0.687721,0.939775,0.499157,0. > 077145,0.588351,0.454380,0.193425) > tri <- deldir(x,y) > triMat(tri) = > [,1] [,2] [,3] > [1,] 1 5 8 > [2,] 1 6 7 > [3,] 1 6 8 > [4,] 2 4 10 > [5,] 2 4 9 > [6,] 2 7 10 > [7,] 2 7 9 > [8,] 3 4 10 > [9,] 3 4 5 > [10,] 4 5 8 > [11,] 4 8 9 > [12,] 6 7 9 > [13,] 6 8 9 > > R with geometry package > > x <- c(0.9554283,0.4695926,0.0769020,0.3033320,0.3553984,0. > 6051734,0.8661461,0.5511353,0.5214984,0.0061548) > > y <- c(0.851911,0.402087,0.704462,0.687721,0.939775,0.499157,0. > 077145,0.588351,0.454380,0.193425) > > library(geometry) > > tri <- delaunayn(cbind(x,y)) > > > > tri > > [,1] [,2] [,3] > > [1,] 2 7 10 > > [2,] 8 5 1 > > [3,] 6 7 1 > > [4,] 6 8 1 > > [5,] 4 2 10 > > [6,] 4 3 10 > > [7,] 4 3 5 > > [8,] 4 8 5 > > [9,] 9 6 8 > > [10,] 9 4 2 > > [11,] 9 4 8 > > [12,] 9 2 7 > > [13,] 9 6 7 > > As you can see, the results are identical with the exception of ordering. > > *However* when I use a slightly larger set of data for input, > "geometry.delaunayn" and "deldir.deldir" seems to give results that are off > by one in a lot of instances. > The input for the Delaunay function has been exported from Octave to 9 > d.p. and then imported into R by using the "foreign" package. > > Example data is on the following link. It is a set of variables exported > from Octave 'x y tri xiflat yiflat tri_list.mat' > https://pastebin.com/xELkj6r6 > > the variable tri_list is just the tri_list = > search(x,y,tri_deldir,xiflat,yiflat) > in Octave > > > The command history is a as follows: > library(deldir) > library(geometry) > library(foreign) > theData <- read.octave('x y tri xiflat yiflat tri_list.mat') > options(digits = 10) > x <- unlist(theData[1]) > y <- unlist(theData[3]) > tri_deldir <- triMat(deldir(x,y)) > tri_delaunayn <- delaunayn(x,y) > tri_delaunayn <- delaunayn(cbind(x,y)) > tri_list_from_deldir <- tsearch(x,y,tri_deldir,xiflat,yiflat) > xiflat <- unlist(theData[7]) > yiflat <- unlist(theData[9]) > tri_list_from_deldir <- tsearch(x,y,tri_deldir,xiflat,yiflat) > tri_list_from_delaunayn <- tsearch(x,y,tri_delaunayn,xiflat,yiflat) > > > Kam Yuen > Software Developer > T +44 (0)1491 820634| F +44 (0)1491 820599 > k.y...@fugro.com<mailto:k.y...@fugro.com> | www.fugro.com<http://www. > fugro.com/> > Fugro GB Marine Limited > Fugro House, Hithercroft Road, Wallingford, Oxfordshire OX10 9RB, UK > Registration No: 1135456 | VAT No: GB 579 3459 84 > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/ > posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > > > [[alternative HTML version deleted]] ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
