I've been trying to develop a simple app that calculates the equation of a curve using information given by the user.
For example, let's suppose the user has the equation of a circle and the equation of an ellipse, and he wants to know the intersection points.
Mathematically speaking, this is a quite simple problem, but i can't figure out how to tell Xcode to solve that system.
I've looked into the Accelerate framework, and i found the "dgesv" function of Lapack. This would be a perfect solution for a system of lines, but what about more complex systems like the one i've stated before?
I was even wondering how to calculate the tangent line of a curve, and other similar geometry problems.
For example, let's suppose the user has the equation of a circle and the equation of an ellipse, and he wants to know the intersection points. Mathematically speaking, this is a quite simple problem, but i can't figure out how to tell Xcode to solve that system.
The problem of intersecting a circle and an ellipse in general involves solving a fourth degree polynomial equation. You can break it down to third degree, but square roots alone won't suffice. So I'd say that's not really a “quiet simple problem”. That being said, some numeric libraries do support algorithms for finding the real or complex roots of a univariate polynomial. So you'd eliminate one of your variables (e.g. using resultants or Gröbner bases) and then feed the resulting polynomial to that. Not sure what libraries would be most suitable in the Objective C world. But a question asking to suggest a specific library would be deemed off-topic anyway, so use the keywords I mentioned to find something that suites your needs.
I was even wondering how to calculate the tangent line of a curve, and other similar geometry problems.
The tangent direction is simply orthogonal to the gradient of the implicit form. In other words, describe your curve not parametrically as x=f(t) and y=g(t) but instead implicitely as f(x,y)=0. In case of a circle that would look like x2+y2+ax+by+c=0. Then compute the partial derivatives with respect to x and y. That's 2x+a and 2y+b. So (2x+a, 2y+b) is perpendicular to the circle, and (2y+b, -2x-a) is tangential. Not sure what you'd consider similar to this.
Related
I'm working on a problem that will eventually run in an embedded microcontroller (ESP8266). I need to perform some fairly simple operations on linear equations. I don't need much, but do need to be able work with points and linear equations to:
Define an equations for lines either from two known points, or one
point and a gradient
Calculate a new x,y point on an equation line that is a specific distance from another point on that equation line
Drop a perpendicular onto an equation line from a point
Perform variations of cosine-rule calculations on points and triangle sides defined as equations
I've roughed up some code for this a while ago based on high school "y = mx + c" concepts, but it's flawed (it fails with infinities when lines are vertical), and currently in Scala. Since I suspect I'm reinventing a wheel that's not my primary goal, I'd like to use someone else's work for this!
I've come across CGAL, and it seems very likely it's capable of all this and more, but I have two questions about it (given that it seems to take ages to get enough understanding of this kind of huge library to actually be able to answer simple questions!)
It seems to assert some kind of mathematical perfection in it's calculations, but that's not important to me, and my system will be severely memory constrained. Does it use/offer memory efficient approximations?
Is it possible (and hopefully easy) to separate out just a limited subset of features, or am I going to find the entire library (or even a very large subset) heading into my memory limited machine?
And, I suppose the inevitable follow up: are there more suitable libraries I'm unaware of?
TIA!
The problems that you are mentioning sound fairly simple indeed, so I'm wondering if you really need any library at all. Maybe if you post your original code we could help you fix it--your problem sounds like you need to redo a calculation avoiding a division by zero.
As for your point (2) about separating a limited number of features from CGAL, giving the size and the coding style of that project, from my experience that will be significantly more complicated (if at all possible) than fixing your own code.
In case you want to try a simpler library than CGAL, maybe you could try Boost.Geometry
Regards,
This is again a question about the CGAL 3D surface mesher.
http://doc.cgal.org/latest/Surface_mesher/index.html#Chapter_3D_Surface_Mesh_Generation
With the definition
Surface_3 surface(sphere_function, // pointer to function
Sphere_3(CGAL::ORIGIN, 64.0)); // bounding sphere
(as given too in the example code) I define an implicit surface given by 'sphere function' and a Sphere_3 of radius 8.
The difference is now, that the zeros of 'sphere function' are (contrary to its now misleading name) no longer bounded and inside Sphere_3. Instead 'sphere_function' represents an unbounded surface (think of x^2 + y^2 - z^2 - 1 = 0) and my intention is to triangularize its part that is in the Sphere_3.
In my examples up to now this worked quite well, if only for some annoying problem, I do not know how to overcome: The boundaries, where the implicit surface meets the Sphere, are very "rough" or "jagged" in a more than acceptable amount.
I already tried the 'Manifold_with_boundary_tag()', but it gave no improvements.
One road to improve the output that I am contemplating, is converting the triangulated mesh (a C2t3) into a Polyhedron_3 and this in a Nef_polyhedron and intersect that with a Nef_polyhedron well approximating a slightly smaller Sphere. But this seems a bit like shooting with cannons for sparrows, nevertheless I have currently no better idea and googling gave me also no hint. So my question: What to do about this problem? Can it be done with CGAL (and moderate programming effort) or is it necessary or better to use another system?
(Just for explanation for what I need this: I try to develop a program that constructs 3D-printable models of algebraic surfaces and having a smooth and also in the boundaries smooth triangulation is my last step that is missing before I can hand the surface over to OpenSCAD to generate a solid body of constant thickness).
The only solution I see is to use the 3D Mesh Generation with sharp feature preservation and no criteria on the cells. You will have to provide the intersection of the bounding sphere with the surface yourself.
There is one example with two intersecting spheres in the user manual.
Does anyone know of a library (any language, though preferably python/R/matlab) for parametric curve fitting, i.e. if you have a set of points in the plane {(x_i,y_i)} you can find parameter estimates for two (polynomial) functions y=f_y(t) and x=f_x(t) for some (arc-length?) parametrization t? This is especially useful if you have some multi-valued function (e.g. a circle) for which regression wouldn't work.
There are a number of papers detailing algorithms (e.g. 'Parametric Curve Fitting', Grossman 1971) but I can't find any corresponding software that would save a lot of time coding up.
For future reference, I ended up using the princurve library in R based on principal curves by Trevor Hastie.
CGAL's manual suggests that there is no such implementation, if you know anything more let me know
N
This sounds like two questions, rather than one:
(1) How to intersect two planar cubic Bezier curves
(2) How to offset a planar cubic Bezier curve
I don't understand the statement that "there is no implementation". Maybe they just mean that there is no implementation in CGAL.
Both problems require numerical methods or approximation -- neither one has a closed-form solution.
But they are both well-known problems with many workable (approximate) solutions available. Searching for "intersect Bezier curves" or "offset Bezier curve" will return dozens of useful references and code samples.
If you want to solve these problems using CGAL ...
(1) Intersection. This is basically a root-finding problem, and CGAL has a bivariate root finder called AlgebraicKernel_d_2::Solve_2.
(2) Offsetting. Could perhaps be done using the Minkowski sum functions. Look at approximated_offset_2, for example. The result will be polygonal, but that might be good enough for your purposes. This is really a curve approximation problem, for which CGAL has no tools, as far as I can see.
For anyone interested:
"There is a CGAL implementation of an exact arrangement of Bezier curves ( http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Arrangement_on_surface_2/Chapter_main.html#Subsection_32.6.7 )" cheers Iddo Hanniel
anyone have experience doing this? when i say imaginary i mean the square root of negative one. how would i graph this?
http://www.wolframalpha.com/input/?i=sqrt(-1)
Or more specifically, http://www.wolframalpha.com/input/?i=plot+sqrt(-1)
Complex numbers have many applications. They are useful for being able to store two properties (the real and imaginary parts) that behave sensibly when you apply standard math operators on them, like multiplication. Many problems become easy to solve by transforming them to the complex number domain, perform an operation on them that is easy to calculate, then transforming them back.
A good example is calculating the behavior of an electronic circuit that has reactive components. The impedance of a coil in the complex domain is jwL, of a capacitor is 1/jwC (w = omega). Driven with a signal in the complex domain, you can easily calculate the response. In this particular case, graphing the response is meaningful by mapping the real part on the X-axis and the imaginary part on the Y-axis. The length of the vector is the amplitude, the angle is the phase.
The Laplace transform is another complex domain transformation, based on Euler's identity. It has a very useful graphical representation too, plotting the complex roots of the equation within the unity circle allows predicting the stability of a feedback system.
These kind of transforms are popular because they simplify the math or their graphical representation are easy to interpret. Whether yours are equally useful really depends on what the transform does.