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.