You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(8) 
_{Nov}
(8) 
_{Dec}
(4) 

2002 
_{Jan}
(53) 
_{Feb}
(15) 
_{Mar}
(51) 
_{Apr}
(54) 
_{May}
(41) 
_{Jun}
(48) 
_{Jul}
(32) 
_{Aug}
(22) 
_{Sep}
(61) 
_{Oct}
(31) 
_{Nov}
(31) 
_{Dec}
(27) 
2003 
_{Jan}
(45) 
_{Feb}
(18) 
_{Mar}
(25) 
_{Apr}
(39) 
_{May}
(34) 
_{Jun}
(20) 
_{Jul}
(13) 
_{Aug}
(16) 
_{Sep}
(18) 
_{Oct}
(14) 
_{Nov}
(17) 
_{Dec}
(13) 
2004 
_{Jan}
(53) 
_{Feb}
(12) 
_{Mar}
(38) 
_{Apr}
(29) 
_{May}
(72) 
_{Jun}
(38) 
_{Jul}
(41) 
_{Aug}
(11) 
_{Sep}
(21) 
_{Oct}
(30) 
_{Nov}
(35) 
_{Dec}
(14) 
2005 
_{Jan}
(66) 
_{Feb}
(14) 
_{Mar}
(24) 
_{Apr}
(50) 
_{May}
(40) 
_{Jun}
(29) 
_{Jul}
(37) 
_{Aug}
(27) 
_{Sep}
(26) 
_{Oct}
(58) 
_{Nov}
(43) 
_{Dec}
(23) 
2006 
_{Jan}
(84) 
_{Feb}
(36) 
_{Mar}
(24) 
_{Apr}
(42) 
_{May}
(20) 
_{Jun}
(41) 
_{Jul}
(40) 
_{Aug}
(42) 
_{Sep}
(23) 
_{Oct}
(38) 
_{Nov}
(31) 
_{Dec}
(28) 
2007 
_{Jan}
(11) 
_{Feb}
(34) 
_{Mar}
(14) 
_{Apr}
(29) 
_{May}
(45) 
_{Jun}
(5) 
_{Jul}
(10) 
_{Aug}
(6) 
_{Sep}
(38) 
_{Oct}
(44) 
_{Nov}
(19) 
_{Dec}
(22) 
2008 
_{Jan}
(37) 
_{Feb}
(24) 
_{Mar}
(29) 
_{Apr}
(14) 
_{May}
(24) 
_{Jun}
(47) 
_{Jul}
(26) 
_{Aug}
(4) 
_{Sep}
(14) 
_{Oct}
(45) 
_{Nov}
(25) 
_{Dec}
(16) 
2009 
_{Jan}
(33) 
_{Feb}
(34) 
_{Mar}
(45) 
_{Apr}
(45) 
_{May}
(30) 
_{Jun}
(47) 
_{Jul}
(37) 
_{Aug}
(19) 
_{Sep}
(15) 
_{Oct}
(16) 
_{Nov}
(24) 
_{Dec}
(31) 
2010 
_{Jan}
(32) 
_{Feb}
(25) 
_{Mar}
(12) 
_{Apr}
(5) 
_{May}
(2) 
_{Jun}
(9) 
_{Jul}
(31) 
_{Aug}
(10) 
_{Sep}
(12) 
_{Oct}
(20) 
_{Nov}
(6) 
_{Dec}
(41) 
2011 
_{Jan}
(23) 
_{Feb}
(8) 
_{Mar}
(41) 
_{Apr}
(8) 
_{May}
(15) 
_{Jun}
(10) 
_{Jul}
(8) 
_{Aug}
(14) 
_{Sep}
(16) 
_{Oct}
(13) 
_{Nov}
(15) 
_{Dec}
(8) 
2012 
_{Jan}
(6) 
_{Feb}
(14) 
_{Mar}
(22) 
_{Apr}
(40) 
_{May}
(27) 
_{Jun}
(18) 
_{Jul}
(2) 
_{Aug}
(6) 
_{Sep}
(10) 
_{Oct}
(32) 
_{Nov}
(5) 
_{Dec}
(2) 
2013 
_{Jan}
(14) 
_{Feb}
(2) 
_{Mar}
(15) 
_{Apr}
(2) 
_{May}
(6) 
_{Jun}
(7) 
_{Jul}
(25) 
_{Aug}
(6) 
_{Sep}
(3) 
_{Oct}

_{Nov}
(8) 
_{Dec}

2014 
_{Jan}
(3) 
_{Feb}
(3) 
_{Mar}
(3) 
_{Apr}

_{May}
(19) 
_{Jun}
(6) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(18) 
_{Oct}
(5) 
_{Nov}
(1) 
_{Dec}

S  M  T  W  T  F  S 




1
(1) 
2
(4) 
3

4

5

6

7

8

9
(1) 
10

11

12

