* Thomas Weber <[EMAIL PROTECTED]> [2008-05-17 23:22]: > On 23/05/06 17:12 +1000, Drew Parsons wrote: > > On Tue, 2006-05-23 at 08:45 +0200, Thomas Weber wrote: > > So any code to go upstream would want to use a renomalisation factor of, > > say r=(xmax-xmin) rather than "1000", in order to get the scaled x > > around 1. The reconversion back to original x would presumeably go as > > P(k)->P(k)/(r^power ), though I haven't proven this. Other alternatives > > would be a linear rescaling of x to between [-1,1] or perhaps [-10,10], > > though I guess that may not make so much of a difference to the polyfit > > comparing to just dividing by r. I'm sure sure, however, maybe it would > > be preferable. > > > > Thanks for looking into it and taking the bug report seriously, > > Upstream changed the polyfit algorithm in the 3.1 branch to a QR based > algorithm. Your sample is included as a test case, so once we come to > that version, this bug should be fixed.
It does not seem to be the case: $ octave3.1 -q octave3.1:1> inputData = load( "test.dat" ); octave3.1:2> x = inputData( : , 1 ); octave3.1:3> y = inputData( : , 2 ); octave3.1:4> P = polyfit(x,y,10); warning: dgelsd: rank deficient 13x11 matrix, rank = 3 octave3.1:5> P P = 1.9998e-24 5.2878e-21 3.5391e-18 -8.9277e-21 1.5014e-23 -2.1042e-26 2.6541e-29 -3.1245e-32 3.5032e-35 -3.7875e-38 3.9812e-41 This is with version 3.1.51. Thomas, do you know whether it is fixed in hg? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
