@@ -55,31 +55,50 @@ Matplotlib is the whole package; :mod:`pylab` is a module in matplotlib
55
55
that gets installed alongside :mod: `matplotlib `; and :mod: `matplotlib.pyplot `
56
56
is a module in matplotlib.
57
57
58
- Pyplot provides the state-machine interface to the underlying plotting
58
+ Pyplot provides the state-machine interface to the underlying OO plotting
59
59
library in matplotlib. This means that figures and axes are implicitly
60
60
and automatically created to achieve the desired plot. For example,
61
61
calling ``plot `` from pyplot will automatically create the necessary
62
62
figure and axes to achieve the desired plot. Setting a title will
63
63
then automatically set that title to the current axes object::
64
64
65
- import matplotlib.pyplot as plt
66
65
67
- plt.plot(range(10), range(10))
68
- plt.title("Simple Plot")
69
- plt.show()
66
+ .. sourcecode:: ipython
67
+
68
+ In [20]: %matplotlib
69
+ Using matplotlib backend: Qt4Agg
70
+
71
+ In [15]: import matplotlib.pyplot as plt
72
+
73
+ In [16]: plt.plot(range(10), range(10))
74
+ Out[16]: [<matplotlib.lines.Line2D at 0x7fdfef9be1d0>]
75
+
76
+ In [17]: plt.title("Simple Plot")
77
+ Out[17]: <matplotlib.text.Text at 0x7fdfee53d0d0>
78
+
79
+ This is very convenient for interactive use, however
80
+ because the commands have side-effects (altering the global state)
81
+ using many :mod: `matplotlib.pyplot ` commands in scripts or functions
82
+ can lead to unexpected and difficult to track down bugs.
70
83
71
- Pylab combines the pyplot functionality (for plotting) with the numpy
72
- functionality (for mathematics and for working with arrays)
73
- in a single namespace, making that namespace
74
- (or environment) even more MATLAB-like.
75
- For example, one can call the `sin ` and `cos ` functions just like
76
- you could in MATLAB, as well as having all the features of pyplot.
84
+ Pylab is a convenience module that imports pyplot (for
85
+ plotting) and numpy functionality (for mathematics and for
86
+ working with arrays) in a single namespace. You can than bulk import
87
+ from pylab::
77
88
78
- The pyplot interface is generally preferred for non-interactive plotting
79
- (i.e., scripting). The pylab interface is convenient for interactive
80
- calculations and plotting, as it minimizes typing. Note that this is
81
- what you get if you use the *ipython * shell with the *-pylab * option,
82
- which imports everything from pylab and makes plotting fully interactive.
89
+ .. sourcecode:: ipython
90
+
91
+ In [1]: from pylab import *
92
+
93
+ to get an even more MATLAB-like environment. For example, one can
94
+ call the `sin ` and `cos ` functions just like you could in MATLAB, as
95
+ well as having all the features of pyplot. The pylab interface is
96
+ convenient for interactive calculations and plotting, as it minimizes
97
+ typing. This is not recommended to use pylab in scripts for the same reasons
98
+ bulk importing is discouraged in general.
99
+
100
+ For non-interactive use it is suggested to use pyplot to create the
101
+ figures and then the OO interface for plotting.
83
102
84
103
.. _coding_styles :
85
104
@@ -106,18 +125,7 @@ scripts will typically be::
106
125
import numpy as np
107
126
108
127
Then one calls, for example, np.arange, np.zeros, np.pi, plt.figure,
109
- plt.plot, plt.show, etc. So, a simple example in this style would be::
110
-
111
- import matplotlib.pyplot as plt
112
- import numpy as np
113
- x = np.arange(0, 10, 0.2)
114
- y = np.sin(x)
115
- plt.plot(x, y)
116
- plt.show()
117
-
118
- Note that this example used pyplot's state-machine to
119
- automatically and implicitly create a figure and an axes. For full
120
- control of your plots and more advanced usage, use the pyplot interface
128
+ plt.plot, plt.show, etc. Use the pyplot interface
121
129
for creating figures, and then use the object methods for the rest::
122
130
123
131
import matplotlib.pyplot as plt
@@ -129,22 +137,59 @@ for creating figures, and then use the object methods for the rest::
129
137
ax.plot(x, y)
130
138
plt.show()
131
139
132
- Next, the same example using a pure MATLAB-style::
140
+ So, why all the extra typing instead of the MATLAB-style (which relies
141
+ on global state and a flat namespace)? For very simple things like
142
+ this example, the only advantage is academic: the wordier styles are
143
+ more explicit, more clear as to where things come from and what is
144
+ going on. For more complicated applications, this explicitness and
145
+ clarity becomes increasingly valuable, and the richer and more
146
+ complete object-oriented interface will likely make the program easier
147
+ to write and maintain.
148
+
149
+ Typically one finds them selves making the same plots over and over
150
+ again, but with different data sets, which leads to needing to write
151
+ specialized functions to do the plotting. The recommended function
152
+ signature is something like: ::
153
+
154
+ def my_plotter(ax, data1, data2, param_dict):
155
+ """
156
+ A helper function to make a graph
157
+
158
+ Parameters
159
+ ----------
160
+ ax : Axes
161
+ The axes to draw to
162
+
163
+ data1 : array
164
+ The x data
165
+
166
+ data2 : array
167
+ The y data
168
+
169
+ param_dict : dict
170
+ Dictionary of kwargs to pass to ax.plot
171
+
172
+ Returns
173
+ -------
174
+ out : list
175
+ list of artists added
176
+ """
177
+ out = ax.plot(data1, data2, **param_dict)
178
+ return out
179
+
180
+ which you would then use as::
181
+
182
+ fig, ax = plt.subplots(1, 1)
183
+ my_plotter(ax, data1, data2, {'marker':'x'})
133
184
134
- from pylab import *
135
- x = arange(0, 10, 0.2)
136
- y = sin(x)
137
- plot(x, y)
138
- show()
185
+ or if you wanted to have 2 sub-plots::
139
186
187
+ fig, (ax1, ax2) = plt.subplots(1, 2)
188
+ my_plotter(ax1, data1, data2, {'marker':'x'})
189
+ my_plotter(ax2, data3, data4, {'marker':'o'})
140
190
141
- So, why all the extra typing as one moves away from the pure
142
- MATLAB-style? For very simple things like this example, the only
143
- advantage is academic: the wordier styles are more explicit, more
144
- clear as to where things come from and what is going on. For more
145
- complicated applications, this explicitness and clarity becomes
146
- increasingly valuable, and the richer and more complete object-oriented
147
- interface will likely make the program easier to write and maintain.
191
+ Again, for these simple examples this style seems like overkill, however
192
+ once the graphs get slightly more complex it pays off.
148
193
149
194
.. _what-is-a-backend :
150
195
0 commit comments