Hi Jim. > You might want to submit it as a separate push and get credit for > fixing 4645692 (solveCubic doesn't return all answers),
Sure, that sounds good. Reading through the code I found, I spotted a few things that might have been problematic in some extremely rare cases. I've been working on making it extra robust. I think I'm pretty close to finishing. I have one question though: how fast does this have to be? I can come up with fairly reasonable examples for which both CubicCurve2D.solveCubic and the implementation I found give very inaccurate results (i.e. evaluating the cubic on the computed "roots" gives numbers as high as 1e-4). I read on the bug reports that what we should do is treat the closed form as a crude approximation and then use the Newton method to really find the roots. I like this idea (with perhaps the exception of the Newton method - I think we might be better off using something like false position, or even simply a binary search). The binary search gives results that when evaluated are as small as 1e-17 which is as close to correct as possible in double precision (because my termination condition was while(middle != start && middle != end)). That didn't even take an outrageous number of iterations - 77 was the highest I observed. > 4724552 > 4493128 > 4074742 > 4724556 > (etc. Those were just the bugs I found on the first 2 pages of a bug > database search) > Double (triple, etc.) credit - woohoo! ;-) Isn't there some sort of diminishing returns after the first duplicate ;-) Regards, Denis.
