# Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?

5 messages
Open this post in threaded view
|

## Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?

 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/xELkj6r6the 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 [hidden email] | 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]] ______________________________________________ [hidden email] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.
Open this post in threaded view
|

## Re: Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?

 "The question is, what is making the results for the R packages different from each other?" There are literally thousands of R packages, contributed independently by thousands of people. There should be no expectation of consistency or for that matter, "correctness",  among them. Caveat emptor. Only within the base R distribution, maintained and mostly written by the R Core team,  might such consistency be reasonably expected. Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Wed, Jan 24, 2018 at 5:59 AM, Yuen, Kam <[hidden email]> 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 > [hidden email] | www.fugro.com 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]] > > ______________________________________________ > [hidden email] 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]] ______________________________________________ [hidden email] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.
Open this post in threaded view
|

## Re: Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?

 In reply to this post by Yuen, Kam 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 <[hidden email]> 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 > [hidden email] | www.fugro.com 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]] > > ______________________________________________ > [hidden email] 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]] ______________________________________________ [hidden email] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.