Very nice! How does it compare to CubicCurve.solveCubic() (which I know
has issues with the 2 root case, but I got it from a "reliable source" -
some textbook on Numerical Recipes)?
Also, one area that I had issues with the version I used in CC2D was
that it chose a hard cutoff to classify the number of points and
floating point errors might cause a given cubic to jump over that point
despite the fact that the equation was of the other form. Hopefully
that jumping between root counts only happens when two roots are very
close to each other so that the choice is between listing "N" or
"N+epsilon and N-epsilon" - I can live with that inaccuracy, but it
seemed like the version in CC2D might choose between "it's either a
single root of 4.25, or three roots of -127.3, 23.5, and 42.6" and I
would scratch my head and think - wow, what a difference a bit made!
Luckily I don't think we actually ever relied on CC2D.solveCubic for
correctness in any of our code, but it would be nice to fix it if a more
stable method is available.
...jim
On 12/13/2010 12:23 PM, Denis Lila wrote:
Hi again.
I found an implementation of a closed form cubic root solver
(from graphics gems):
http://read.pudn.com/downloads21/sourcecode/graph/71499/gems/Roots3And4.c__.htm
I did some micro benchmarks, and it's about 25% slower than the one I have.
I'm thinking we should use it anyway because it's much better in every
other way: it finds all roots, it doesn't make its callers give it a root
array that is longer than the total number of roots, and most importantly,
it doesn't fail because of an iteration upper bound. From my testing, I noticed
that this happens too frequently for comfort in my cubicRootsInAB. I haven't
noticed any rendering artifacts caused by this, but I also haven't tried
rendering every possible curve and it's better to prevent bugs than fix them.
What do you think?
Regards,
Denis.
