Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

2010-12-28 Thread Jim Graham

Correction...

On 12/28/2010 3:00 PM, Jim Graham wrote:

math. (Though it begs the question - is "-q/sqrt(-p^3)" more accurate
than "-q/(p*sqrt(-p)"? If p is < 1 then the cube is an even smaller
number, does that matter?)


Make that "-q/(-p*sqrt(-p))", or "q/(p*sqrt(-p))"...

...jim


Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

2010-12-28 Thread Jim Graham

Hi Denis,

I'm attaching a test program I wrote that compares the old and new 
algorithms.


Obviously the old one missed a bunch of solutions because it classified 
all solutions as 1 or 3, but the new one also sometimes misses a 
solution.  You might want to turn this into an automated test for the 
bug (and maybe use it as a stress test with a random number generator).


I think one problem might be that you use "is close to zero" to check if 
you should use special processing.  I think any tests which say "do it 
this way and get fewer roots" should be conservative and if we are on 
the borderline and we can do the code that generates more solutions then 
we should generate more and them maybe refine the roots and eliminate 
duplicates.  That way we can be (more) sure not to leave any roots unsolved.


The test as it is has a test case (I just chose random numbers to check 
and got lucky - d'oh!) that generates 1 solution from the new code even 
though the equation had 2 distinct solutions that weren't even near each 
other...


...jim



CubicSolver.java
Description: java/


Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

2010-12-28 Thread Jim Graham

Aha!

I finally figured out what I was missing.

On 12/24/2010 4:43 PM, Denis Lila wrote:

Line 1133 - I don't understand why that term has -q in it. The above
link and the original code both computed essentially the arccos of
this


Basically, the negative comes in when you push all of the p terms back 
inside the sqrt().


They had cos(3phi) = (3Q/2P)sqrt(-3/P)
   = (q/p)*sqrt(-1/p)
   = (-q/-p)*sqrt(-1/p)
   = -q*(-1/p)*sqrt(-1/p)
   = -q/(-p*sqrt(-p))
   = -q/(sqrt(-p^3)
which is what you calculate, so we are not calculating the negative of 
the angle after all - we are calculating the same angle using different 
math.  (Though it begs the question - is "-q/sqrt(-p^3)" more accurate 
than "-q/(p*sqrt(-p)"?  If p is < 1 then the cube is an even smaller 
number, does that matter?)



Let X = (3q/2p)*sqrt(-3/p) where p and q are the ones from the wikipedia
article, not our code.
So, when we do ret[0] = t * cos(phi), that's:
   = t * cos(acos(-X))


actually, it really was t*cos(acos(X)), not -X.


   = t * cos(pi/3 - acos(X))
   = t * cos(acos(X) - pi/3)
   = t * cos(acos(X) - pi/3 - pi)


There was an error here in this step as well, this line should read:
 = t * cos(acos(X) - pi/3 - 2pi)
 = t * cos(acos(X) -7pi/3)
 = nothing because this isn't our math... ;-)


I unfortunately don't have access to the icedtea servers at this moment,
so I attached a patch. I hope that's ok.


Have you updated the webrev yet?

...jim