[R] Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?
William Dunlap
wdunlap at tibco.com
Thu Jan 25 17:16:15 CET 2018
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.yuen at 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:wdunlap at tibco.com]
> *Sent:* 24 January 2018 19:29
> *To:* Yuen, Kam <k.yuen at fugro.com>
> *Cc:* r-help at 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.yuen at 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.yuen at fugro.com<mailto:k.yuen at 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 at 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]]
More information about the R-help
mailing list