I have a set of equations. I also have a set of values and the results for the equation.
Something like:
a + b + c = x
and some allocation might be:
1 + 1 + 1 = 3
2 + 3 + 4 = 9
However, the actual equations are much longer and may contain some functions, for example logarithms.
I now need to alter the result of a given set in a way that (1) the equation becomes equal to a specific value xx and (2) the parameters change as little as possible.
I thought I could solve this as a CSP by altering the eqation to
(a + ax) + (b + bx) + (c + cx) = xx
where a, b and c correspond to the old values and ax, bx and cx are the differences which need to be applied to the corresponding old values. And xx will be the result I want the equation to have. Note that a, b, c, xa, xb, cx etc. are all integer values and xx will always be within a certain distance to x, i.e. xx - d < x < xx + d.
In a CSP a, b, c and xx would be treated as Problem facts, ax, bx, cx would be treated as Planning variable and the equation (a + ax) + (b + bx) + (c + cx) = xx would be a hard constraint.
Minimizing all of ax, ab, ac would be a soft constraint.
I don't really see a Planning entity here.
global HardSoftScoreHolder scoreHolder;
rule "changeIsBad"
when
DeltaVariable($delta : delta)
then
scoreHolder.addSoftConstraintMatch(kcontext, -Math.abs(delta));
end
rule "equationMustBeEqual"
// No idea?
end
But I can't figure out how to go on from here. Is Optaplanner feasible for this kind of problem? It seems all PlanningVariables have to come from a List and have to be instances, whereas I only have integer values. Is my model correct?
You can wrap each integer variable in an entity class, like this:
#PlanningEntity
public class MyEntity {
private Integer myVariable;
#PlanningVariable(...)
public Integer getMyVariable() {...}
...
}
Additionally, use a planning entity range to define the range of each variable (because it differs per entity), see official docs section "4.3.5.2.2. ValueRangeProvider on a planning entity" (and don't use SwapMove's, only ChangeMove's I guess).
But overall, I am not 100% sure if this is the right tool for the job. I would be interested to know what your experience with this use case results into.
PS: Starting from 6.1.0.Beta1 (not yet released, but nightlies are available), we have IntValueRange as documented in nightly docs in section "4.3.5.2.4. ValueRangeFactory", which is more efficient for these kinds of use cases.
Related
I constructed a finite automata for the language L of all strings made of the symbols 0, 1 and 2 (Σ = {0, 1, 2}) where the last symbol is not smaller than the first symbol. E.g., the strings 0, 2012, 01231 and 102 are in the language, but 10, 2021 and 201 are not in the language.
Then from that an GNFA so I can convert to RE.
My RE looks like this:
(0(0+1+2)* )(1(0(1+2)+1+2)* )(2((0+1)2+2))*)
I have no idea if this is correct, as I think I understand RE but not entirely sure.
Could someone please tell me if it’s correct and if not why?
There is a general method to convert any DFA into a regular expression, and is probably what you should be using to solve this homework problem.
For your attempt specifically, you can tell whether an RE is incorrect by finding a word that should be in the language, but that your RE doesn't accept, or a word that shouldn't be in the language that the RE does accept. In this case, the string 1002 should be in the language, but the RE doesn't match it.
There are two primary reasons why this string isn't matched. The first is that there should be a union rather than a concatenation between the three major parts of the language (words starting with 0, 1 and 2, respectively:
(0(0+1+2)*) (1(0(1+2)+1+2)*) (2((0+1)2+2))*) // wrong
(0(0+1+2)*) + (1(0(1+2)+1+2)*) + (2((0+1)2+2))*) // better
The second problem is that in the 1 and 2 cases, the digits smaller than the starting digit need to be repeatable:
(1(0 (1+2)+1+2)*) // wrong
(1(0*(1+2)+1+2)*) // better
If you do both of those things, the RE will be correct. I'll leave it as an exercise for you to follow that step for the 2 case.
The next thing you can try is find a way to make the RE more compact:
(1(0*(1+2)+1+2)*) // verbose
(1(0*(1+2))*) // equivalent, but more compact
This last step is just a matter of preference. You don't need the trailing +1+2 because 0* can be of zero length, so 0*(1+2) covers the +1+2 case.
You can use an algorithm but this DFA might be easy enough to convert as a one-off.
First, note that if the first symbol seen in the initial state is 0, you transition to state A and remain there. A is accepting. This means any string beginning with 0 is accepted. Thus, our regular expression might as well have a term like 0(0+1+2)* in it.
Second, note that if the first symbol seen in the initial state is 1, you transition to state B and remain in states B and D from that point on. You only leave B if you see 0 and you stay out of B as long as you keep seeing 0. The only way to end on D is if the last symbol you saw was 0. Therefore, strings beginning with 1 are accepted if and only if the strings don't end in 0. We can have a term like 1(0+1+2)*(1+2) in our regular expression as well to cover these cases.
Third, note that if the first symbol seen in the initial state is 2, you transition to state C and remain in states C and E from that point on. You leave state C if you see anything but 2 and stay out of B until you see a 2 again. The only way to end up on C is if the last symbol you saw was 2. Therefore, strings beginning with 2 are accepted if and only if the strings end in 2. We can have a term like 2(0+1+2)*(2) in our regular expression as well to cover these cases.
Finally, we see that there are no other cases to consider; our three terms cover all cases and the union of them fully describes our language:
0(0+1+2)* + 1(0+1+2)*(1+2) + 2(0+1+2)*2
It was easy to just write out the answer here because this DFA is sort of like three simple DFAs put together with a start state. More complicated DFAs might be easier to convert to REs using algorithms that don't require you understand or follow what the DFA is doing.
Note that if the start state is accepting (mentioned in a comment on another answer) the RE changes as follows:
e + 0(0+1+2)* + 1(0+1+2)*(1+2) + 2(0+1+2)*2
Basically, we just tack the empty string onto it since it is not already generated by any of the other parts of the aggregate expression.
You have the equivalent of what is known as a right-linear system. It's right-linear because the variables occur on the right hand sides only to the first degree and only on the right-hand sides of each term. The system that you have may be written - with a change in labels from 0,1,2 to u,v,w - as
S ≥ u A + v B + w C
A ≥ 1 + (u + v + w) A
B ≥ 1 + u D + (v + w) B
C ≥ 1 + (u + v) E + w C
D ≥ u D + (v + w) B
E ≥ (u + v) E + w C
The underlying algebra is known as a Kleene algebra. It is defined by the following identities that serve as its fundamental properties
(xy)z = x(yz), x1 = x = 1x,
(x + y) + z = x + (y + z), x + 0 = x = 0 + x,
y0z = 0, w(x + y)z = wxz + wyz,
x + y = y + x, x + x = x,
with a partial ordering relation defined by
x ≤ y ⇔ y ≥ x ⇔ ∃z(x + z = y) ⇔ x + y = y
With respect to this ordering relation, all finite subsets have least upper bounds, including the following
0 = ⋁ ∅, x + y = ⋁ {x, y}
The sum operator "+" is the least upper bound operator.
The system you have is a right-linear fixed point system, since it expresses the variables on the left as a (right-linear) function, as given on the right, of the variables. The object being specified by the system is the least solution with respect to the ordering; i.e. the least fixed point solution; and the regular expression sought out is the value that the main variable has in the least fixed point solution.
The last axiom(s) for Kleene algebras can be stated in any of a number of equivalent ways, including the following:
0* = 1
the least fixed point solution to x ≥ a + bx + xc is x = b* a c*.
There are other ways to express it. A consequence is that one has identities such as the following:
1 + a a* = a* = 1 + a* a
(a + b)* = a* (b a*)*
(a b)* a = a (b a)*
In general, right linear systems, such as the one corresponding to your problem may be written in vector-matrix form as 𝐪 ≥ 𝐚 + A 𝐪, with the least fixed point solution given in matrix form as 𝐪 = A* 𝐚. The central theorem of Kleene algebras is that all finite right-linear systems have least fixed point solutions; so that one can actually define matrix algebras over Kleene algebras with product and sum given respectively as matrix product and matrix sum, and that this algebra can be made into a Kleene algebra with a suitably-defined matrix star operation through which the least fixed point solution is expressed. If the matrix A decomposes into block form as
B C
D E
then the star A* of the matrix has the block form
(B + C E* D)* (B + C E* D)* C E*
(E + D B* C)* D B* (E + D B* C)*
So, what this is actually saying is that for a vector-matrix system of the form
x ≥ a + B x + C y
y ≥ b + D x + E y
the least fixed point solution is given by
x = (B + C E* D)* (a + C E* b)
y = (E + D B* C)* (D B* a + b)
The star of a matrix, if expressed directly in terms of its components, will generally be huge and highly redundant. For an n×n matrix, it has size O(n³) - cubic in n - if you allow for redundant sub-expressions to be defined by macros. Otherwise, if you in-line insert all the redundancy then I think it blows up to a highly-redundant mess that is exponential in n in size.
So, there's intelligence required and involved (literally meaning: AI) in finding or pruning optimal forms that avoid the blow-up as much as possible. That's a non-trivial job for any purported matrix solver and regular expression synthesis compiler.
An heuristic, for your system, is to solve for the variables that don't have a "1" on the right-hand side and in-line substitute the solutions - and to work from bottom-up in terms of the dependency chain of the variables. That would mean starting with D and E first
D ≥ u* (v + w) B
E ≥ (u + v)* w C
In-line substitute into the other inequations
S ≥ u A + v B + w C
A ≥ 1 + (u + v + w) A
B ≥ 1 + u u* (v + w) B + (v + w) B
C ≥ 1 + (u + v) (u + v)* w C + w C
Apply Kleene algebra identities (e.g. x x* y + y = x* y)
S ≥ u A + v B + w C
A ≥ 1 + (u + v + w) A
B ≥ 1 + u* (v + w) B
C ≥ 1 + (u + v)* w C
Solve for the next layer of dependency up: A, B and C:
A ≥ (u + v + w)*
B ≥ (u* (v + w))*
C ≥ ((u + v)* w)*
Apply some more Kleene algebra (e.g. (x* y)* = 1 + (x + y)* y) to get
B ≥ 1 + N (v + w)
C ≥ 1 + N w
where, for convenience we set N = (u + v + w)*. In-line substitute at the top-level:
S ≥ u N + v (1 + N (v + w)) + w (1 + N w).
The least fixed point solution, in the main variable S, is thus:
S = u N + v + v N (v + w) + w + w N w.
where
N = (u + v + w)*.
As you can already see, even with this simple example, there's a lot of chess-playing to navigate through the system to find an optimally-pruned solution. So, it's certainly not a trivial problem. What you're essentially doing is synthesizing a control-flow structure for a program in a structured programming language from a set of goto's ... essentially the core process of reverse-compiling from assembly language to a high level language.
One measure of optimization is that of minimizing the loop-depth - which here means minimizing the depth of the stars or the star height. For example, the expression x* (y x*)* has star-height 2 but reduces to (x + y)*, which has star height 1. Methods for reducing star-height come out of the research by Hashiguchi and his resolution of the minimal star-height problem. His proof and solution (dating, I believe, from the 1980's or 1990's) is complex and to this day the process still goes on of making something more practical of it and rendering it in more accessible form.
Hashiguchi's formulation was cast in the older 1950's and 1960's formulation, predating the axiomatization of Kleene algebras (which was in the 1990's), so to date, nobody has rewritten his solution in entirely algebraic form within the framework of Kleene algebras anywhere in the literature ... as far as I'm aware. Whoever accomplishes this will have, as a result, a core element of an intelligent regular expression synthesis compiler, but also of a reverse-compiler and programming language synthesis de-compiler. Essentially, with something like that on hand, you'd be able to read code straight from binary and the lid will be blown off the world of proprietary systems. [Bite tongue, bite tongue, mustn't reveal secret yet, must keep the ring hidden.]
I'm reading the section of the full adder in Digital Design by Morris Mano and I can't seem to figure out how it got from equation A to equation B.
From a full adder's truth table and k-map using inputs x, y, and z, the carry out term, C, is defined as:
C = xy + xz + yz (equation A)
I could understand the above, but in order to leverage the xor already used by the summation term of x, y, and z, the book redefines C as:
C = z(xy' + x'y) + xy = xy'z + x'yz + xy (equation B)
How are these two equivalent? I've tried to derive one from the other on paper but I'm not able to come up with the steps in between.
Sorry my comment (which I removed) was hastily stated.
Consider the following logic table (I'm using ^ to represent XOR for brevity):
The results of xy + xz + yz are the same as xy + (x ^ y)z because, for the first 6 cases, the value of x + y and x ^ y are the same. For the last two cases where they are different, the xy term being OR'ed in is 1 which makes their difference irrelevant to the final value.
Given the line segment AB, how do I find the point Pn where the normal to AB passes through the point P? I also need to know if there is no normal that passes through the point (e.g. the point Q).
If R is any point on the normal line passing through P (different from P), then Pn is the point where AB and PR intersect.
One way to generate point R is to rotate segment AB by 90 degrees and then translate it so that A coincides with P. The the translated B is your R:
Rx = Px + (By - Ay)
Ry = Py - (Bx - Ax)
Once you have your point R, it becomes a simple line-line intersection problem, which will give you your Pn (the formulas can be simplified for a specific case of perpendicular lines).
Then you can easily check whether Pn lies between A and B or not.
P.S. Note that solution provided in #MBo's answer is a more direct and efficient one (and if you combine and simplify/optimize the formulas required for my answer you will eventually arrive at the same thing). What I describe above might make good sense if you already have a primitive function that calculates the intersection of two lines, say,
find_intersection(Ax, Ay, Bx, By, Cx, Cy, Dx, Dy)
// Intersect AB and CD
In that case finding Pn becomes a simple one-liner
Pn = find_intersection(Ax, Ay, Bx, By, Px, Py, Px + (By - Ay), Py - (Bx - Ax))
But if you don't have such primitive function at your disposal and/or care for making your code more efficient, then you might want to opt for a more direct dedicated sequence of calculations like the one in #MBo's answer.
Find vectors
AB = (B.X-A.X, B.Y-A.Y)
AP = (P.X-A.X, P.Y-A.Y)
Projection of P to AB is:
APn = AB * (AB.dot.AP) / (AB.dot.AB);
where .dot. is scalar product
In coordinates:
cf = ((B.X-A.X)*(P.X-A.X)+(B.Y-A.Y)*(P.Y-A.Y))/((B.X-A.X)^2+(B.Y-A.Y)^2)
if cf < 0 or cf > 1 then projection lies outside AB segment
Pn.X = A.X + (B.X-A.X) * cf
Pn.Y = A.Y + (B.Y-A.Y) * cf
I found this code snippet on raywenderlich.com, however the link to the explanation wasn't valid anymore. I "translated" the answer into Swift, I hope you can understand, it's actually quite easy even without knowing the language. Could anyone explain what exactly is going on here? Thanks for any help.
class func linesCross(#line1: Line, line2: Line) -> Bool {
let denominator = (line1.end.y - line1.start.y) * (line2.end.x - line2.start.x) -
(line1.end.x - line1.start.x) * (line2.end.y - line2.start.y)
if denominator == 0 { return false } //lines are parallel
let ua = ((line1.end.x - line1.start.x) * (line2.start.y - line1.start.y) -
(line1.end.y - line1.start.y) * (line2.start.x - line1.start.x)) / denominator
let ub = ((line2.end.x - line2.start.x) * (line2.start.y - line1.start.y) -
(line2.end.y - line2.start.y) * (line2.start.x - line1.start.x)) / denominator
//lines may touch each other - no test for equality here
return ua > 0 && ua < 1 && ub > 0 && ub < 1
}
You can find a detailed segment-intersection algorithm
in the book Computational Geometry in C, Sec. 7.7.
The SegSegInt code described there is available here.
I recommend avoiding slope calculations.
There are several "degenerate" cases that require care: collinear segments
overlapping or not, one segment endpoint in the interior of the other segments,
etc. I wrote the code to return an indication of these special cases.
This is what the code is doing.
Every point P in the segment AB can be described as:
P = A + u(B - A)
for some constant 0 <= u <= 1. In fact, when u=0 you get P=A, and you getP=B when u=1. Intermediate values of u will give you intermediate values of P in the segment. For instance, when u = 0.5 you will get the point in the middle. In general, you can think of the parameter u as the ratio between the lengths of AP and AB.
Now, if you have another segment CD you can describe the points Q on it in the same way, but with a different u, which I will call v:
Q = C + v(D - C)
Again, keep in mind that Q lies between C and D if, and only if, 0 <= v <= 1 (same as above for P).
To find the intersection between the two segments you have to equate P=Q. In other words, you need to find u and v, both between 0 and 1 such that:
A + u(B - A) = C + v(D - C)
So, you have this equation and you have to see if it is solvable within the given constraints on u and v.
Given that A, B, C and D are points with two coordinates x,y each, you can open the equation above into two equations:
ax + u(bx - ax) = cx + v(dx - cx)
ay + u(by - ay) = cy + v(dy - cy)
where ax = A.x, ay = A.y, etc., are the coordinates of the points.
Now we are left with a 2x2 linear system. In matrix form:
|bx-ax cx-dx| |u| = |cx-ax|
|by-ay cy-dy| |v| |cy-ay|
The determinant of the matrix is
det = (bx-ax)(cy-dy) - (by-ay)(cx-dx)
This quantity corresponds to the denominator of the code snippet (please check).
Now, multiplying both sides by the cofactor matrix:
|cy-dy dx-cx|
|ay-by bx-ax|
we get
det*u = (cy-dy)(cx-ax) + (dx-cx)(cy-ay)
det*v = (ay-by)(cx-ax) + (bx-ax)(cy-ay)
which correspond to the variables ua and ub defined in the code (check this too!)
Finally, once you have u and v you can check whether they are both between 0 and 1 and in that case return that there is intersection. Otherwise, there isn't.
For a given line the slope is
m=(y_end-y_start)/(x_end-x_start)
if two slopes are equal, the lines are parallel
m1=m1
(y1_end-y_start)/(x1_end-x1_start)=(y2_end-y2_start)/(x2_end-x2_start)
And this is equivalent to checking that the denominator is not zero,
Regarding the rest of the code, find the explanation on wikipedia under "Given two points on each line"
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to write a reliable method to retrieve the answer to the following scenario...
Given a line segment AB and an arbitrary point C, how would I find the closest point to A on a line parallel to AB that passes through point C? (Reliable mentioned above refers to the algorithms ability to find D while allowing the coordinates for A, B, and C to be completely arbitrary and unpredictable. I've ran in to a quite a few solutions that I was not able to adapt to all possible scenarios, sadly...)
In the case of the data displayed in the picture below, how would I reliably find the x,y coordinates of D?
A = <425, 473>
B = <584, 533>
C = <371, 401>
D = <???, ???>
Knowing that AB and CD are parallel, that obviously means the slopes are the same.
I have tried many different formulas to no avail and have been working on this for weeks now. I'm stumped!
It's a minimization problem.
In general, the Euclidean distance between two points (A and B) in N dimensional space is given by
Dist(A,B) = sqrt((A1-B1)^2 + ... + (AN-BN)^2)
If you need to find the minimum distance between a space curve A(t) (a 1-dimensional object embedded in some N dimensional space) and a point B, then you need to solve this equation:
d Dist(A(t),B) / dt = 0 // (this is straightforward calculus: we're at either a minimum or maximum when the rate of change is 0)
and test that set of roots (t1, t2, etc) against the distance function to find which one yields the smallest value of D.
Now to find the equation for the parallel line passing through C in y=mx+b form:
m = (Ay - By)/(Ax-Bx)
b = Cy - mCx
Let's write this in space-curve form as and plug it into our formula from part 1:
Dist(D(t),A) = sqrt((t-Ax)^2 + (m*t+b-Ay)^2)
taking our derivative:
d Dist(D(t),A)/ dt = d sqrt((t-Ax)^2 + (m*t+b-Ay)^2) / dt
= (t + (m^2)*t - Ax + m*b - m*Ay)/sqrt(t^2 + (m^2)t^2 - 2*t*Ax + 2*m*t*b - 2*m*t*Ay + (Ax)^2 + (Ay)^2 + b^2 - 2*b*Ay )
= ((1+m^2)*t - Ax + m*b - m*Ay)/sqrt((1+m^2)*(t^2) + 2*t*(m*b - Ax - m*Ay) + (Ax)^2 + (Ay)^2 + b^2 - 2*b*Ay )
Settings this equal to 0 and solving for t yields:
t = (Ax-m*b+m*Ay)/(1+m^2)
as the only root (you can check this for yourself by substituting back in and verifying that everything cancels as desired).
Plugging this value of t back in to our space curve yields the following:
D=<(Ax-m*b+m*Ay)/(1+m^2),b+m*(Ax-m*b+m*Ay)/(1+m^2)>
You can then plug in your expressions for m and b if you want an explicit solution in terms A,B,C, or if you only want the numerical solution you can just compute it as a three step process:
m = (Ay - By)/(Ax-Bx)
b = Cy - mCx
D=<(Ax-m*b+m*Ay)/(1+m^2),b+m*(Ax-m*b+m*Ay)/(1+m^2)>
This will be valid for all cases with parallel straight lines. One caveat when implementing it as a numerical (rather than analytical) code: if the lines are oriented vertically, calculating m = (Ay-By)/(Ax-Bx) will result in division by 0, which will make your code not work. You can throw in a safety valve as follows:
if( Ax == Bx) {
D = <Cx,Ay>
} else {
// normal calculation here
}
For serious numerical work, you probably want to implement that in terms of tolerances rather than a direct comparison due to roundoff errors and all that fun stuff (i.e., abs(Ax-Bx) < epsilon, rather than Ax==Bx)