13

14

15

16

17

18

19

20

21
(3) 
22
(1) 
23

24

25

26

27
(2) 
28

29

30



From: somi <seesomi@gm...>  20100902 15:39:38

Thanks Peter. That seems to work for me ( I tried bunch of 4th order polynomials, and I got the correct solutions) On Thu, Sep 2, 2010 at 11:11 AM, Peter Vanroose <peter_vanroose@...>wrote: > > Is there any way around it ? I could scale down points by 10, > > and again scale back the results. But I want to get a generic > > solution as I use this program in a library and I would have > > no way of telling automatically when to scale and when not to scale. > > Yes, of course, I see the problem. > > A "generic" way would be to compare the first and last nonzero coefficient, > and scale by a factor which makes them approximately equal (i.e., scale by > the nthe root of that factor), then scale back the result. > > I was thinking of adding a method "solve_robust()" to the vnl_rnpoly_solve > class which does something like this, but I'm not feeling comfortable enough > to do this right away for the general mdimensional case. But for your > particular (generic) use, it should not be too difficult: something like: > > double factor = coeffs[4]/coeffs[0]; > // take 4th root: > factor = sqrt(factor); factor = sqrt(factor); > double mfactor = 1.0; > for (int i=0; i<=4; ++i) coeffs[i]/=mfactor, mfactor*=factor; > ... > vnl_rnpoly_solve solver(l); > vcl_vector<vnl_vector<double>*> re = solver.real(); > vcl_vector<vnl_vector<double>*> im = solver.imag(); > ... > (*(*rp)) *= factor; // globally scale the vnl_vector back > > I've put a working implementation of exactly this in the last SVN version > of > core/vnl/algo/tests/test_rnpoly_roots.cxx > > >  Peter. > > > > > > > > > > > > 
From: Peter Vanroose <peter_vanroose@ya...>  20100902 15:11:11

> Is there any way around it ? I could scale down points by 10, > and again scale back the results. But I want to get a generic > solution as I use this program in a library and I would have > no way of telling automatically when to scale and when not to scale. Yes, of course, I see the problem. A "generic" way would be to compare the first and last nonzero coefficient, and scale by a factor which makes them approximately equal (i.e., scale by the nthe root of that factor), then scale back the result. I was thinking of adding a method "solve_robust()" to the vnl_rnpoly_solve class which does something like this, but I'm not feeling comfortable enough to do this right away for the general mdimensional case. But for your particular (generic) use, it should not be too difficult: something like: double factor = coeffs[4]/coeffs[0]; // take 4th root: factor = sqrt(factor); factor = sqrt(factor); double mfactor = 1.0; for (int i=0; i<=4; ++i) coeffs[i]/=mfactor, mfactor*=factor; ... vnl_rnpoly_solve solver(l); vcl_vector<vnl_vector<double>*> re = solver.real(); vcl_vector<vnl_vector<double>*> im = solver.imag(); ... (*(*rp)) *= factor; // globally scale the vnl_vector back I've put a working implementation of exactly this in the last SVN version of core/vnl/algo/tests/test_rnpoly_roots.cxx  Peter. 
From: somi <seesomi@gm...>  20100902 13:50:48

