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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Yuen, Kam
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]<mailto:[hidden email]> | 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]]

______________________________________________
[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.
Reply | Threaded
Open this post in threaded view
|

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

Bert Gunter-2
"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]<mailto:[hidden email]> | 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]]
>
> ______________________________________________
> [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-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

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

R help mailing list-2
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]<mailto:[hidden email]> | 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]]
>
> ______________________________________________
> [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-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

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

Jeff Newmiller
In reply to this post by Bert Gunter-2
I think there is some middle ground here... th ere are some expectations of
correctness that any user should have about various implementations of
well-known algorithms, and there are others that are unreasonable.
However, the normal terms of use you agree to by using open source code
such as the deldir package require that you take all responsibility for
incorrect results, whether from your mis-use of the code or flaws in the
code as given to you.

* Complaining to this list about percieved shortcomings is not likely to
help... particularly for contributed packages. As Bert says, it is up to
the contributors sharing these packages to get it right, and I like to
think they do so to the best of their ability or available time, and
neither R-help users nor R Core developers should be expected to take
responsibility for those packages.

* Numerical precision is a notoriously difficult subject, and you should
always be prepared to encounter differences in complicated results. It is
reasonable to expect them to be small discrepancies, but the definition of
"small" can depend on the algorithms used, and in all cases the user must
take responsibility for verifying results.

* Any expectation that any two implementations of a mathematical graph
algorithm present its results in the same sequence is unreasonable. It is
perfectly normal that different implementations sort things differently,
so buckle down and do your own sorting before doing comparisons. I would
further say that if you are making assumptions about result ordering in
your current work, YOUR application of the Delaunay algorithm is broken
and in danger of yielding incorrect results.

I suggest you sort both sets of results yourself and determine whether the
results are accurate enough for your purposes.

On Wed, 24 Jan 2018, Bert Gunter wrote:

> "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]<mailto:[hidden email]> | 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]]
>>
>> ______________________________________________
>> [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-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<[hidden email]>        Basics: ##.#.       ##.#.  Live Go...
                                       Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k

______________________________________________
[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.
Reply | Threaded
Open this post in threaded view
|

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

R help mailing list-2
In reply to this post by R help mailing list-2
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 <[hidden email]> 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:[hidden email]]
> *Sent:* 24 January 2018 19:29
> *To:* Yuen, Kam <[hidden email]>
> *Cc:* [hidden email]
> *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 <[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]<mailto:[hidden email]> | 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]]
>
> ______________________________________________
> [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-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.