I have two triangulated meshes m and m1 with the following properties:
m_faces: 16640
m_points: 49920
m_surface_area: 178.82696989147524
m1_faces: 8
m1_points: 24
m1_surface_area: 1.440205667851934
Now I would like to subdivide m1 so that it has approx. the same faces number as m, i.e. 16640. I am using the vtk library and more specifically the vtkAdaptiveSubdivisionFilter() function which according to the description:
…is a filter that subdivides triangles based on maximum edge length and/or triangle area.
My question is how to compute the maximum edge length, according to some trial and error I found that this needs to be a value between [0.0188-0.0265] which gives me 16384 faces. However, I couldn’t find any formulation that gives a number in this ratio range and is consistent on different cases. Any idea how to calculate this maximum edge length each time?
On another example I have the following two meshes:
Sph1_faces: 390
Sph1_points: 1170
Sph1_surface_area: 1.9251713393584104
Sph2_faces: 1722
Sph2_points: 5166
Sph2_suface_area: 10.59400389764954
And for getting Sph1 number of faces close to Sph2 number of faces the maximum edge length should be between [0.089-0.09] which gives me 1730 faces for Sph1.
I've tried to use the equilateral triangle area formulation making the corresponding assumption and then solving for side and dividing by number of faces or points but it didn't seem to work. Thus, any other idea would be appreciated.
Thanks.
Related
Apologies for the overlap with existing questions; mine is at a more basic skill level. I am working with very sparse occurrences spanning very large areas, so I would like to calculate probability at pixels using the density.ppp function (as opposed to relrisk.ppp, where specifying presences+absences would be computationally intractable). Is there a straightforward way to convert density (intensity) to probabilities at each point?
Maxdist=50
dtruncauchy=function(x,L=60) L/(diff(atan(c(-1,1)*Maxdist/L)) * (L^2 + x^2))
dispersfun=function(x,y) dtruncauchy(sqrt(x^2+y^2))
n=1e3; PPP=ppp(1:n,1:n, c(1,n),c(1,n), marks=rep(1,n));
density.ppp(PPP,cutoff=Maxdist,kernel=dispersfun,at="points",leaveoneout=FALSE) #convert to probabilies?
Thank you!!
I think there is a misunderstanding about fundamentals. The spatstat package is designed mainly for analysing "mapped point patterns", datasets which record the locations where events occurred or things were located. It is designed for "presence-only" data, not "presence/absence" data (with some exceptions).
The relrisk function expects input data about the presence of two different types of events, such as the mapped locations of trees belonging to two different species, and then estimates the spatially-varying probability that a tree will belong to each species.
If you have 'presence-only' data stored in a point pattern object X of class "ppp", then density(X, ....) will produce a pixel image of the spatially-varying intensity (expected number of points per unit area). For example if the spatial coordinates were expressed in metres, then the intensity values are "points per square metre". If you want to calculate the probability of presence in each pixel (i.e. for each pixel, the probability that there is at least one presence point in the pixel), you just need to multiply the intensity value by the area of one pixel, which gives the expected number of points in the pixel. If pixels are small (the usual case) then the presence probability is just equal to this value. For physically larger pixels the probability is 1 - exp(-m) where m is the expected number of points.
Example:
X <- redwood
D <- density(X, 0.2)
pixarea <- with(D, xstep * ystep)
M <- pixarea * D
p <- 1 - exp(-M)
then M and p are images which should be almost equal, and can both be interpreted as probability of presence.
For more information see Chapter 6 of the spatstat book.
If, instead, you had a pixel image of presence/absence data, with pixel values equal to 1 or 0 for presence or absence respectively, then you can just use the function blur in the spatstat package to perform kernel smoothing of the image, and the resulting pixel values are presence probabilities.
I have a question please , it's about 'Isomap' nonlinear dimensionality reduction, in normal cases when I introduce a matrix distance of 100 * 100
and I apply Isomap [http://isomap.stanford.edu/][1] I get the coordinates of 100 points ,in other cases I do not understand why, with a matrix of 150 * 150 i obtain juste 35 or 50 points ?
The first step of Isomap is usually to create a "nearest neighbor matrix" so that every point is connected to its 4 or 6 or 8 or something nearest neighbors.
So, you may start with a distance matrix that is 100 x 100 and every point has a distance to 99 other points, after this first step the distances for anything but the (4 or 6 or 8) closest points are set to infinity.
Then Isomap computes a shortest path distance, hopping between nearby points to get to farther away points.
In your case, when you create a matrix of 150 points, I think that once you only keep the nearby points in the first step, the points become disconnected, and there is path between distant points. The default behavior of many Isomap codes is to return the Isomap embedding of the largest collection of connected points.
How can you fix this?
1. You can increase the number of nearest neighbors that you use until you get all the points included.
Caveat: In many natural cases, if you include most or all neighbors, this ends up in the case where the shortest-path part of the procedure does nothing, and this reduces to a problem called "multi-dimensional scaling" which gives a linear embedding.
I am currently researching the traveling salesman problem, and was wondering if anyone would be able to simply explain the held karp lower bound. I have been looking at a lot of papers and i am struggling to understand it. If someone could simply explain it that would be great.
I also know there is the method of calculating a minimum spanning tree of the vertices not including the starting vertex and then adding the two minimum edges from the starting vertex.
I'll try to explain this without going in too much details. I'll avoid formal proofs and I'll try to avoid technical jargon. However, you might want to go over everything again once you have read everything through. And most importantly; try the algorithms out yourself.
Introduction
A 1-tree is a tree that consists of a vertex attached with 2 edges to a spanning tree. You can check for yourself that every TSP tour is a 1-Tree.
There is also such a thing as a minimum-1-Tree of a graph. That is the resulting tree when you follow this algorithm:
Exclude a vertex from your graph
Calculate the minimum spanning tree of the resulting graph
Attach the excluded vertex with it's 2 smallest edges to the minimum spanning tree
*For now I'll assume that you know that a minimum-1-tree is a lower bound for the optimal TSP tour. There is an informal proof at the end.
You will find that the resulting tree is different when you exclude different vertices. However all of the resulting trees can be considered lower bounds for the optimal tour in the TSP. Therefore the largest of the minimum-1-trees you have found this way is a better lower bound then the others found this way.
Held-Karp lower bound
The Held-Karp lower bound is an even tighter lower bound.
The idea is that you can alter the original graph in a special way. This modified graph will generate different minimum-1-trees then the original.
Furthermore (and this is important so I'll repeat it throughout this paragraph with different words), the modification is such that the length of all the valid TSP tours are modified by the same (known) constant. In other words, the length of a valid TSP solution in this new graph = the length of a valid solution in the original graph plus a known constant. For example: say the weight of the TSP tour visiting vertices A, B, C and D in that order in the original graph = 10. Then the weight of the TSP tour visiting the same vertices in the same order in the modified graph = 10 + a known constant.
This, of course, is true for the optimal TSP tour as well. Therefore the optimal TSP tour in the modified graph is also an optimal tour in the original graph. And a minimum-1-Tree of the modified graph is a lower bound for the optimal tour in the modified graph. Again, I'll just assume you understand that this generates a lower bound for your modified graph's optimal TSP tour. By substracting another known constant from the found lower bound of your modified graph, you have a new lower bound for your original graph.
There are infinitly many of such modifications to your graph. These different modifications result in different lower bounds. The tightest of these lower bounds is the Held-Karp lower bound.
How to modify your graph
Now that I have explained what the Held-Karp lower bound is, I will show you how to modify your graph to generate different minimum-1-trees.
Use the following algorithm:
Give every vertex in your graph an arbitrary weight
update the weight of every edge as follows: new edge weight = edge weight + starting vertex weight + ending vertex weight
For example, your original graph has the vertices A, B and C with edge AB = 3, edge AC = 5 and edge BC = 4. And for the algorithm you assign the (arbitrary) weights to the vertices A: 30, B: 40, C:50 then the resulting weights of the edges in your modified graph are AB = 3 + 30 + 40 = 73, AC = 5 + 30 + 50 = 85 and BC = 4 + 40 + 50 = 94.
The known constant for the modification is twice the sum of the weights given to the vertices. In this example the known constant is 2 * (30 + 40 + 50) = 240. Note: the tours in the modified graph are thus equal to the original tours + 240. In this example there is only one tour namely ABC. The tour in the original graph has a length of 3 + 4 + 5 = 12. The tour in the modified graph has a length of 73 + 85 + 94 = 252, which is indeed 240 + 12.
The reason why the constant equals twice the sum of the weights given to the vertices is because every vertex in a TSP tour has degree 2.
You will need another known constant. The constant you substract from your minimum-1-tree to get a lower bound. This depends on the degree of the vertices of your found minimum-1-tree. You will need to multiply the weight you have given each vertex by the degree of the vertex in that minimum-1-tree. And add that all up. For example if you have given the following weights A: 30, B:40, C:50, D:60 and in your minimum spanning tree vertex A has degree 1, vertex B and C have degree 2, vertex D has degree 3 then your constant to substract to get a lower bound = 1 * 30 + 2 * 40 + 2 * 50 + 3 * 60 = 390.
How to find the Held-Karp lower bound
Now I believe there is one more question unanswered: how do I find the best modification to my graph, so that I get the tightest lower bound (and thus the Held-Karp lower bound)?
Well, that's the hard part. Without delving too deep: there are ways to get closer and closer to the Held-Karp lower bound. Basicly one can keep modifying the graph such that the degree of all vertices get closer and closer to 2. And thus closer and closer to a real tour.
Minimum-1-tree is a lower bound
As promised I would give an informal proof that a minimum-1-tree is a lower bound for the optimal TSP solution. A minimum-1-Tree is made of two parts: a minimum-spanning-tree and a vertex attached to it with 2 edges. A TSP tour must go through the vertex attached to the minimum spanning tree. The shortest way to do so is through the attached edges. The tour must also visit all the vertices in the minimum spanning tree. That minimum spanning tree is a lower bound for the optimal TSP for the graph excluding the attached vertex. Combining these two facts one can conclude that the minimum-1-tree is a lower bound for the optimal TSP tour.
Conclusion
When you modify a graph in a certain way and find the minimum-1-Tree of this modified graph to calculate a lower bound. The best possible lower bound through these means is the Held-Karp lower bound.
I hope this answers your question.
Links
For a more formal approach and additional information I recommend the following links:
ieor.berkeley.edu/~kaminsky/ieor251/notes/3-16-05.pdf
http://www.sciencedirect.com/science/article/pii/S0377221796002147
So say I have an image that I want to "pixelate". I want this sharp image represented by a grid of, say, 100 x 100 squares. So if the original photo is 500 px X 500 px, each square is 5 px X 5 px. So each square would have a color corresponding to the 5 px X 5 px group of pixels it swaps in for...
How do I figure out what this one color, which is best representative of the stuff it covers, is? Do I just take the R G and B numbers for each of the 25 pixels and average them? Or is there some obscure other way I should know about? What is conventionally used in "pixelation" functions, say like in photoshop?
If you want to know about the 'theory' of pixelation, read up on resampling (and downsampling in particular). Pixelation algorithms are simply downsampling an image (using some downsampling method) and then upsampling it using nearest-neighbour interpolation. Note that in code these two steps may be fused into one.
For downsampling in general, to downsample by a factor of n the image is first filtered by an appropriate low-pass filter, and then one sample out of every n is taken. An "ideal" filter to use is the sinc filter, but because of issues with implementing it, the Lanczos filter is often used as a close alternative.
However, for almost all purposes when doing pixelization, using a simple box blur should work fine, and is very simple to implement. This is just an average of nearby pixels.
If you don't need to change the output size of the image, then this means you divide the image into blocks (the big resulting pixels) which are k×k pixels, and then replace all the pixels in each block with the average value of the pixels in that block.
when the source and target grids are so evenly divisible and aligned, most algorigthms give similar results. if the grids are fixed, go for simple averages.
in other cases, especially when resizing by a small percentage, the quality difference is quite evident. the simplest enhancement over simple average is weighting each pixel value considering how much of it's contained in the target pixel's area.
for more algorithms, check multivariate interpolation
I have a reference set of n points, and another set which 'approximates' each of those points. How do I find out the absolute/percentage error between the approximation and my reference set.
Put in other words, I have a canned animation and a simulation. How do I know how much is the 'drift' between the 2 in terms of a single number? That is, how good is the simulation approximating the vertices as compared to those of the animation.
I actually do something like this for all vertices: |actual - reference|/|actual| and then average out the errors by dividing the number of verts. Is this correct at all?
Does this measurement really have to be a percentage value? I'm guessing you have one reference set, and then several sets that approximate this set and you want to pick the one that is "the best" in some sense.
I'd add the squared distances between the actual and the reference:
avgSquareDrift = sum(1..n, |actual - reference|^2) / numvertices
Main advantage with this approach, is that we dont need to take apply the square root, which is a costly operation.
If you sum the formula you have over all vertices (and then divide by the number of verts) you will have calculated the average percentage error in position for all vertices.
However, this percentage error is probably not quite what you want, because vertices closer to the origin will have a greater "percentage error" for the same displacement because their magnitude is smaller.
If you don't divide by anything at all, you will have the average drift in world units, which may be exactly what you want:
average_drift = sum(1->numvertices, |actual - reference|) / numvertices
You may want to divide by something more appropriate to your particular situation to get a meaningful unitless number. If you divide average_drift by the height of your model, you will have the error as a percentage of the model size, which could be useful.
If individual vertices are likely to have more error if they are a long distance from a vertex 'parented' to them, as could be the case if they are vertices of a jointed model, you could divide each error by the length of their parent joint to get the average error normalised for joint orientation -- i.e. what the average drift would be if each joint were of unit length:
orientation_drift = sum(1->numvertices, |actual - reference| / jointlength) / numvertices