[R] Geometry delaunayn and deldir results, differing results from Octave due to decimal precision?

[Bert Gunter]

"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 <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]]