Hi Peter, Thanks for the reply. I checked the solution in atleast two programs (octave >roots and Numerical Recipies>zroots) and they give the correct solution for these coefficients. You are right, this has something to do with numerical instabilities during scaling. Unfortunately I can't change the coefficients. Let me explain the context in which I am using these coefficients. I have to compute the rigid transformation between two 3D point set v1 and v2 v2 = s R v1 + T , based on Horn's derivation of the closed form least squares formulation (for horns method see : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.971&rep=rep1&type=pdf ) For this I have to solve a polynomial as an intermediate step. However the function " vnl_rnpoly_solve" included in the ITK (vnl library) doesn't seem to be returning the correct roots for a particular case. a) BUGGY CASE: I used the following points: +9 253 1187 45 222 740 98 223 750 For this the polynomial coefficients would be (while registering above points to self) : 1.0000e+00 0.0000e+00 4.0615e+09 4.0000e06 4.1220e+18 The roots of the polynomial should be 4.5546e+04 4.4576e+04 4.5546e+04 4.4576e+04 But vnl_rnpoly_solve , doesn't return any root. b) TEST CASE: I then scaled the points by 0.1 to get the modified points +0.9 25.3 118.7 4.5 22.2 74.0 9.8 22.3 75.0 For this the polynomial coefficients would be (while registering above points to self) : 1.0000e+00 0.0000e+00 4.0615e+07 0.0000e+00 4.1220e+14 For this the roots should be: 4554.6 4457.6 4554.6 4457.6 Which is what I get using VNL. This is how I get the coefficients: a) center the point sets at their respective centroids b) compute the cross covariance terms of the two centered datasets c) Form the matrix "N" as in horns method d) form the quartic coefficients of the characteristic equation of matrix N for solving for the rotation in terms of quaternions e) Solve the polynomial with coefficients from step (d) Is there any way around it ? I could scale down points by 10, and again scale back the results. But I want to get a generic solution as I use this program in a library and I would have no way of telling automatically when to scale and when not to scale. Thanks, Somi On Thu, Sep 2, 2010 at 9:41 AM, Peter Vanroose <peter_vanroose@...>wrote: > Somi, > > I have the impression that this has to do with the precision and size of > your coefficients, > and more precisely of the magnitude difference between them. > Your constant coefficient is around 4e18. > If I scale the solutions by a factor 10, by dividing coefficient 3 by 100 > and coefficient 5 by 10000, I obtain the correct result (to be interpreted > 10x larger): > ======================== > VNL roots are > 4554.6 +i 4.62223e32 > 4457.61 +i 1.44445e34 > 4554.6 +i 4.62223e32 > 4457.61 +i 1.44445e34 > ======================== > > So try reducing too extreme values first (e.g. by dividing coefficient n by > 10^n) before calling the solver. > > I presume that the original algorithm (by Kriegman and Ponce) has this same > instability. > > Not sure whether this scaling solution should be introduced into the VNL > interface layer, or whether this should better be left to the user who calls > the method. Suggestions welcome, of course. > >  Peter. > > >  > >  Den *ons 20100901 skrev somi <seesomi@...>*: > > > Från: somi <seesomi@...> > Ämne: [Vxlusers] Bug in VNL vnl_rnpoly_solve ? > Till: vxlusers@... > Datum: onsdag 1 september 2010 22:29 > > > Hi, > I am getting incorrect solution when I try to solve a polynomial using the > method "vnl_rnpoly_solve", > that is provided in ITK. > > a) Polynomial coefficients (buggy case ) > > 1.0000e+00 0.0000e+00 4.0615e+09 4.0000e06 4.1220e+18 > > The roots of the polynomial should be > 4.5546e+04 > 4.4576e+04 > 4.5546e+04 > 4.4576e+04 > > But vnl_rnpoly_solve , doesn't return any root. > > > b) Polynomial coefficients (test case) > > > 1.0000e+00 0.0000e+00 4.0615e+07 0.0000e+00 4.1220e+14 > > For this the roots should be: > 4554.6 > 4457.6 > 4554.6 > 4457.6 > > Which is what I get using VNL. > > > > I have included a test program. > > Thanks, > Somi > > Infogad bilaga följer > > >  > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intelthreadsfd > > Infogad bilaga följer > > _______________________________________________ > Vxlusers mailing list > Vxlusers@...<http://mc/compose?to=Vxlusers@...>; > https://lists.sourceforge.net/lists/listinfo/vxlusers > > > 
From: Peter Vanroose <peter_vanroose@ya...>  20100902 13:41:09

Somi, I have the impression that this has to do with the precision and size of your coefficients, and more precisely of the magnitude difference between them. Your constant coefficient is around 4e18. If I scale the solutions by a factor 10, by dividing coefficient 3 by 100 and coefficient 5 by 10000, I obtain the correct result (to be interpreted 10x larger): ======================== VNL roots are 4554.6 +i 4.62223e32 4457.61 +i 1.44445e34 4554.6 +i 4.62223e32 4457.61 +i 1.44445e34 ======================== So try reducing too extreme values first (e.g. by dividing coefficient n by 10^n) before calling the solver. I presume that the original algorithm (by Kriegman and Ponce) has this same instability. Not sure whether this scaling solution should be introduced into the VNL interface layer, or whether this should better be left to the user who calls the method. Suggestions welcome, of course.  Peter.   Den ons 20100901 skrev somi <seesomi@...>: Från: somi <seesomi@...> Ämne: [Vxlusers] Bug in VNL vnl_rnpoly_solve ? Till: vxlusers@... Datum: onsdag 1 september 2010 22:29 Hi,I am getting incorrect solution when I try to solve a polynomial using the method "vnl_rnpoly_solve",that is provided in ITK. a) Polynomial coefficients (buggy case ) 1.0000e+00 0.0000e+00 4.0615e+09 4.0000e06 4.1220e+18 The roots of the polynomial should be 4.5546e+04 4.4576e+04 4.5546e+04 4.4576e+04 But vnl_rnpoly_solve , doesn't return any root. b) Polynomial coefficients (test case) 1.0000e+00 0.0000e+00 4.0615e+07 0.0000e+00 4.1220e+14 For this the roots should be: 4554.6 4457.6 4554.6 4457.6 Which is what I get using VNL. I have included a test program. Thanks,Somi Infogad bilaga följer  This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intelthreadsfd Infogad bilaga följer _______________________________________________ Vxlusers mailing list Vxlusers@... https://lists.sourceforge.net/lists/listinfo/vxlusers 