matplotlib-devel Mailing List for matplotlib

This is indeed a bug. In some places in the code, I was casting from double to float (which is used by Mac OS X quartz internally) too soon. This created a roundoff error, which shows up as the jagged plot. I am preparing a patch and will submit it as soon as possible.
Thanks for reporting this bug.
--Michiel.
--- On Mon, 1/12/09, Tony Yu <ts...@gm...> wrote:
> From: Tony Yu <ts...@gm...>
> Subject: [matplotlib-devel] Jagged plot in macosx backend
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, January 12, 2009, 2:59 PM
> There appears to be a bug in the macosx backend. When I plot
> large numbers with small variations in the value, the
> numbers seem to be coarsely rounded off. This bug
> doesn't appear with other backends (I tried WxAgg and
> TkAgg). Below is a simple script showing the problem and the
> resulting plot on the macosx backend.
> 
> Thanks,
> -Tony
> 
> Mac OS X 10.5.6
> Matplotlib svn r6779
> 
> #~~~~~~~~
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> x = np.linspace(0, 1)
> plt.plot(x, x + 1e6)
> plt.show()------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

John Hunter wrote:
> On the issue of units (not unit testing but unit support which is
> motivating your writing of unit test) I think we may need a new
> approach. The current approach is to put unitized data into the
> artists, and update the converted data at the artist layer. I don't
> know that this is the proper design. For this approach to work, every
> scalar and array quantity must support units at the artist layer, and
> all the calculations that are done at the plotting layer (eg error
> bar) to setup these artists must be careful to preserve unitized data
> throughout. So it is burdensome on the artist layer and on the
> plotting function layer.
> 
> The problem is compounded because most of the other developers are not
> really aware of how to use the units interface, which I take
> responsibility for because they have oft asked for a design document,
> which I have yet to provide because I am unhappy with the design. So
> new code tends to break functions that once had unit support. Which
> is why we need unit tests ....
> 
> I think everything might be easier if mpl had an intermediate class
> layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
> already do for Legend. The plotting functions would instantiate these
> objects with the input arguments and track unit data through the
> reference to the axis. These plot objects would contain all the
> artist primitives which would store their data in native floating
> point, which would remove the burden on the artists from handling
> units and put it all in the plot creation/update logic. The objects
> would store references to all of the original inputs, and would update
> the primitive artists on unit changes. The basic problem is that the
> unitized data must live somewhere, and I am not sure that the low
> level primitive artists are the best place for that -- it may be a
> better idea to keep this data at the level of a PlotItem and let the
> primitive artists handle already converted floating point data. This
> is analogous to the current approach of passing transformed data to
> the backends to make it easier to write new backends. I need to chew
> on this some more.
John,
I think that getting unit support out of the basic artists, and keeping 
it at a higher level, is an excellent idea. Right now, unit support is 
sprinkled all over, and one never knows exactly where it will be or what 
to expect. Most of it works, but some doesn't. (I just fixed a part 
that didn't.)
One could go a little farther with this and require that more of the 
argument checking and regularization be done above the artist level as 
well; so that the artists could count on arrays of coordinates being 
ndarrays or masked arrays, for example. Whether the resulting code 
simplification would be worth the extra care required in using the 
artists, I don't know.
I also like the PlotItem concept as a way to get Axes under control and 
slimmed down. It is the approach taken with Quiver, Contour, and 
Colorbar, so there is more precedent than just Legend.
I'm not sure that a complete PlotItem-ization is required for localizing 
the unit support at a higher level than the basic artists; maybe it can 
be done piecemeal. A complete one-shot reworking would be a big job, 
requiring a lot of testing.
Eric

Paul Kienzle wrote:
> 
> On Jan 9, 2009, at 6:12 PM, Ryan May wrote:
> 
>> Maybe it's time to refactor here to get routine(s) that operate how we
>> want (IMO
>> more sanely than Matlab), and we provide wrappers that give
>> Matlab-like behavior.
>> Maybe we can also get these sane routines upstream into Scipy. At
>> that point,
>> however, I'm not sure what to do about the plotting functions, since
>> there's a
>> variety of behavior.
> 
> My policy when working on Octave was to avoid inventing new interfaces
> when the existing interfaces are good enough. This doesn't apply to the
> same degree in pylab of course because there is little hope of running
> matlab code directly off the net, but it still helps users if things
> with the same name share the same interface. It would not be good if
> importing psd from the matlab compatibility package gave a different
> interface than the same function name imported directly from mpl or scipy.
I agree 100%. My thoughts were having a flexible, yet simple and straightforward
implementation in scipy/matplotlib, and reimplement psd() on top of that. I
don't think psd is a good name anyways, since it is specifically based on the
welch method. While general, this is only 1 way of estimating the psd of the signal.
> In terms of refactoring, consider having a spectral density object. The
> following properties of psd naturally lends itself to an object interface:
> 
> * a number of related functions (psd, csd, transfer function,
> coherence) can be calculated from the same internal state
> * the state can be fed new inputs and updated frame by frame,
> * confidence intervals may or may not be requested,
> * data can be plotted in multiple ways
> * users may want to extract the data for further processing
> 
> It would be pretty easy to build the matlab interface on top of such an
> object.
I hadn't thought of an OO interface, but that's not usually my primary way of
thinking. It actually sounds like a good way to go, and is, in fact, the way
MatLab has gone now. It would also allow making a class hierarchy that uses
different methods for doing these calculation (plain periodogram, welch's method,
etc.).
Some food for thought anyways.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Jan 9, 2009, at 6:12 PM, Ryan May wrote:
> Maybe it's time to refactor here to get routine(s) that operate how 
> we want (IMO
> more sanely than Matlab), and we provide wrappers that give Matlab- 
> like behavior.
> Maybe we can also get these sane routines upstream into Scipy. At 
> that point,
> however, I'm not sure what to do about the plotting functions, 
> since there's a
> variety of behavior.
My policy when working on Octave was to avoid inventing new 
interfaces when the existing interfaces are good enough. This 
doesn't apply to the same degree in pylab of course because there is 
little hope of running matlab code directly off the net, but it still 
helps users if things with the same name share the same interface. 
It would not be good if importing psd from the matlab compatibility 
package gave a different interface than the same function name 
imported directly from mpl or scipy.
In terms of refactoring, consider having a spectral density object. 
The following properties of psd naturally lends itself to an object 
interface:
 * a number of related functions (psd, csd, transfer function, 
coherence) can be calculated from the same internal state
 * the state can be fed new inputs and updated frame by frame,
 * confidence intervals may or may not be requested,
 * data can be plotted in multiple ways
 * users may want to extract the data for further processing
It would be pretty easy to build the matlab interface on top of such 
an object.
 - Paul