That could certainly explain it.
> I don't know that I agree that it's correct -- I'm not
> graphing log(X), I'm graphing X, and 0 is a valid value
> for it. Only the scale is logarithmic, but it still
> contains a 0. I'll bow to a more expert opinion if
> there's disagreement.
If you posst your script, we might be able to give a more informed
opinion of what the desired output should be 
I understand that
there are some largish data files that you don't want to post, but if
we could just read the script alone that might be enough.
JDH
John Hunter wrote:
"Tennessee" == Tennessee Leeuwenburg <tennessee@...329...> writes:
> That could certainly explain it.
> I don't know that I agree that it's correct -- I'm not
> graphing log(X), I'm graphing X, and 0 is a valid value
> for it. Only the scale is logarithmic, but it still
> contains a 0. I'll bow to a more expert opinion if
> there's disagreement.
If you posst your script, we might be able to give a more informed
opinion of what the desired output should be I understand that
there are some largish data files that you don't want to post, but if
we could just read the script alone that might be enough.
JDH
John,
Here is a simple illustration of the problem and inconsistency, using just the first few points in Tennessee's plot and a few lines from his script. With a log scale for y, the Agg backends are leaving gaps (breaking the line) at the points where y==0; the PS and SVG backends are removing those points, but *not* breaking the line. I think the Agg behavior is much better. But maybe it would be better yet to raise an exception, forcing the user to deal with the error explicitly. For example, the user might want to change the zero values to a very small number, and then explicitly set the y range to exclude the small numbers. This is illustrated in the second subplot.
I haven't looked into it, but I suspect the log(0) values are becoming nans, so what we are seeing is differences in nan-handling among the backends.
Eric
logplot.py (429 Bytes)