* 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
On Sat, Sep 06, 2008 at 10:26:20AM +0200, Rafael Laboissiere wrote:
* Thomas Weber [EMAIL PROTECTED] [2008-05-17 23:22]:
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
* Thomas Weber [EMAIL PROTECTED] [2008-09-06 11:09]:
On Sat, Sep 06, 2008 at 10:26:20AM +0200, Rafael Laboissiere wrote:
* Thomas Weber [EMAIL PROTECTED] [2008-05-17 23:22]:
Upstream changed the polyfit algorithm in the 3.1 branch to a QR based
algorithm. Your sample is included as a
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
On Sun, 2006-05-21 at 15:44 +0200, Thomas Weber wrote:
Using your data file, I get:
octave:2 norm(y-ynew)
ans = 6.3300
While Matlab's result is slightly better (norm of difference is ~0.4), I
don't see the results to differ that much? Oh, and Matlab warns about
the polynomial being badly
Using your data file, I get:
$ cat v.m
clear all
inputData = load( test.dat );
x = inputData( : , 1 );
y = inputData( : , 2 );
P = polyfit(x,y,10);
ynew = polyval(P,x);
$ cat test.dat
-1196.4 315571.7086
-1195.2 315575.9618
-1194 315579.4195
-1192.8 315582.6206
-1191.6 315585.4966
-1190.4
Here's a sample data file which polyfit can't handle directly.
-1196.4 315571.7086
-1195.2 315575.9618
-1194 315579.4195
-1192.8 315582.6206
-1191.6 315585.4966
-1190.4 315588.3172
-1189.2 315590.9326
-1188 315593.5934
-1186.8 315596.0455
-1185.6 315598.4201
-1184.4 315600.7143
-1183.2
7 matches
Mail list logo