[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
dlila at redhat.com
Wed Dec 15 01:11:09 UTC 2010
> 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.
> (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 ;-)
More information about the 2d-dev