Hi In the plot produced by this here the straight line

> isn't really straight and seems to "try to interpolate" the

> data points.

> x = linspace(0.016, 0.017, 20) y = 1000*x+5 +

> randn(len(x))/30.0 p = polyfit(x,y,1) plot(x, y, 'o', x,

> polyval(p, x), 'r') savefig('image.eps')

> The same happens with p[0]*x+p[1] instead of polyval(p, x).

> In the corresponding .png is OK so it seems to be a problem

> with the ps-backend.

This is the same bug that cropped up in your last post -- it is a

truncation bug in backend ps. 1.4g isn't doing it for us... For

testing I jacked up all the 1.4g fmt strings to 1.9g and the line

straightened itself out.

This persistent problem strengthens my belief that the ps backend

should be outputting transformed coords, since we can then precisely

know the size of the rounding error, eg in fractions of a point.

JDH

I agree. As of svn 2257, the transforms are done by backend_ps, instead of

being passed to the postscript interpreter.

On a side note, may I suggest that svn users should read and post to the

matplotlib-devel list?

## ···

On Tuesday 04 April 2006 17:03, John Hunter wrote:

> Hi In the plot produced by this here the straight line

> isn't really straight and seems to "try to interpolate" the

> data points.

> x = linspace(0.016, 0.017, 20) y = 1000*x+5 +

> randn(len(x))/30.0 p = polyfit(x,y,1) plot(x, y, 'o', x,

> polyval(p, x), 'r') savefig('image.eps')

> The same happens with p[0]*x+p[1] instead of polyval(p, x).

> In the corresponding .png is OK so it seems to be a problem

> with the ps-backend.

This is the same bug that cropped up in your last post -- it is a

truncation bug in backend ps. 1.4g isn't doing it for us... For

testing I jacked up all the 1.4g fmt strings to 1.9g and the line

straightened itself out.

This persistent problem strengthens my belief that the ps backend

should be outputting transformed coords, since we can then precisely

know the size of the rounding error, eg in fractions of a point.