I have a program written in vb.net that creates a graph and draws various lines on it parsed from an XML file. Each line defines if points on the graph must be above or below it.
Simply put, I am looking for a way to find the closest number ABOVE and BELOW a certain point.
So say we have a straight line {(0,0)(1,1)(2,2)(3,3)}
and a point we want to validate (1.5,4) Say this point needs to be ABOVE the line.
Also, i should mention that the line may not always be a straight line but have many segments representing a curve.
I suspect the easiest way to do this is to find the 2 points on the line surrounding our point on the x axis, get the slope between them and then interpolate.
So I tried this:
pointBelow = validationLine.points.Aggregate(Function(x, y) If(Math.Abs(x.X - paramPoint.XValue) < Math.Abs(y.X - paramPoint.YValues(0)), x, y))
pointAbove = validationLine.points.Aggregate(Function(x, y) If(Math.Abs(x.X - paramPoint.XValue) < Math.Abs(y.X - paramPoint.YValues(0)), x, y))
As you can see, these will obviously both return the same value, so I would like to know how I can search for the closest number in a list BELOW a given value, then do the same thing but search ABOVE that value.
P.S. it is also possible that the point we are validating may be at the exact same place on the x axis as one of the vertices on our line and I am looking for a solution that will solve this regardless.
Sorry but it's too long to comment.
It depends on the line that you are comparing it to... if your line is a function, it means it will never 'go backwards', and you just have to compare the Y-values of the point and your line at point X.
If it's not a function, then it's harder, and maybe you should ask that question on a math Q&A site, like https://mathematica.stackexchange.com/
Related
I am new to LabVIEW and I am trying to read a code written in LabVIEW. The block diagram is this:
This is the program to input x and y functions into the voltage input. It is meant to give an input voltage in different forms (sine, heartshape , etc.) into the fast-steering mirror or galvano mirror x and y axises.
x and y function controls are for inputting a formula for a function, and then we use "evaluation single value" function to input into a daq assistant.
I understand that { 2*(|-Mpi|)/N }*i + -Mpi*pi goes into the x value. However, I dont understand why we use this kind of formula. Why we need to assign a negative value and then do the absolute value of -M*pi. Also, I don`t understand why we need to divide to N and then multiply by i. And finally, why need to add -Mpi again? If you provide any hints about this I would really appreciate it.
This is just a complicated way to write the code/formula. Given what the code looks like (unnecessary wire bends, duplicate loop-input-tunnels, hidden wires, unnecessary coercion dots, failure to use appropriate built-in 'negate' function) not much care has been given in writing it. So while it probably yields the correct results you should not expect it to do so in the most readable way.
To answer you specific questions:
Why we need to assign a negative value and then do the absolute value
We don't. We can just move the negation immediately before the last addition or change that to a subtraction:
{ 2*(|Mpi|)/N }*i - Mpi*pi
And as #yair pointed out: We are not assigning a value here, we are basically flipping the sign of whatever value the user entered.
Why we need to divide to N and then multiply by i
This gives you a fraction between 0 and 1, no matter how many steps you do in your for-loop. Think of N as a sampling rate. I.e. your mirrors will always do the same movement, but a larger N just produces more steps in between.
Why need to add -Mpi again
I would strongly assume this is some kind of quick-and-dirty workaround for a bug that has not been fixed properly. Looking at the code it seems this +Mpi*pi has been added later on in the development process. And while I don't know what the expected values are I would believe that multiplying only one of the summands by Pi is probably wrong.
I was trying to solve Google Code Jam problems and there is one of them that I don't understand. Here is the question (World Finals 2013 - problem C): https://code.google.com/codejam/contest/2437491/dashboard#s=p2&a=2
And here follows the problem analysis: https://code.google.com/codejam/contest/2437491/dashboard#s=a&a=2
I don't understand why we can use binary search. In order to use binary search the elements have to be sorted. In order words: for a given element e, we can't have any element less than e at its right side. But that is not the case in this problem. Let me give you an example:
Suppose we do what the analysis tells us to do: we start with a left bound angle of 90° and a right bound angle of 0°. Our first search will be at angle of 45°. Suppose we find that, for this angle, X < N. In this case, the analysis tells us to make our left bound 45°. At this point, we can have discarded a viable solution (at, let's say, 75°) and at the same time there can be no more solutions between 0° and 45°, leading us to say that there's no solution (wrongly).
I don't think Google's solution is wrong =P. But I can't figure out why we can use a binary search in this case. Anyone knows?
I don't understand why we can use binary search. In order to use
binary search the elements have to be sorted. In order words: for a
given element e, we can't have any element less than e at its right
side. But that is not the case in this problem.
A binary search works in this case because:
the values vary by at most 1
we only need to find one solution, not all of them
the first and last value straddle the desired value (X .. N .. 2N-X)
I don't quite follow your counter-example, but here's an example of a binary search on a sequence with the above constraints. Looking for 3:
1 2 1 1 2 3 2 3 4 5 4 4 3 3 4 5 4 4
[ ]
[ ]
[ ]
[ ]
*
I have read the problem and in the meantime thought about the solution. When I read the solution I have seen that they have mostly done the same as I would have, however, I did not thought about some minor optimizations they were using, as I was still digesting the task.
Solution:
Step1: They choose a median so that each of the line splits the set into half, therefore there will be two provinces having x mines, while the other two provinces will have N - x mines, respectively, because the two lines each split the set into half and
2 * x + 2 * (2 * N - x) = 2 * x + 4 * N - 2 * x = 4 * N.
If x = N, then we were lucky and accidentally found a solution.
Step2: They are taking advantage of the "fact" that no three lines are collinear. I believe they are wrong, as the task did not tell us this is the case and they have taken advantage of this "fact", because they assumed that the task is solvable, however, in the task they were clearly asking us to tell them if the task is impossible with the current input. I believe this part is smelly. However, the task is not necessarily solvable, not to mention the fact that there might be a solution even for the case when three mines are collinear.
Thus, somewhere in between X had to be exactly equal to N!
Not true either, as they have stated in the task that
You should output IMPOSSIBLE instead if there is no good placement of
borders.
Step 3: They are still using the "fact" described as un-true in the previous step.
So let us close the book and think ourselves. Their solution is not bad, but they assume something which is not necessarily true. I believe them that all their inputs contained mines corresponding to their assumption, but this is not necessarily the case, as the task did not clearly state this and I can easily create a solvable input having three collinear mines.
Their idea for median choice is correct, so we must follow this procedure, the problem gets more complicated if we do not do this step. Now, we could search for a solution by modifying the angle until we find a solution or reach the border of the period (this was my idea initially). However, we know which provinces have too much mines and which provinces do not have enough mines. Also, we know that the period is pi/2 or, in other terms 90 degrees, because if we move alpha by pi/2 into either positive (counter-clockwise) or negative (clockwise) direction, then we have the same problem, but each child gets a different province, which is irrelevant from our point of view, they will still be rivals, I guess, but this does not concern us.
Now, we try and see what happens if we rotate the lines by pi/4. We will see that some mines might have changed borders. We have either not reached a solution yet, or have gone too far and poor provinces became rich and rich provinces became poor. In either case we know in which half the solution should be, so we rotate back/forward by pi/8. Then, with the same logic, by pi/16, until we have found a solution or there is no solution.
Back to the question, we cannot arrive into the situation described by you, because if there was a valid solution at 75 degrees, then we would see that we have not rotated the lines enough by rotating only 45 degrees, because then based on the number of mines which have changed borders we would be able to determine the right angle-interval. Remember, that we have two rich provinces and two poor provinces. Each rich provinces have two poor bordering provinces and vice-versa. So, the poor provinces should gain mines and the rich provinces should lose mines. If, when rotating by 45 degrees we see that the poor provinces did not get enough mines, then we will choose to rotate more until we see they have gained enough mines. If they have gained too many mines, then we change direction.
The path I'm using has no curves; just a series of connected points.
The method I'm currently using involves iterating through the NZBezierPathElement components of the path and getting each point, but this is clumsy - especially because I have to save the last point to get each new distance. If any of you know of a better method, that would be very much appreciated.
Your algorithm sounds exactly right - the length of the path is the sum of the lengths between each pair of points. It's hard to see why you think this is "clumsy", so here is the algorithm in pseudo code just in case:
startPoint <- point[1]
length <- 0
repeat with n <- 2 to number of points
nextPoint <- point[n]
length <- length + distanceBetween(startPoint, nextPoint)
startPoint <- nextPoint // hardly clumsy
end repeat
Maybe you're doing it differently?
The notion of current point is fundamental to NSBezierPath (and SVG, turtle graphics, etc.), with its relative commands (e.g. move relative, line relative) - there is no escaping it!
Im writing an application that will calculate the focal length of a camera based on the lines that can be seen in the photograph. For instance, if you take a picture of a room, the ceiling line can be one straight line (horizontal), the floor can be another straight line (horizontal) and the wall can be the third straight line (vertical). The aim of my application is for the user to select these straight lines one at a time, and once 3 lines are selected, the lines will need to be intersected to form a "triangle".
My problem is that because the lines selected don't necessarily intersect, how do I extend a line until it intersects with another line? In my application I have the start and end positions of all 3 user selected lines (Vector2's). But how do I extend each line until it intersect with the other 2 lines?
If anyone needs an image to clarify what I mean, send me a reply and Ill upload one to Flickr
Say each line is represented by two vector2's: v1 and v2, all the points in that given line will be given by the equation: p(x) = v1 + x(v2-v1). Each line will have its equation in this form. For each pair of lines, you will have to find the value of x that gives you the same p(x) for both equations; p(x) will be the point of intersection of those two lines.
Sounds like you need to do 3 things.
Extend the lines to the end of the picture (in your code, not visible to the user).
Calculate line intersection. See this answer: detecting line intersection
on the user's end, extend the lines until the intersection point if there is one on the picture.
I have a projectile that I would like to pass through specific coordinates at the apex of its path. I have been using a superb equation that giogadi outlined here, by plugging in the velocity values it produces into chipmunk's cpBodyApplyImpulse function.
The equation has one drawback that I haven't been able to figure out. It only works when the coordinates that I want to hit have a y value higher than the cannon (where my projectile starts). This means that I can't shoot at a downward angle.
Can anybody help me find a suitable equation that works no matter where the target is in relation to the cannon?
As pointed out above, there isn't any way to make the apex be lower than the height of the cannon (without making gravity work backwards). However, it is possible to make the projectile pass through a point below the cannon; the equations are all here. The equation you need to solve is:
angle = arctan((v^2 [+-]sqrt(v^4 - g*(x^2+2*y*v^2)))/g*x)
where you choose a velocity and plug in the x and y positions of the target - assuming the cannon is at (0,0). The [+-] thing means that you can choose either root. If the argument to the square root function is negative (an imaginary root) you need a larger velocity. So, if you are "in range" you have two possible angles for any particular velocity (other than in the maximum range 45 degree case where the two roots should give the same answer).
I suspect one trajectory will tend to 'look' much more sensible than the other, but that's something to play around with once you have something working. You may want to stick with the apex grazing code for the cases where the target is above the cannon.