search for: delaunayn

Dear R helpers, I try to use the 'delaunayn' function in the 'geometry' package for Delaunay triangulation in 2 dimensions. For the four following points, I get a warning message : > coord=matrix(ncol=2,byrow=TRUE,c(622633,7073452, + 621228,7073517, + 621879...

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 i...

...gt; 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 orienta...

...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 d...

...8.27, 654.05, 652.25, 651.22, 650.06, 649.66, 648.7, 647.04, 645.89, 644.91, 643.77, 642.63, 645.3, 647.98, 648.89, 653.93, 657.35, 659.75, 662.52, 666.66, 672.86, 677.25, 679.44, 681.24, 682.95, 686.44, 688.24, 689.49), .Dim = c(34L, 3L)) # One (wrong) way library(geometry) tm <- t(surf.tri(m, delaunayn(m))) plot3d(m[,1],m[,2],m[,3], type='l', col="black", size=2) rgl.triangles(m[tm, 1], m[tm, 2], m[tm, 3], col="green") ------------------------------------------------- Remko Duursma Research Lecturer Centre for Plants and the Environment University of Western Sy...

...gt; > for (k in 0:3){ + + screen(k+1) + cnt <- 0 + #grp<- iter * 5 + for (i in 1:5000 ) { + if (iter<-k*5) { + cnt = cnt + 1 + x[cnt] <- myx[i] + y[cnt] <- myy[i] + } + } + #p = cbind(x=rnorm(300), y=rnorm(300)) + #p = cbind(x, y) + #tt = delaunayn(p) + #trimesh(tt,p,axis=TRUE,box=TRUE) + plot(myx,myy) + } > > [[alternative HTML version deleted]]

...ii:dimension){ > matDistances[ii,jj]<- norm( df[,ii] - df[,jj]) > } > } This is both inefficient and ugly, I'll welcome any suggestion. In particular: - the location of the points on the sphere is not ideal (understand: not uniformly distributed over the area): i looked into delaunayn from the geometry package and qhull.com but at best I obtained a random set of points on the sphere. It must be a most classical problem ?? generating a uniform distribution of points on a sphere??, but i've set that problem aside for the moment. - the double for loop over all the poin...

...in 1:4){ + + screen(k) + cnt <- 0 + grp<- mydata$iter * 5 + for (i in 1:5000 ) { + if (grp<-k*5) { + cnt = cnt + 1 + x[cnt] <- mydata$xin[i] + y[cnt] <- mydata$yin[i] + } + } + #p = cbind(x=rnorm(300), y=rnorm(300)) + #p = cbind(x, y) + #tt = delaunayn(p) + #trimesh(tt,p,axis=TRUE,box=TRUE) + plot(x,y) + } > > [[alternative HTML version deleted]]