I am creating a graphing calculator in Java as a project for my programming class. There are two main components to this calculator: the graph itself, which draws the line(s), and the equation evaluator, which takes in an equation as a String and... well, evaluates it.
To create the line, I create a Path2D.Double instance, and loop through the points on the line. To do this, I calculate as many points as the graph is wide (e.g. if the graph itself is 500px wide, I calculate 500 points), and then scale it to the window of the graph.
Now, this works perfectly for most any line. However, it does not when dealing with singularities.
If, when calculating points, the graph encounters a domain error (such as 1/0), the graph closes the shape in the Path2D.Double instance and starts a new line, so that the line looks mathematically correct. Example:
(source: imagesocket.com)
However, because of the way it scales, sometimes it is rendered correctly, sometimes it isn't. When it isn't, the actual asymptotic line is shown, because within those 500 points, it skipped over x = 2.0 in the equation 1 / (x-2), and only did x = 1.98 and x = 2.04, which are perfectly valid in that equation. Example:
(source: imagesocket.com)
In that case, I increased the window on the left and right one unit each.
My question is: Is there a way to deal with singularities using this method of scaling so that the resulting line looks mathematically correct?
I myself have thought of implementing a binary search-esque method, where, if it finds that it calculates one point, and then the next point is wildly far away from the last point, it searches in between those points for a domain error. I had trouble figuring out how to make it work in practice, however.
Thank you for any help you may give!
You could use interval arithmetic ( http://en.wikipedia.org/wiki/Interval_arithmetic ) and calculate the interval of the function on each interval [x(i), x(i+1)]. If the resulting interval is infinite, skip that line segment. Speed-wise this should only be a couple times slower than just evaluating the function.
I think you are mostly on the right track.
I don't think figure 2 is mathematically incorrect.
For bonus points, you should have a routine which checks the diff between two consecutive values y1 & y2, and if it is greater than a threshold, inserts more points between y1 and y2, until no diff is greater than the threshold. If this iterative rountine is unable to get out of the while loop after 10 iterations or so, then that indicates presence of a singularity, and you can remove the plot between y1 and y2. That will give you figure 1.
If morpehus's solution is too slow for you, you can consider all the absolute values of jumps between two consecutive function values, and try to identifies large outliers -- these will be the infinite jumps.
If you decide to try this, and need help, leave a comment here.
I finally figured out a way to have singularities graphed properly.
Essentially what I do is for every point on the graph, I check to see if it is inside the visible graphing clip. If I hit a point on the graph that is outside the visible clip, I graph that first point outside the clip, and then stop graphing any invisible points after that.
I keep calculating points and checking if they are inside the visible clip, not graphing ones that are outside the clip. Once I hit a point that is inside the clip again, I graph the point before that point, and then graph the current point.
I keep doing this until I've graphed the entire line. This creates the illusion that the entire line is begin drawn, when only the visible parts are.
This won't work if the window is large and the actual graph size in pixels is small, but it does suffice for me.
Related
Hello I am currently trying to move objects in my libgdx android application. The main issue is that i can't move my objects unaffected by the fps. Up to now i was using the delta time like this:
public void move(float delta){
this.setX(this.getX() + this.speed.x * delta); //moving just along x axis to keep it simple
this.speed.x += 1 * delta //some acceleration;
}
The move method is called on each frame. Imagine I have two devices, one with 1fps and one with 2fps, and now we move a object for 1 second with a start speed of zero. The object wouldn't have moved on the first device while it would have on the second one.
To sum up if the fps is increased the object moves slightly faster.
Up to now this little differnce was no problem but in this case it is important that the object moves 100% synchronous, because i want to measure the time the objects needs to reach some point.
So what is the right way to go here?
Actually... the way you are moving your objects when multiplying it by delta makes it FPS independent already :) Let see below graphic to understand it better:
open the picture in full size!
Atlhough you are adding some value to x twice per second when having 2FPS the value is twice smaller than when having 1FPS what means that in the every integer point of time the x of the object will be the same.
The situation you are afraid of would be true if you wouldn't multiply it by delta - then every second you would add the same value twice when having 2FPS than when having 1FPS - it means that after one second the object would be twice far more when having 2FPS than when having 1FPS.
Only thing affect by the FPS is rendering smoothness - but if you are refreshing the screen twice times more it is obvious that it will be more smooth.
By the way - if you are using Scene2D and looking for some other ways to move object look at Actions especially MoveToAction. Take a look at this tutorial to get some information.
Thanks to m.antkowicz provided informations i could do some better research and found some interesting artices. According to my current knowlege it is pretty hard move objects with dynamic accelleration based on the deltatime. The right way to go is to use fixed time stamps.
I m working on a android app, which takes X-Y co-ordinates as input using openGL. The Problem is when we draw slow (fling slow) the input co-ordinate points are more and input co-ordinate points are less on fast fling.
I would like to know to the reason why it happens, So as to optimize and have same number of co-ordinates on touch with any speed/motion.
Since stackoverflow requires 10 reputation i could not upload images.. pls see the links below for images
fast moment : https://www.dropbox.com/s/rvdlz79mr2iowtx/fast_moment.png?dl=0
slow moment : https://www.dropbox.com/s/n2px7wcjw62wfi8/slow_moment.png?dl=0
The reason for this is how touch events are working. Your touch screen may report new touch coordinates but your system needs to collect those data which generally happens every X milliseconds. This results in getting N points per second rather then N points per distance made.
If you wish to have a relatively same amount of points per distance you should do a bit of an extra processing on the points you get. To begin with when the press is dragged you should always remember the last point received and when a new one comes you should compute the distance from the last one and if the distance is not long enough simply discard the point.
Note that this is only a first step but some more might need to be introduced so I suggest you create some class that will handle this for you and report to your target system.
So the first issue with this system you will most likely introduce is you will lose the last point sometimes because it might be too close to the one before it, so you need to handle the last point specifically.
Then if the drag was too fast you might find yourself having too little points in which case you should use some interpolation. It might be enough to simply interpolate lineally (an average of two points) but generally you would want to create a nice curve interpolated between at least 3 points to get a nice curve.
So what I suggest in general is to create a trace class that will hold all the points you receive from touch events (until the finger is lifted). Then on every point received you should analytically generate the new array of points from the ones gotten by the events and report them to the target system.
Since in the digital world a real collision almost never happens, we will always have a situation where the "colliding" balls overlap.
How to put back balls in situation where they collide perfectly without overlap?
I would solve this problem with a posteriori approach (in two dimensions).
In short I have to solve this equation for t:
Where:
is a number that answers to the question: how many frames ago
did the collision happen perfectly?
is the center of the first ball
is the center of the second ball
and are their velocities.
but the solution from WolframAlpha is too complicated (I changed the name of the velocities but essentially does not change anything).
It looks complicated because it's the full solution, not just the simplified polynomial form of it. Multiply everything out and gather the constant, t, and t^2 terms, and you'll find that it becomes just at^2 + bt + c = 0. From there you can just use the quadratic formula.
Also, if you want to keep things simple, do them with vector math. There's no reason here to separate out the x and y coordinates; vector addition and dot products are all you need.
Finally, all that matters is the relative position and relative velocity. Pretend one circle is at the origin and stationary, and apply the difference to the other ball. That doesn't change the answer, but it does reduce the number of variables you're wrangling.
So I'm doing the project of an introduction to Java course and it seems that I chose something that goes way beyond what I'm able to do. :P
Any help would be greatly appreciated. This is what I'm having problems with:
You have a cursor that is controlled by a player (goes forward or
turns 90°) which leaves a colored line as it goes. If you manage to go
over your own line and close a polygon of any shape (only right angles
though), its surface changes color into the color of your line.
I can detect when this situation arises but I am kind of lost as how to actually fill the correct polygon just closed. I can't seem to imagine an algorithm that would cover any case possible.
I looked at the Scanline fill algorithm but I think it would start having problems by the time there are already some polygons already filled in the map.
The Floodfill algorithm would be perfect if I had a way of finding a point inside the polygon, but, as there are many different possibilities, I can't think of a general rule for this.
I'm using an array 2x2 of integers where each color is represented by a number.
Does anyone have an idea on how to approach this problem?
If you can detect the situation then this can be solved in very simple manner. The question is which point to choose as start point for floodfill. The simple answer is: try all of them. Of course it makes a sense to start only with points adjacent to the one where your cursor is located. In this case you will have at most 8 points to check. Even better - at least 2 of them are definitely painted already if current point forms a polygon.
So you have 8 points to check. Launch floodfill 8 times starting from each of those points.
Two things which you probably should keep in mind:
You should try filling the area in cloned version of your field in order to be able to get back if floodfill will not find a polygon.
Launching floodfill second time and later you should reuse this cloned version of your field to see whether it was filled there. This will allow you to check every point at most once and this will make your 8 floodfills almost as fast as 1 floodfill.
Check this question, using Graphics2 and Polygon to fill an arbitrary polygon: java swing : Polygon fill color problem
Finding out whether a point is inside or outside a polygon: http://en.wikipedia.org/wiki/Point_in_polygon
Make sure you use double buffering. If you set individual pixels and don't use double buffering the component may redraw after every pixel was set.
My question is, will the code given in http://pietschsoft.com/post/2008/07/Virtual-Earth-Polygon-Search-Is-Point-Within-Polygon.aspx work to find a point in one of areas mentioned in
below file (page 7-9):
http://www.weather.gov/directives/sym/pd01008006curr.pdf
looking forward,
A point-in-polygon algorithm usually just counts the number of times it crosses a line by "drawing" one out in any particular direction. It would then know if it's in the polygon or not by knowing how many times it crossed that line (even number it was outside, odd number it is inside). The code on that site looks like it just flips a boolean instead of adding to a counter but it's the same thing.
I must confess I have not read the PDF you linked too (too long!) but I've not come across an instance where the algorithm fails.
One tip might be to draw a rough square around the outermost extremeties of the polygon first and check whether it falls within that to avoid having to test each point).
I believe it will fail in some cases. The algorithm you linked to, which is correct for planar geometry, is incorrect for spherical geometry. Consider the rectangles which cross the 180th meridian, e.g. the rectangle labelled "M". The algorithm would consider that rectangle as covering the americas, Africa, and Europe, but not Asia or the Pacific.