[Pkg-octave-devel] Bug#348480: sample data

Rafael Laboissiere rafael at debian.org
Sat Sep 6 08:26:20 UTC 2008


* Thomas Weber <thomas.weber.mail at gmail.com> [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





More information about the Pkg-octave-devel mailing list