Re: [Matplotlib-users] Strange resize behaviour for qt backend
Hi Darren, Darren Dale writes: > I am really busy with other things, and can't offer suggestions unless > you post a short, simple, standalone script that demonstrates the > problem. Sure: 8<- import random import sys from PyQt4 import QtGui, QtCore from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas from matplotlib.figure import Figure,SubplotParams class DiagramWidget(QtGui.QWidget): def __init__(self, parent): QtGui.QWidget.__init__(self, parent) layout = QtGui.QVBoxLayout(self) self.setLayout(layout) self.diagram = InnerDiagramWidget(self) self.scrollbar = QtGui.QScrollBar(QtCore.Qt.Horizontal, self) layout.addWidget(self.diagram) layout.addWidget(self.scrollbar) def resizeEvent(self, event): print 'figure resize to', event.size() QtGui.QWidget.resizeEvent(self, event) class InnerDiagramWidget(FigureCanvas): def __init__(self, parent): fig = Figure() self.axes = fig.add_subplot(111) range = xrange(1) l = [ random.randint(-5, 5) for i in range ] self.axes.plot(range, l, drawstyle='steps') FigureCanvas.__init__(self, fig) self.setParent(parent) FigureCanvas.setSizePolicy(self, QtGui.QSizePolicy.Expanding, QtGui.QSizePolicy.Expanding) FigureCanvas.updateGeometry(self) def resizeEvent(self, event): print 'scroll resize to', event.size() FigureCanvas.resizeEvent(self, event) a = QtGui.QApplication(sys.argv) w = QtGui.QMainWindow() w.setCentralWidget(DiagramWidget(w)) w.show() a.exec_() 8<- To see the problem undisturbed, you may remove the "resizeEvent()" functions. Best regards Ole -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Strange resize behaviour for qt backend
Hi again, Ole Streicher writes: > Darren Dale writes: >> I am really busy with other things, and can't offer suggestions unless >> you post a short, simple, standalone script that demonstrates the >> problem. > Sure: > w.show() > a.exec_() I forgot to say: execute this code, and then try to resize the window width with the mouse -- this leads to a wrong scrollbar width. Trying to resize the window height with the mouse leads to a wrong scrollbar position. Best regards Ole -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Strange resize behaviour for qt backend
Hallo Theodore, "Drain, Theodore R" writes: > Remember, this is not a multi-threaded system. You can't receive a > second repaint event while the drawing code is happening because the > event loop is not in a separate thread. This is not my choice. If the user resizes the window, the events are created in that manner. And I cannot prevent the user from resizing the window. Best regards Ole -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] making publication quality plots
Howdy y'all! I'm trying to make a publication quality plot for a two-column latex article. I'm using latex for text processing, so the plot quality itself is impeccable. However, as I scale the plot size down, the legend becomes extremely large compared to the plot itself. Has anyone solved this problem in a good manner? I'm not willing to make do without the legend. cheers, Paul. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] making publication quality plots
Hi,
I usually fix the size of the figure when I produce it. I use rcparams
below for a single column plot. This usually solves the problem. What
you see is what you get in the final document if you use the same size
of the figure as used to produce it.
def paper_single():
plt.rc('figure', figsize=(3.375,3.375))
plt.rc('figure.subplot', left=0.15, right=0.97, bottom=0.1, top=0.95)
plt.rc('lines', linewidth=1.5)
plt.rc('font', size=10.0)
plt.rc('xtick', labelsize='small')
plt.rc('ytick', labelsize='small')
plt.rc('legend', fontsize='medium')
Cheers,
Chaitanya
On Fri, May 29, 2009 at 5:25 PM, Paul Anton Letnes
wrote:
> Howdy y'all!
>
> I'm trying to make a publication quality plot for a two-column latex
> article. I'm using latex for text processing, so the plot quality
> itself is impeccable. However, as I scale the plot size down, the
> legend becomes extremely large compared to the plot itself. Has
> anyone solved this problem in a good manner? I'm not willing to make
> do without the legend.
>
> cheers,
> Paul.
>
>
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
Indeed, but it should really be fixed in the svn. Xavier > Hi Xavier, > > I had the same problem and fixed it by changing just two lines of code in the > axes.py (line 1812 and 1814). Just change the formatter in > 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the > same for y). > > But it would really be great to see your proposal as a standard. > > > Greetings, > > David > > > > Original-Nachricht > Datum: Sun, 24 May 2009 19:15:18 +0200 > > Von: Xavier Gnata > An: > matplotlib-users@lists.sourceforge.net > Betreff: [Matplotlib-users] x= / y= > labels default format is wrong > Hello all, > > I routinely work with images > sizes > [1000,1000]. > There is a slight annoying problem whatever the > backend I use: > Pixels coordinates default format is wrong. > It does not > make sense to display "x=1.42e+03,y=1.92e+03". > Pixels coordinates should be > formated *by default* as integers. > > Would it be possible to fix that? > > > Steps to reproduce: > import numpy > import pylab > > a=numpy.random.random((2000,2000)) > pylab.imshow(a,interpolation='Nearest') > > > > Xavier > > > -- > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is > a gathering of tech-side developers & brand creativity professionals. > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing, & > > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > > ___ > Matplotlib-users mailing > list > Matplotlib-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] making publication quality plots
On Fri, May 29, 2009 at 10:25 AM, Paul Anton Letnes wrote: > I'm trying to make a publication quality plot for a two-column latex > article. I'm using latex for text processing, so the plot quality > itself is impeccable. However, as I scale the plot size down, the > legend becomes extremely large compared to the plot itself. Has > anyone solved this problem in a good manner? I'm not willing to make > do without the legend. The major determinant of the legend is the fontsize, so if you want to make a small figure in inches, you may want to make the legend font smaller import matplotlib.font_manager as font_manager leg = ax.legend(loc='upper left', prop=font_manager.FontProperties(size=10)) JDH -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata wrote:
>> I had the same problem and fixed it by changing just two lines of code in
>> the axes.py (line 1812 and 1814). Just change the formatter in
>> 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the
>> same for y).
You don't need to modify the internals of axes.py -- just set the
formatter on the axes instance itself.
http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter
> Indeed, but it should really be fixed in the svn.
We could perhaps be a little smarter about this, but consider that one
can easily plot lines over images
In [30]: imshow(np.random.rand(512,512))
Out[30]:
In [31]: plot(np.arange(512), np.arange(512))
Since the plot can be a mix of images, polygons, lines, etc, it is not
obvious that the formatter should be int. We could trap the case
where you have only an image, no other data, and haven't set the
extent, but it would be complicated because you may add data to the
plot later and we would have to track that we had attempted to be
clever but we should now undo our cleverness. Our general philosophy
is to make is easy for you to customize when the default behavior
doesn't suit you, so try
import matplotlib.ticker as ticker
ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d'))
.. and ditto for yaxis ..
in addition to the ticks, you can customize how the coords appear in
the toolbar by setting
ax.fmt_xdata = ticker.FormatStrFormatter('%d')
... and ditto for fmt_ydata
There are a variety of formatters available
http://matplotlib.sourceforge.net/api/ticker_api.html
JDH
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Howto get horiz/vert grid
from pylab import semilogy, show, grid grid() semilogy (result[0]) This gave me just a vertical grid. What do I do to get both horiz and vert grids? -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Error in mpl.axes.set_default_color_cycle
Hi,
I have an error while trying to use mpl.axes.set_default_color_cycle to
define my own color cycle based on the set1 colormap:
In [1]: set1 = array([[228,55, 77, 152,255,255,166,247,153],
...: [26, 126,175,78, 127,255,86, 129,153],
...: [28, 184,74, 163,0, 51, 40, 191,153]],'d').T / 255.
In [2]: mpl.axes.set_default_color_cycle(set1)
---
AttributeErrorTraceback (most recent call last)
/autofs/home/ycopin/ in ()
/usr/lib/python2.5/site-packages/matplotlib/axes.py in
set_default_color_cycle(clist)
113 """
114 _process_plot_var_args.defaultColors = clist[:]
--> 115 rcParams['lines.color'] = clist[0]
116
117 class _process_plot_var_args:
/usr/lib/python2.5/site-packages/matplotlib/__init__.pyc in
__setitem__(self, key, val)
588 instead.'% (key, alt))
589 key = alt
--> 590 cval = self.validate[key](val)
591 dict.__setitem__(self, key, cval)
592 except KeyError:
/usr/lib/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_color(s)
156 def validate_color(s):
157 'return a valid color arg'
--> 158 if s.lower() == 'none':
159 return 'None'
160 if is_color_like(s):
AttributeError: 'numpy.ndarray' object has no attribute 'lower'
I'm using matplotlib 0.98.3 but I checked on the SVN repository that the
offending lines ("rcParams['lines.color'] = clist[0]","if s.lower() ==
'none'") are still there.
Cheers.
--
.~. Yannick COPIN (o:>* Doctus cum libro
/V\ Institut de physique nucleaire de Lyon (IN2P3-France)
// \\ Lawrence Berkeley National Laboratory
/( )\ aim:YnCopin icq:236931013 http://snovae.in2p3.fr/ycopin/
^`~'^
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Howto get horiz/vert grid
On Fri, May 29, 2009 at 19:09, Neal Becker wrote: > > from pylab import semilogy, show, grid > grid() > semilogy (result[0]) > > This gave me just a vertical grid. What do I do to get both horiz and vert > grids? (without looking at a screenshot or to the dataset is hard to tell but) is it possible that you have Y values contained in a single logarithmic inteval (or even closer)? if so, there is no line on Y to draw and only vertival lines (relative to X values) are displayed. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Error in mpl.axes.set_default_color_cycle
Yannick Copin wrote:
> Hi,
>
> I have an error while trying to use mpl.axes.set_default_color_cycle to
> define my own color cycle based on the set1 colormap:
>
> In [1]: set1 = array([[228,55, 77, 152,255,255,166,247,153],
> ...: [26, 126,175,78, 127,255,86, 129,153],
> ...: [28, 184,74, 163,0, 51, 40, 191,153]],'d').T / 255.
>
> In [2]: mpl.axes.set_default_color_cycle(set1)
> ---
> AttributeErrorTraceback (most recent call last)
I just committed a change that should fix this bug.
Eric
>
> /autofs/home/ycopin/ in ()
>
> /usr/lib/python2.5/site-packages/matplotlib/axes.py in
> set_default_color_cycle(clist)
> 113 """
> 114 _process_plot_var_args.defaultColors = clist[:]
> --> 115 rcParams['lines.color'] = clist[0]
> 116
> 117 class _process_plot_var_args:
>
> /usr/lib/python2.5/site-packages/matplotlib/__init__.pyc in
> __setitem__(self, key, val)
> 588 instead.'% (key, alt))
> 589 key = alt
> --> 590 cval = self.validate[key](val)
> 591 dict.__setitem__(self, key, cval)
> 592 except KeyError:
>
> /usr/lib/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_color(s)
> 156 def validate_color(s):
> 157 'return a valid color arg'
> --> 158 if s.lower() == 'none':
> 159 return 'None'
> 160 if is_color_like(s):
>
> AttributeError: 'numpy.ndarray' object has no attribute 'lower'
>
> I'm using matplotlib 0.98.3 but I checked on the SVN repository that the
> offending lines ("rcParams['lines.color'] = clist[0]","if s.lower() ==
> 'none'") are still there.
>
> Cheers.
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] computer modern
Thanks, it works well.
However, I forgot that computer modern does not include accented
characters (unlike latin modern), so I eventually used Stix :
mpl.rc('font', family = 'serif', serif = 'STIXGeneral')
By the way, is there any way to use Stix for sans-serif as well, or even
cursive and monospace ? I don't know how to do that, since Stix seems to
contain all of them in a single file (STIXGeneral.ttf) ?
Nicolas
Michael Droettboom a écrit :
> The name of the Computer Modern Roman font that ships with matplotlib
> is "cmr10", so
>
> mpl.rc('font', family = 'serif', serif = 'cmr10')
>
> should work.
>
> Mike
>
> Nicolas Pourcelot wrote:
>> Hi,
>>
>> is there any way to use Computer Modern in any text in matplotlib ?
>>
>> In http://matplotlib.sourceforge.net/users/customizing.html, I read
>> the following :
>>
>> #font.serif : Bitstream Vera Serif, New Century Schoolbook,
>> Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9
>> L, Times New Roman, Times, Palatino, Charter, serif
>> #font.sans-serif : Bitstream Vera Sans, Lucida Grande, Verdana,
>> Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif
>> #font.cursive: Apple Chancery, Textile, Zapf Chancery, Sand,
>> cursive
>> #font.fantasy: Comic Sans MS, Chicago, Charcoal, Impact,
>> Western, fantasy
>> #font.monospace : Bitstream Vera Sans Mono, Andale Mono, Nimbus
>> Mono L, Courier New, Courier, Fixed, Terminal, monospace
>> So, Computer Modern is not listed there.
>>
>> However, Computer Modern is used in mathtext, so I suppose there is a
>> way to use it also in plain text, but I can't figure it...
>>
>> I tried :
>> /mpl.rc('font', family = 'serif', serif = 'computer modern roman')/
>> but it did not work.
>>
>> Thanks a lot,
>>
>> Nicolas P.
>>
>>
>> --
>>
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing,
>> & iPhoneDevCamp as they present alongside digital heavyweights like
>> Barbarian Group, R/GA, & Big Spaceship.
>> http://p.sf.net/sfu/creativitycat-com
>>
>>
>> ___
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] PCA scatter plot in pylab with data labels
Gurus, I am implementing some simple Principal Component Analysis (PCA) in Python but I have run into trouble with the graphical output. I have calculated my scores and my loadings (just matrices with mean-centered, univariate values) and I want to scatterplot them. However, to make the graph more useful I want to label each dot in the scatter plot and also color it. I am using Matplotlib, Pylab, and Scipy. For example, given a 3x3 matrix of scores called T, I want to: T,P,E = PCA_svd( X, standardize = True ) t1, t2 = T[:,0], T[:,1] properties = dict( alpha = 0.75, c = some_colors ) s1 = scatter( t1, t2 ,s = 50, **properties ) legend() grid( True ) show() And the result should show three dots of various colors with a legend describing each color, and a data-label (say a two-character code, like AA, BB, CC) for each data-point. I understand that pylab.scatter objects are not formatted correctly to use the pylab.legend command, and I was wondering if a patch has been written for this yet. I use Python 2.5.3 I have found one work-around for the legend that plots each group in color and then hacks with a Rectangle object, as follows: props = dict( alpha = 0.75, faceted = False ) Scores = scatter( t1, t2, c = 'red', s = 50, **props ) Loadings = scatter( p1, p2, c = 'blue', s = 50, **props ) redp = Rectangle( ( 0,0 ), 1, 1, facecolor = 'red' ) bluep = Rectangle( ( 0,0 ), 1, 1, facecolor = 'blue' ) legend( ( redp,bluep ),( 'Scores','Loadings' ) ) grid( True ) show() This works for varying colors across two groups of points, but it doesn't work for single data-points (it says "ValueError: First argument must be a sequence") and it also does not allow me to label each data-point with a two-char code. Any shoves in the right direction would be very much appreciated. Links to online examples and source-code especially so. -Timothy Kinney -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
John Hunter wrote:
> On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata wrote:
>
>
>>> I had the same problem and fixed it by changing just two lines of code in
>>> the axes.py (line 1812 and 1814). Just change the formatter in
>>> 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the
>>> same for y).
>>>
>
> You don't need to modify the internals of axes.py -- just set the
> formatter on the axes instance itself.
>
> http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter
>
>
>> Indeed, but it should really be fixed in the svn.
>>
>
> We could perhaps be a little smarter about this, but consider that one
> can easily plot lines over images
>
> In [30]: imshow(np.random.rand(512,512))
> Out[30]:
>
> In [31]: plot(np.arange(512), np.arange(512))
>
> Since the plot can be a mix of images, polygons, lines, etc, it is not
> obvious that the formatter should be int. We could trap the case
> where you have only an image, no other data, and haven't set the
> extent, but it would be complicated because you may add data to the
> plot later and we would have to track that we had attempted to be
> clever but we should now undo our cleverness. Our general philosophy
> is to make is easy for you to customize when the default behavior
> doesn't suit you, so try
>
> import matplotlib.ticker as ticker
> ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d'))
> .. and ditto for yaxis ..
>
> in addition to the ticks, you can customize how the coords appear in
> the toolbar by setting
>
> ax.fmt_xdata = ticker.FormatStrFormatter('%d')
> ... and ditto for fmt_ydata
>
> There are a variety of formatters available
>
> http://matplotlib.sourceforge.net/api/ticker_api.html
>
> JDH
>
Hi John,
Ok, well; the way I use pylab may be a corner case ;)
However, everyone would be happy if the default format would be consistent :
As it is, *by default*, when <1000 it displays an int and after 1000 it
displays 1.42e3.
Why? What do you think this scientific format is a good for?
I understand some users would like to see floats by default.
Some other users would like to see integers by default.
I'm fine with integers or floats by default (I don't cadre) but I don't
get the logic of the scientific format.
I only would like to see all the digits of the integer parts.
I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for
instance assume that images larger than (100 000, 100 000) are really a
corner case ;)).
Why should be the *default* logic so strange?
Ok, it is easy to change but the default should at least make sense.
As it is, I don't think it does...but there could be a good rational I'm
missing.
pylab is so easy and fun to use because the default settings are always
the best one.
IMHO, there is one exception :(
Xavier
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Histogram with multiple data
Hi, I'm trying to add label to a histogram with multiple data. The doc says "label can also be a sequence of strings" but when I try: plt.hist([listA, listB, listC], bins=25, histtype='bar', alpha=0.75,rwidth=0.85,label=['A','B','C']) I got an error: "AttributeError: 'tuple' object has no attribute 'startswith'" (for the entire traceback see http://paste.pocoo.org/show/119820/ ) is it me or a bug? Can I add a legend in another way? thanks in advance! -Yva. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
Xavier Gnata wrote: > > However, everyone would be happy if the default format would be consistent : > > As it is, *by default*, when <1000 it displays an int and after 1000 it > displays 1.42e3. > Why? What do you think this scientific format is a good for? > > I understand some users would like to see floats by default. > Some other users would like to see integers by default. It is not just a matter of integer versus float; the formatting algorithm must accomodate both. > > I'm fine with integers or floats by default (I don't cadre) but I don't > get the logic of the scientific format. > I only would like to see all the digits of the integer parts. > I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for > instance assume that images larger than (100 000, 100 000) are really a > corner case ;)). > > Why should be the *default* logic so strange? > Ok, it is easy to change but the default should at least make sense. > As it is, I don't think it does...but there could be a good rational I'm > missing. Right now, the default is very simple: def format_data_short(self,value): 'return a short formatted string representation of a number' return '%1.3g'%value It looks like changing it to something like "%-12g" would facilitate considerable improvement in reducing the jumping around of the numbers, as well as in providing much more precision. I think that 12 is the max number of characters in g conversion. Or maybe it is 13; I might not have tested negative numbers. The problem is that then it crowds out the other part of the message, the pan/zoom status notification etc. Breaking the message into two lines almost works (so far only checking with gtkagg), but the plot gets resized depending on whether there is a status or not. I think that with some more fiddling around with that part of the toolbar--probably including breaking the message up into separate messages for status and readout, and maybe making the readout use two lines and always be present--we could make the readout and status display much nicer. I have never liked the way it jumps around. Eric > > pylab is so easy and fun to use because the default settings are always > the best one. > IMHO, there is one exception :( > > Xavier > > > > -- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > ___ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
>
>>
>> However, everyone would be happy if the default format would be
>> consistent :
>>
>> As it is, *by default*, when <1000 it displays an int and after 1000
>> it displays 1.42e3.
>> Why? What do you think this scientific format is a good for?
>>
>> I understand some users would like to see floats by default.
>> Some other users would like to see integers by default.
>
> It is not just a matter of integer versus float; the formatting
> algorithm must accomodate both.
>
I agree.
>>
>> I'm fine with integers or floats by default (I don't cadre) but I
>> don't get the logic of the scientific format.
>> I only would like to see all the digits of the integer parts.
>> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could
>> for instance assume that images larger than (100 000, 100 000) are
>> really a corner case ;)).
>>
>> Why should be the *default* logic so strange?
>> Ok, it is easy to change but the default should at least make sense.
>> As it is, I don't think it does...but there could be a good rational
>> I'm missing.
>
>
> Right now, the default is very simple:
>
> def format_data_short(self,value):
> 'return a short formatted string representation of a number'
> return '%1.3g'%value
>
> It looks like changing it to something like "%-12g" would facilitate
> considerable improvement in reducing the jumping around of the
> numbers, as well as in providing much more precision. I think that 12
> is the max number of characters in g conversion. Or maybe it is 13; I
> might not have tested negative numbers.
>
> The problem is that then it crowds out the other part of the message,
> the pan/zoom status notification etc.
>
> Breaking the message into two lines almost works (so far only checking
> with gtkagg), but the plot gets resized depending on whether there is
> a status or not.
>
> I think that with some more fiddling around with that part of the
> toolbar--probably including breaking the message up into separate
> messages for status and readout, and maybe making the readout use two
> lines and always be present--we could make the readout and status
> display much nicer. I have never liked the way it jumps around.
>
I also agree.
However, I would like to be sure I understand one point correctly:
As long as x<1000, the default format *is* an integer (at least when
imshow(M) is used).
Fine for me. Why do we need to move to another *default* format for
numbers larger than 1000?
Anyhow, I think that we should at least always display all the digits of
the integer part of the coordinates.
BTW, ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) is
fine but it prevents you to do a simple imshow(M) to look at your data.
You have to create ax. Easy...yes...but not as simple/nice as the
one-liner imhow(M)
Xavier
> Eric
>
>>
>> pylab is so easy and fun to use because the default settings are
>> always the best one.
>> IMHO, there is one exception :(
>>
>> Xavier
>>
>>
>>
>> --
>>
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing,
>> & iPhoneDevCamp as they present alongside digital heavyweights like
>> Barbarian Group, R/GA, & Big Spaceship.
>> http://p.sf.net/sfu/creativitycat-com
>> ___
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] x= / y= labels default format is wrong
Xavier Gnata wrote: > >> >>> >> Right now, the default is very simple: >> >> def format_data_short(self,value): >> 'return a short formatted string representation of a number' >> return '%1.3g'%value >> >> It looks like changing it to something like "%-12g" would facilitate >> considerable improvement in reducing the jumping around of the >> numbers, as well as in providing much more precision. I think that 12 >> is the max number of characters in g conversion. Or maybe it is 13; I >> might not have tested negative numbers. >> >> The problem is that then it crowds out the other part of the message, >> the pan/zoom status notification etc. >> >> Breaking the message into two lines almost works (so far only checking >> with gtkagg), but the plot gets resized depending on whether there is >> a status or not. >> >> I think that with some more fiddling around with that part of the >> toolbar--probably including breaking the message up into separate >> messages for status and readout, and maybe making the readout use two >> lines and always be present--we could make the readout and status >> display much nicer. I have never liked the way it jumps around. >> > I also agree. > However, I would like to be sure I understand one point correctly: > As long as x<1000, the default format *is* an integer (at least when > imshow(M) is used). No. Try imshow(rand(4,4)) There is nothing special about imshow that makes the cursor readout an integer, nor should there be. Again, the present default is "%1.3g". I think we can and will do better, but it is not necessarily trivial. Eric -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
