Is there a function to prevent more than onde edge between two vertex in mxGraph? Actually I'm using mxGraph.multiplicities, however it limit the number of edges between all types of vertex and not between on type of edge.
Usually you will want to accomplish this via setting setMultigraph to false.
However if you need to distinguish between different kinds of vertices or even having edges with a direction (allowing to connect both A->B and B->A), the way I did it in the past was by overloading getEdgeValidationError, where your logic can determine if and when 2 vertices can be connected.
Related
I am writing some CUDA code for finding the 3 parameters of a circle (centre X,Y & radius) from many (m) measurements of positions around the perimeter.
As m > 3 I am (successfully) using Singular Value Decomposition (SVD) for this purpose (using the cuSolver library). Effectively I am solving m simulaneous equations with 3 unknowns.
However, not all of my perimeter positions are valid (say q of them), and so I have to go through my initial set of m measurements and remove the q invalid ones. This involves moving the size m data array from the card to the host, processing linearly to remove the q invalid entries and then re loading the smaller (m-q) array back onto the card...
My question is; if I were to set all terms on both sides of the q invalid equations to zero, could I just run the m equations (including the zeros) through my SVD analysis (without the data transfer etc) or would this cause other problems?
My instinct tells me that this is a bit like applying weights to the data but instinct and SVD are not terms that sit well together in my experience...
I am hesitant just to try this as I don't know if it will work in some cases and not in others...
I have tested the idea by inserting rows of zeros into my matrix. The solution that I am getting is not significantly affected by this.
So I am answering my own question with a non-rigorous Yes it is OK do do this.
If anybody has a more rigorous or more considered answer I would very much like to hear it.
I'm dealing with rooted, directed, potentially cyclic graphs. Each vertex in the graph has a label, which might or might not be unique. Edges do not have labels. The graph has a designated root vertex from which every vertex is reachable. The order of the edges outgoing from a vertex is relevant.
For my purposes, a vertex is equal to another vertex if they share the same label, and if their outgoing edges are also considered equal (and are in the same order). Two edges are equal if they have the same direction and if the vertices at their corresponding ends are equal.
Because of the equality rules above, a graph can contain multiple "sections" that are effectively equal. For example, in the graph below, there are two isomorphic sections containing vertices with labels {1, 2, 3, 4}. The root of the graph is vertex 0.
(source: graphonline.ru)
I need to be able to identify sections that are identical, and then remove all duplication, without changing the "meaning" of the graph (with regard to the equality rules above). Using the above example as input, I need to produce this:
(source: graphonline.ru)
Is there a known way of doing this within polynomial time?
The solution that ended up working was to essentially run the recursive equality check against every pair of vertices with the same label.
Let S = all pairs of vertices with the same label
For each s in S:
Compare the two vertices a and b in s by recursively comparing their children
If they compare as equal, take all edges in the graph pointing to b, and point them to a instead
According to the help file
http://www.inside-r.org/packages/cran/igraph/docs/erdos.renyi.game
the erdos.renyi.game function is supposed to accept n=The number of vertices in the graph and m= the number of edges in the graph as input parameters.
The dataset I am working with has 6 vertices and 25 edges, so when i try
g = erdos.renyi.game(6,25)
I get an error
Error in .Call("R_igraph_erdos_renyi_game", as.numeric(n), as.numeric(type1), :
At games.c:569 : Invalid probability given, Invalid value
Not sure where I am going wrong, appreciate any advise on this topic.
Just use erdos.renyi.game(n=6, m=25) erdos.renyi.game(6, 12, type="gnm") and it will work. You have to define explicitly that the second parameter is for the value of m and not p.
erdos.renyi.game(n, p.or.m, type=c("gnp", "gnm"),
directed = FALSE, loops = FALSE, ...)
n
The number of vertices in the graph.
p.or.m
Either the probability for drawing an edge between two arbitrary vertices (G(n,p) graph), or the number of edges in the graph (for G(n,m) graphs).
type
The type of the random graph to create, either gnp (G(n,p) graph) or gnm (G(n,m) graph).
directed
Logical, whether the graph will be directed, defaults to FALSE.
loops
Logical, whether to add loop edges, defaults to FALSE.
...
Additional arguments, ignored.
Details
In G(n,p) graphs, the graph has ‘n’ vertices and for each edge the probability that it is present in the graph is ‘p’.
In G(n,m) graphs, the graph has ‘n’ vertices and ‘m’ edges, and the ‘m’ edges are chosen uniformly randomly from the set of all possible edges. This set includes loop edges as well if the loops parameter is TRUE. random.graph.game is an alias to this function.
Example:
g <- erdos.renyi.game(1000, 1/1000)
degree.distribution(g)
I've wrote a little wavefront's .obj file parser (3d model format), I'm able to display the geometry correctly but am having problems texturing it correctly.
The only way I'm able to get a correct texture is by dividing the model in my 3d editor, exporting and parsing it this way.. ie: I'm no longer sharing vertex data, each triangle is on it own so my indexBuffer's array looks like this [0,1,2,3,4,5,6...] which I want to avoid.
The correct texture/inefficient geometry (No reusing of vertices: 36 vertices):
Correct http://imageshack.us/a/img29/2242/textureright.jpg
Wrong texture/right topology (Sharing data: 8 vertices only = efficient):
Wrong http://imageshack.us/a/img443/6160/texturewrong.jpg
I thought to try and separate the UVs buffer from the indexBuffer destined to the vertices but didn't found a way to do it; if indeed it is doable.
I also messed with the agal code but haven't achieved any results.
The desired end is being able to pass different UVs coordinates to the same vertex in context of the triangle being drawn atm.
What to do?
Thanks. (I'm new to 3d programming)
It might seem like you need just one vertex per 'vertex location' of your model but, from what I understand of an .obj parser, you need to define your vertices around the FACES. This means you may have multiple vertices for some locations - depending on how many faces adjoin that location - but the pay off is you can have different UV coordinates for those vertices in the same location.
I'd suggest altering your parser to create vertices based on the faces they define rather than solely their positions. I know this bumps up the number of vertices but, from what I've read, it's unavoidable if you need different UVs for the same vertex location.
So, unfortunately, I'm pretty sure your first option is the way to go.
it seems like your welding operation is wrong. For welding vertices you must be sure that positions, UV-coordinates, normals and tangents(if you need them) are equal
"Dead reckoning is the process of estimating one's current position based upon a previously determined position and advancing that position based upon known or estimated speeds over elapsed time, and course." (Wikipedia)
I'm currently implementing a simple server that makes use of dead reckoning optimization, which minimizes the updates required by making logical assumptions on both the clients and the server.
The objects controlled by users can be said to be turning, or not turning. This presents an issue with dead reckoning (the way I see it.)
For example, say you have point A in time defined by [position, velocity, turning: left/right/no]. Now you want point B after t amount of time. When not turning, the new position is easy to extrapolate. The resulting direction is also easy to extrapolate. But what about when these two factors are combined? The direction of the velocity will be changing along a curve as the object is turning over t amount of time.
Should I perhaps go with another solution (such as making the client send an update for every new direction rather than just telling the server "I'm turning left now")?
This is in a 2D space, by the way, for the sake of simplicity.
For simplicity let's say that your vehicles have a turning radius r that's independant of speed. So to compute the new position given the initial coords and the time:
compute the distance (that's velocity * time)
compute how much you turned (that's distance / (2*pi*r))
add that arc to the original position.
The last steps needs elaboration.
Given the angle a computed in step 2, if you started at (0,0) with a due north heading (i.e. pi/2 radians) and are turning left then your new positions is: (rcos(a)-1, rsin(a)).
If your original heading was different, say it was "b", then simply rotate the new position accordingly, i.e. multiply by this rotation matrix:
[ cos b , -sin b ]
[ sin(b), cos(b) ]
Finally, add the initial position and you're done. Now you only need to send an update if you change the velocity or turning direction.
Well, I think "turning: left/right/no" is insufficient to determine position B - you also need to know the arc at which the turn is being made. If you are turning left along a circular path of radius 1, you will end up at a different place than if you are turning along a circular path of radius 10, even though your initial position, velocity, and direction of turn will all be the same.
If making the client send an update for every new direction and treating them as linear segments is an option, that is going to be a much easier calculation to make. You can simply treat each new report from the client as a vector, and sum them. Calculating a bunch of curves is going to be more complex.