For example:
Cardinality and optionality are
orthogonal properties of a
relationship. You can specify that a
relationship is optional, even if you
have specified upper and/or lower
bounds. This means that there do not
have to be any objects at the
destination, but if there are then the
number of objects must lie within the
bounds specified.
What exactly does "orthogonal" mean? I bet it's just a fancy soundig nerd-style word for something that could be expressed a lot easier to understand for average people ;)
From wikipedia:
In mathematics, two vectors are
orthogonal if they are perpendicular,
i.e., they form a right angle. The
word comes from the Greek ὀρθός
(orthos), meaning "straight", and
γωνία (gonia), meaning "angle".
Anyone?
In the quoted context above you could substitute the word "independent" or "unrelated" for "orthogonal".
Items/concepts/values etc.. that are Orthogonal means that one does not constrain the other, so you can establish one item/concept/value without regards for how other orthogonal items are set.
Loosely speaking, orthogonal means independent.
Specifically in 2d space an orthogonal line is one with bends at 90 degrees to each other.
Related
I am writing a simple GUI library and am using quadtrees to determine which, if any, objects are interacted with during a mouse event. I was looking through a number of quadtree libraries on github and they all contained a method for adding a rectangular object to a quadtree.
The method, in all cases, simply checked to see if the rectangle intersected with the given quadtree:
return quadtree.x2 >= rect.x1
and quadtree.x1 <= rect.x2
and quadtree.y2 >= rect.y1
and quadtree.y1 <= rect.y2
However, this gives an unwanted result in one of the simplest cases: Imagine a 100x100 square area. I place four 50x50 square objects into the area with coordinates (0,0), (0,50), (50,0), and (50,50). If these objects had been placed into a 100x100 quadtree with a maximum capacity of one object, I would (visually) expect that the first layer of the quadtree would split and that the four resulting trees would each exactly contain one of the squares.
If I use the above method to determine which tree the squares are placed into, though, I find that each object intersects with all four trees. This would cause each of the trees to rapidly split until the maximum depth is reached.
The only way I see to avoid this is to use two checks:
return (quadtree.x2 > rect.x1
and quadtree.x1 < rect.x2
and quadtree.y2 > rect.y1
and quadtree.y1 < rect.y2)
or (quadtree.x2 == rect.x1
and quadtree.x1 == rect.x2
and quadtree.y2 == rect.y1
and quadtree.y1 == rect.y2)
(in the simplest case. Larger objects would have to be viewed within a bounding box since, for example, an object with coordinates (0,0), w=100, h=100 would belong in the upper-left quadtree as well.)
I could also calculate the overlap between the rectangles and the quadtrees to see if it's non-zero.
Am I missing something? It seems like this should be an ideal situation for a quadtree, yet, in most implementations, it's a huge mess.
I wouldn't call this an ideal situation, because the four rectangles overlap by a fractional amount. For example, if we assume a (fictional) floating precision of 10^(-10), every 'point' is actually a small rectangle with 10^(-10) length, and thus the rectangles overlap by 10^(-10). This is why you get the deep tree.
But I also think the tree could be improved with a slightly modified overlap checking. With your code, the sub-nodes all overlap by a tiny amount. It would work better with excluding the minimum (or maximum values), for example:
return quadtree.x2 >= rect.x1
and quadtree.x1 < rect.x2
and quadtree.y2 >= rect.y1
and quadtree.y1 < rect.y2
So the lower left coordinate of a node is actually outside of that node. This would at least avoid points turning up in several nodes (such as the point (50,50)), and the lower left rectangle would be stored in only one node.
A line segment can be defined by a pair of points. There are well-known algorithms for finding whether two line segments in 2D space intersect. But what if we make it a bit trickier by adding a width to the line?
Imagine you have a line segment defined by a pair of points and a width. What you end up with is a rectangle whose sides are not necessarily aligned with the coordinate axes. (So you can't use the standard "rectangle overlap" functions.) What would be the best way to determine if two such line segments overlap?
I'd recommend to use The Method of Separating Axes to find out whether the rotated rectangles (thick line segments) overlap. This method is fast and simple.
A line with a width can be regarded as two parallel lines, separated by the width that you're talking about. So two lines which each have a width corresponds to four lines. Just work out whether any of these 4 lines intersect and you're done, aren't you?
Update: A comment points out that this will miss overlapping parallel lines. I think that's all it will miss, so that case could be handled as a special case.
Is the proper HTML entity for giving dimensions ×? I want to be semantically correct, but that begs the question, is listing a dimension as 2" x 3" even semantic? If the x represents "by", would I use the letter x or ×?
In my code I've been using 2″ × 3″, or 2″ × 3″. The non-breaking spaces are to prevent the dimension from being wrapped, as per the suggestions found in The Elements of Typographic Style Applied to the Web.
×
Unicode: U+00D7 MULTIPLICATION SIGN
HTML: ×, ×
CSS: \00d7
See the Wikipedia article about the multiplication sign:
In mathematics, the symbol × (read as times or multiplied by) is primarily used to denote the […]
Geometric dimension of an object, such as noting that a room is 10×12 feet in area.
Depending on the context, the math element (for MathML) element could be of use.
The proper question is which character should be used. The use of entity references for characters adds no semantics. There is no formal standard on denoting dimensions, but clearly this is about multiplication rather than the Latin letter x, so “x” (×) is the correct character.
In practice, this is more of an orthography and typography question than about “semantic web”. Search engines, browsers, etc., don’t really care; it’s the human readers that matter.
You're doing everything correctly. I believe × here is [semantically] related to the operation of multiplication, i.e. in fact you write the area by specifying two dimensions.
I'm trying to diagnose and fix a bug which boils down to X/Y yielding an unstable result when X and Y are small:
In this case, both cx and patharea increase smoothly. Their ratio is a smooth asymptote at high numbers, but erratic for "small" numbers. The obvious first thought is that we're reaching the limit of floating point accuracy, but the actual numbers themselves are nowhere near it. ActionScript "Number" types are IEE 754 double-precision floats, so should have 15 decimal digits of precision (if I read it right).
Some typical values of the denominator (patharea):
0.0000000002119123
0.0000000002137313
0.0000000002137313
0.0000000002155502
0.0000000002182787
0.0000000002200977
0.0000000002210072
And the numerator (cx):
0.0000000922932995
0.0000000930474444
0.0000000930582124
0.0000000938123574
0.0000000950458711
0.0000000958000159
0.0000000962901528
0.0000000970442977
0.0000000977984426
Each of these increases monotonically, but the ratio is chaotic as seen above.
At larger numbers it settles down to a smooth hyperbola.
So, my question: what's the correct way to deal with very small numbers when you need to divide one by another?
I thought of multiplying numerator and/or denominator by 1000 in advance, but couldn't quite work it out.
The actual code in question is the recalculate() function here. It computes the centroid of a polygon, but when the polygon is tiny, the centroid jumps erratically around the place, and can end up a long distance from the polygon. The data series above are the result of moving one node of the polygon in a consistent direction (by hand, which is why it's not perfectly smooth).
This is Adobe Flex 4.5.
I believe the problem most likely is caused by the following line in your code:
sc = (lx*latp-lon*ly)*paint.map.scalefactor;
If your polygon is very small, then lx and lon are almost the same, as are ly and latp. They are both very large compared to the result, so you are subtracting two numbers that are almost equal.
To get around this, we can make use of the fact that:
x1*y2-x2*y1 = (x2+(x1-x2))*y2 - x2*(y2+(y1-y2))
= x2*y2 + (x1-x2)*y2 - x2*y2 - x2*(y2-y1)
= (x1-x2)*y2 - x2*(y2-y1)
So, try this:
dlon = lx - lon
dlat = ly - latp
sc = (dlon*latp-lon*dlat)*paint.map.scalefactor;
The value is mathematically the same, but the terms are an order of magnitude smaller, so the error should be an order of magnitude smaller as well.
Jeffrey Sax has correctly identified the basic issue - loss of precision from combining terms that are (much) larger than the final result.
The suggested rewriting eliminates part of the problem - apparently sufficient for the actual case, given the happy response.
You may find, however, that if the polygon becomes again (much) smaller and/or farther away from the origin, inaccuracy will show up again. In the rewritten formula the terms are still quite a bit larger than their difference.
Furthermore, there's another 'combining-large&comparable-numbers-with-different-signs'-issue in the algorithm. The various 'sc' values in subsequent cycles of the iteration over the edges of the polygon effectively combine into a final number that is (much) smaller than the individual sc(i) are. (if you have a convex polygon you will find that there is one contiguous sequence of positive values, and one contiguous sequence of negative values, in non-convex polygons the negatives and positives may be intertwined).
What the algorithm is doing, effectively, is computing the area of the polygon by adding areas of triangles spanned by the edges and the origin, where some of the terms are negative (whenever an edge is traversed clockwise, viewing it from the origin) and some positive (anti-clockwise walk over the edge).
You get rid of ALL the loss-of-precision issues by defining the origin at one of the polygon's corners, say (lx,ly) and then adding the triangle-surfaces spanned by the edges and that corner (so: transforming lon to (lon-lx) and latp to (latp-ly) - with the additional bonus that you need to process two triangles less, because obviously the edges that link to the chosen origin-corner yield zero surfaces.
For the area-part that's all. For the centroid-part, you will of course have to "transform back" the result to the original frame, i.e. adding (lx,ly) at the end.
This question will be asked in a specific form, but applies to a more general question, how to name unordered set items without implying any sort of structure.
In terms of graph theory, a connected, undirected graph will contain vertices that are connected via edges.
When creating an edge class with two member variables that are vertices, representing the two vertices that the edge connects, there was a difficulty in describing the two variables that did not include some form of implied structure.
Consider
class Edge{
Vertex v1;
Vertex v2;
}
or
class Edge{
Vertex left;
Vertex right;
}
or
class Edge{
Vertex a;
Vertex b;
}
{v1, v2} implies order and a larger possible size than two, though an edge only has two ends.
{a, b} is similar to {v1,v2}, only substiting different symbols.
{left, right} or {up, down} imply direction, which may be counter-intuitive when there is not necessarily any spatial reference to the graph, since raw graphs are pure abstractions.
{start, end} would work for a directed graph but seems arbitrary in an undirected graph.
The closest that I can consider is:
class Edge{
Vertex oneEnd;
Vertex otherEnd;
}
but that feels kludgey.
What name complies with good practice for such variables without implying any form of direction, ordering, or structure?
I'd go with Edge { Vertex v1; Vertex v2; }. I don't think that the user of your code will interpret the numerical suffixes as the order, but simply as differentiators. What if your unordered set contained 10 or 100 items, as could be the case with for example a polygon structure? I'm sure the most intuitive solution would be to use numerical indices/suffixes when naming the items.