Evaluate the use of a different method of calculating regression

[reilleya]

Custom grains ended up being implemented in a way that would allow the use of a geometry library like shapely to calculate regression, which will likely be faster than the current method of finding contours. The current level of performance is acceptable, but erosive burning will require calculating many times the current number of contours which will slow things down significantly. Start by evaluating the results and performance of a library like shapely.

[adam-aitoumez]

Running a couple test cases, I don't see a meaningful difference in burning area as a function of burned distance for finocyl grains as burn increment decreases or number of contours increases. Tried 30 contours and burn increment dx = 0.01 on a finocyl grain, yielded the same results as 150 contours and dx = 0.001. Both cases were run with a map dimension of 1000. Would be wise to do a more robust analysis using several geometries, map sizes, number of contours, and burn increments, but the quick and dirty first pass indicates it shouldn't make much of a difference.

To speed things up the number of calls to getters like getCorePerimeter() can be reduced by caching tabular data for port area, perimeter, etc using a fairly coarse burn increment, and then doing interpolated lookup of those values as needed during internal ballistics computation.

[reilleya]

Sounds good. I was planning to use memoization to log calculated values as each slice of a grain would go through approximately the same shapes at different times. I think it might still be worth it to do a direct comparison between shapely and the current method, but it probably isn't too pressing.

[reilleya]

https://stackoverflow.com/questions/32772638/python-how-to-get-the-x-y-coordinates-of-a-offset-spline-from-a-x-y-list-of-poi/34011390#34011390