I recently started playing an Android game called Euclidea. It teaches the basics of compass and ruler construction (geometry) and asks you to complete various tasks such as bisecting an angle or finding a circle equally spaced between four points, etc. The goal is to do so with a certain minimal number of moves.
Having never taken a geometry class, but being an experienced programmer, I was struck by the difference in the approaches I gravitate to versus the geometer's approach the game seems to be trying to teach me.
For example, I might want to approach a point by successive approximation, but that doesn't count because the game is looking for an exact solution - to say nothing of the points-penalty incurred by using constructions of dozens of moves where the game knows it can be solved by just 3 or 4.
Another example, to reach something I might start by defining a "coordinate system", perhaps a strange triangular coordinate system defined by osculating circles. In this case I do reach the exact solution, eventually, but again fail to get the most points for golfing the number of moves. This because I was thinking in layers of abstraction and drawing all the possible circles first, and then saying "oh here's the point(s) I needed" rather than just getting from A to B.
I think it would no stretch to associate the elegant/minimal geometric construction of this game with the symbolic approach the author of the original post is advocating. The Euclidea game really opened my eyes to how ingrained numeric, successive approximation is in my approach to problem solving and how it contrasts to the symbolic, geometric approach. I don't know if I'd change how I approach problem solving or programming, but I think it's helpful to be aware both that you're doing it and that it's not the only approach.
Your comment reminds me of frustrations I ran into when going the opposite direction in college.
I majored in mathematics (focusing on pure math) where the goal is typically to produce a solution which is as elegant and readable as possible. In the couple of programming classes I took for my minor, I tended to follow this same approach. If I could write a sexy three line recursive statement that solved the problem in O(n^2) rather than some convoluted nest of loops and tests that did it in O(nlogn) I wanted to go with the first one! It was really hard to make the mental shift from trying to produce something elegant and concise to something fast and memory efficient.
It's funny, I've been diving into a lot of math I haven't used in a while lately (via the Coursera "Robotics Specialization"). Since I don't particularly trust myself to do huge amounts of symbolic manipulation/integration/etc on paper, I've picked up Maxima as a CAS to try to keep track of it all. More than once, I've gotten some set of equations into a form that I'm ready to use to do numerical iteration/gradient descent/whatever, and Maxima just kind of... pops out a closed form solution for the problem I'm trying to solve.
My basic approach to straddle the symbolic/numeric divide is to keep things symbolic until the last minute and then substitute in the boundary conditions/constants/whatever at the end and see what pops out. If Maxima pops out a closed form solution, I'll analyze that geometrically to make sure it makes sense and isn't just a quirk of the specific boundary conditions I've chosen, and if it doesn't really have a closed form solution, I'll use the simplified equations and run them through a solver of whatever kind (ODE, gradient descent, etc).
Since you're into geometric constructions... I've been learning CAD with SolveSpace, which is GPL and has a constraint solver. This is very interesting code to dig into. When you apply constraints to a drawing (midpoint, point on line, parallel, perpendicular, etc..) It creates an internal algebraic expression for that constraint. You end up with a system of equations (internally only) that are constantly enforced as you manipulate a sketch. It's a hybrid approach where the constraints are represented as equations but the solutions are all computed numerically. I think you'd appreciate it.
Exact answers are nice, but sometimes you need to know whether two ellipses do or don't intersect, as fast as possible, and then do the more computationally intensive math only for the interesting cases.
For instance, if the distance between centers is greater than the sum of the major radiuses, the ellipses do not have a real area of intersection, and imaginary areas are not useful for the problem at hand, so you stop calculating and move on to the next pair. If the distance between centers is smaller than the larger minor radius, there is a real area of intersection, and you can put it on the list to calculate it later.
In seven steps, you can determine the desired answer to the limit of floating point precision faster than the exact symbolic answer determined by actually solving the quartic as a "single step", which is actually encapsulating quite a lot of multiplications, and at least six distinct conditional cases.
But on the other hand, the rapid approximation is the work of one afternoon, and can be debugged one step at a time, while the exact answer is a doctoral-level thesis.
And if you're drawing your ellipses on the surface of an ellipsoid, like the WGS84 geoid, the value of approximations becomes even greater, because the exact answers will come from an even higher-order polynomial equation.
In this, the "don't care" part of the problem space is always used to make the shape of the solution as simple as possible. So when you always care about exact answers, discovered elegantly, you're actually discarding the means to make the solution more elegant in way you might not have realized.
I don't remember the whole thing, and I couldn't take it with me, but what I can recall is this:
It is much more important to determine whether there is a real intersection at all, than it is to determine how big the area of intersection is.
Calculate distance between centers.
Add both major radiuses.
If distance >= sum, skip this pair. Intersection area is entirely imaginary.
If distance < max( minor radiuses ), the pair definitely has a real intersection. Put it on the list for later and check the next pair. Upper bound, min( ellipse areas ); lower bound zero.
Find the maximum extents of each ellipse, when projected onto the segment between centers. If the sum is greater than the distance, there is a real intersection. Put it on the list and go on to the next pair.
Then there was a bit of a race against time through increasingly esoteric tests that relied heavily on the calculations from previous steps. The goal was to produce a list of ellipses, sorted by decreasing real area of intersection greater than zero with a single reference ellipse. So if there was only one on the list, you didn't even need to calculate area. That was the answer, and you're done.
At some point, the reference ellipse was transformed into a circle at the origin, with the center of the comparison ellipse on the x axis. Some tests only used one quadrant of an ellipse at a time. Each test refined the bounds on the fraction of the reference ellipse that could be in the intersection, so again, if those limits were enough to sort the list, the area calculation was skipped.
If there were still enough ambiguous tests, then finally you calculate the points of intersection. For zero or one, the area is exactly the area of the smaller ellipse. For four, first approximation is the area of the quadrilateral, as minimum. For three, the area of the triangle, as minimum. Two was the worst case, because then you needed to pick out a third point for the triangle, which was probably one of the four where a major axis intersected an ellipse. If you needed a maximum area, it was the smallest circle enclosing the points. Each test either increased the lower bound, or decreased the upper bound, until there was no more overlap in the sorted list.
After all that, if the list was still not clearly ordered, you finally calculated and added chord areas to get exact results. You couldn't really get here with real-world test data, so now you had to invent test data specifically to make it this far, to be sure that if any real-world data set ever does execute this branch, it ends up ordered correctly. But I don't think we ever got funding to bulletproof it. Customer was fine with the possibility that a tiny fraction of inputs might end up ordered incorrectly, so long as the wrong answer came out quickly.
Clearly, if all the areas had to be calculated exactly, it would have been more efficient to just do that from the start. But that wasn't the problem.
Having never taken a geometry class, but being an experienced programmer, I was struck by the difference in the approaches I gravitate to versus the geometer's approach the game seems to be trying to teach me.
For example, I might want to approach a point by successive approximation, but that doesn't count because the game is looking for an exact solution - to say nothing of the points-penalty incurred by using constructions of dozens of moves where the game knows it can be solved by just 3 or 4.
Another example, to reach something I might start by defining a "coordinate system", perhaps a strange triangular coordinate system defined by osculating circles. In this case I do reach the exact solution, eventually, but again fail to get the most points for golfing the number of moves. This because I was thinking in layers of abstraction and drawing all the possible circles first, and then saying "oh here's the point(s) I needed" rather than just getting from A to B.
I think it would no stretch to associate the elegant/minimal geometric construction of this game with the symbolic approach the author of the original post is advocating. The Euclidea game really opened my eyes to how ingrained numeric, successive approximation is in my approach to problem solving and how it contrasts to the symbolic, geometric approach. I don't know if I'd change how I approach problem solving or programming, but I think it's helpful to be aware both that you're doing it and that it's not the only approach.