matplotlib-devel Mailing List for matplotlib

The following code show how the FontProperties is currently hashed.
 def __hash__(self):
 l = self.__dict__.items()
 l.sort()
 return hash(repr(l))
The hash does not account user's rcParams setting. And due to the font
caching, findfont(FontProperties()) returns the same font even if user
changes the rcParams["font.family"] and other parameters.
So, I propose to change it to something like below.
 def __hash__(self):
 l = [(k, getattr(self, "get" + k)()) for k in self.__dict__]
 return hash(repr(l))
The other change I want to make is the behavior of the findfont(None).
As of now, it returns "fontManager.defaultFont" which is set when
fontManager is initialized. Therefore, it returns same font even if
user change the rcParams. I prefer to have "findfont(None) ==
findfont(FontProperties())".
Unless others object, I'll commit the changes to the trunk.
Regards,
-JJ

Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...> wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to 
> implement, and most of us don't see a compelling need; we believe that a 
> better practice is to structure one's work so that plotting is separated 
> from data (result) generation in any cases where the latter is highly 
> time-consuming.
One nice benefit, however, would be that the data could be shipped to
another interpreter for plotting without worrying about threads/GIL/etc.
So, having an MPL-native plot description would be useful. But, I agree,
it would be a lot of work.

Sandro Tosi wrote:
> Hi Sam,
> 
> On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...> wrote:
>> I think this topic has come up before, but i don't think anything has
>> resulted from it.
>>
Correct, because the capability would require a *lot* of work to 
implement, and most of us don't see a compelling need; we believe that a 
better practice is to structure one's work so that plotting is separated 
from data (result) generation in any cases where the latter is highly 
time-consuming.
>> I'd like a way for saving a plot from from matplotlib, so that it can be
>> re-rendered later, possibly with a different backend, maybe to a different
>> size, and maybe with changes to the labels. This would save me having to
>> rerun the simulation that generated the plot.
>>
>> Ideally this would work by having a save_plot() function, that would save
>> all state of the current plot into a file. This could then be loaded by a
>> program to regenerate that plot.
> 
> Can't this be achieved by pickling/unpickling the mpl objects? Didn't
> manage to test it, but it should work.
No, this has been discussed several times. Quite a bit of work would be 
required to make all the extension code compatible with pickling. More 
work, more complexity, more difficult code maintenance and testing. 
It's not worth it, given the developer resources available for mpl.
> 
> Of course, it might fall in uncompatibility from source (pickling)
> environment and the destination (unpickling) one.
Yes, pickling is fundamentally unreliable, and should be used only under 
controlled, non-critical circumstances, such as for caching.
Eric
> 
> Regards,

Hi Sam,
On Wed, Feb 25, 2009 at 09:35, sam tygier <sam...@ya...> wrote:
> I think this topic has come up before, but i don't think anything has
> resulted from it.
>
> I'd like a way for saving a plot from from matplotlib, so that it can be
> re-rendered later, possibly with a different backend, maybe to a different
> size, and maybe with changes to the labels. This would save me having to
> rerun the simulation that generated the plot.
>
> Ideally this would work by having a save_plot() function, that would save
> all state of the current plot into a file. This could then be loaded by a
> program to regenerate that plot.
Can't this be achieved by pickling/unpickling the mpl objects? Didn't
manage to test it, but it should work.
Of course, it might fall in uncompatibility from source (pickling)
environment and the destination (unpickling) one.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

sam tygier wrote:
> 
> That is one method that i have used, but i don't think it is ideal. My data can be a wide range of things,
> sometimes the coordinates of a bunch of many particles, sometimes the track of one. If I save just an array
 > of numbers it can get a bit confusing. So it would be useful to be 
able to save everything needed to make the plot.
> 
You could use a file format made for scientific data storage, such as 
netCDF or HDF5.
To use netCDF files from Python you can use either ScientificPython ( 
http://dirac.cnrs-orleans.fr/plone/software/scientificpython/ ) or 
Pupynere http://pypi.python.org/pypi/pupynere/
ScientificPython is bigger and more general, Pupynere is lightweight but 
 you can run into some bugs.
For HDF5 you can use PyTables (http://www.pytables.org/).
These file types can store not only the data itself, but also it's type, 
name, units, and any other property you might like, for an arbitrary 
number of data sets. For some fields there are naming conventions 
conventions to guide you (ex: 
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.0/cf-conventions.html ).
João Silva

Troels Kofoed Jacobsen wrote:
> On Wednesday 25 February 2009 09:35:07 am sam tygier wrote:
>> I think this topic has come up before, but i don't think anything has
>> resulted from it.
>>
>> I'd like a way for saving a plot from from matplotlib, so that it can be
>> re-rendered later, possibly with a different backend, maybe to a different
>> size, and maybe with changes to the labels. This would save me having to
>> rerun the simulation that generated the plot.
> 
> I think this is a good idea, but why don't you just save your data to a file 
> and plot from a different script. If the data is only numbers you can just do 
> savetxt('data.dat',data) in you simulation script and then 
> data=loadtxt('data.dat') from your plot script...
> Now if you also just use savefig('fig') without suffix, you can just run your 
> plot script like: python plot.py -DAgg or -DPS or whatever and it will plot to 
> the default format for that backend.
> 
> Best regards
> Troels Kofoed Jacobsen
That is one method that i have used, but i don't think it is ideal. My data can be a wide range of things, sometimes the coordinates of a bunch of many particles, sometimes the track of one. If I save just an array of numbers it can get a bit confusing. So it would be useful to be able to save everything needed to make the plot.
Sam Tygier

This is now fixed in SVN. Thanks for the report.
Mike
Gregor Thalhammer wrote:
> Hi all,
>
> sorry, only reporting, no bugfix. I just discovered that an empty plot 
> with drawstyle 'steps', 'steps-pre', 'steps-mid' and 'steps-post' fails. 
> I am using matplotlib 0.98.5.2.
>
> Example
>
> plot([], [], drawstyle = 'steps')
>
> ...
> C:\Python25\lib\site-packages\matplotlib\lines.pyc in 
> _draw_steps_pre(self, renderer, gc, path, trans)
> 784 def _draw_steps_pre(self, renderer, gc, path, trans):
> 785 vertices = self._xy
> --> 786 steps = ma.zeros((2*len(vertices)-1, 2), np.float_)
> 787
> 788 steps[0::2, 0], steps[1::2, 0] = vertices[:, 0], 
> vertices[:-1, 0
> ]
> ...
>
> ValueError: negative dimensions are not allowed
>
> Gregor
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wednesday 25 February 2009 09:35:07 am sam tygier wrote:
> I think this topic has come up before, but i don't think anything has
> resulted from it.
>
> I'd like a way for saving a plot from from matplotlib, so that it can be
> re-rendered later, possibly with a different backend, maybe to a different
> size, and maybe with changes to the labels. This would save me having to
> rerun the simulation that generated the plot.
>
> Ideally this would work by having a save_plot() function, that would save
> all state of the current plot into a file. This could then be loaded by a
> program to regenerate that plot.
>
> I have made a rough prototype to demonstrate. It is incomplete. It only
> implements a very small subset of pylab.
>
> I shall attach some files (if these get mangled, then i can upload them
> somewhere).
>
> example1 and example2 are what the plot files might look like.
>
> plot.py renders the plot files.
> eg.
> plot.py example1
> plot.py example2 example.png
>
> fakepylab.py is a wrapper around pylab that record you plotting, and offers
> a save_plot() function
>
> test.py is script that uses fakepylab to create a plot file.
>
> So does any of this look useful? What more might it need to be useful?
>
> Any comments on the file format. Is there an existing standard that could
> be used instead? Would XML be better than plain ascii?
>
> Sam Tygier
I think this is a good idea, but why don't you just save your data to a file 
and plot from a different script. If the data is only numbers you can just do 
savetxt('data.dat',data) in you simulation script and then 
data=loadtxt('data.dat') from your plot script...
Now if you also just use savefig('fig') without suffix, you can just run your 
plot script like: python plot.py -DAgg or -DPS or whatever and it will plot to 
the default format for that backend.
Best regards
Troels Kofoed Jacobsen

I think this topic has come up before, but i don't think anything has resulted from it.
I'd like a way for saving a plot from from matplotlib, so that it can be re-rendered later, possibly with a different backend, maybe to a different size, and maybe with changes to the labels. This would save me having to rerun the simulation that generated the plot.
Ideally this would work by having a save_plot() function, that would save all state of the current plot into a file. This could then be loaded by a program to regenerate that plot.
I have made a rough prototype to demonstrate. It is incomplete. It only implements a very small subset of pylab.
I shall attach some files (if these get mangled, then i can upload them somewhere).
example1 and example2 are what the plot files might look like. 
plot.py renders the plot files.
eg.
plot.py example1
plot.py example2 example.png
fakepylab.py is a wrapper around pylab that record you plotting, and offers a save_plot() function
test.py is script that uses fakepylab to create a plot file.
So does any of this look useful? What more might it need to be useful?
Any comments on the file format. Is there an existing standard that could be used instead? Would XML be better than plain ascii?
Sam Tygier

Christopher Barker wrote:
> Eric Firing wrote:
>> It has been purged from the svn trunk.
> 
> Thanks. Has it been deprecated somehow? I don't want folks' code to 
> break too fast!
I have restored a stripped-down numpy-only version of numerix, with a 
prominent deprecation warning.
Eric
> 
> 
>> Now, if you can run your app after building from svn,
> 
> Well, I'm not set up to build on Windows...
> 
>> it should become obvious where the numerix import was coming from
> 
> Found it: it was wxmpl. I'm going to send a patch to Ken.
> 
> -Chris
> 
> 
> 
> 

Ken,
I've found Numerix used in wxmpl, but it's been deprecated, so I've 
replaced all the calls with direct numpy calls. However, I can't pretend 
that I've tested well at all -- all I know is that it's working for me. 
In particular, I haven't tested plotit beyond making sure it complies.
I've enclosed a zip archive with my modifications. If you have it in SVN 
somewhere I could give you a diff -- just let me know if I can help further.
Also, I see this a lot in your plotit code:
if not isinstance(x, (np.ndarray, np.ma.masked_array)):
(though you had Numerix equivalent)
What I like to do instead is call:
try:
 x = asarray(x, dtype=np.float)
except ValueError:
 raise your error here...
(and maybe a reshape call, too, to make sure it can be converted into 
that shape)
I usually don't care if I'm getting an array, as long as it can be 
turned into one...
If you do want to check the type, np.ma is a subclass of ndarray, so:
isinstance(x, np.ndarray)
should do it. That's what I've put in the code for now.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Eric Firing wrote:
> It has been purged from the svn trunk.
Thanks. Has it been deprecated somehow? I don't want folks' code to 
break too fast!
> Now, if you can run your app 
> after building from svn,
Well, I'm not set up to build on Windows...
> it should become obvious where the numerix 
> import was coming from
Found it: it was wxmpl. I'm going to send a patch to Ken.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Chris Barker wrote:
> Hi all,
> 
> I just ran into an issue with py2exe -- my app failed because various 
> numpy sub-packages weren't included. However, I wasn't using them. But 
> it failed because numerix imports them, and they weren't included 
> because it imports them with __import__
> 
> Anyway, I can work around this, but it made me wonder: is it time to 
> retire numerix? We all should be using numpy anyway.
It has been purged from the svn trunk. Now, if you can run your app 
after building from svn, it should become obvious where the numerix 
import was coming from, assuming it was in your app or in some package 
it imports.
Eric

Christopher Barker wrote:
> Eric Firing wrote:
>> It has been purged from the svn trunk.
> 
> Thanks. Has it been deprecated somehow? I don't want folks' code to 
> break too fast!
No, I guess I was in a dangerous mood--I just ripped it out. I could 
put it back with a deprecation if necessary--is it? The only nod to 
deprecation at present is that a matplotlibrc file with a numerix entry 
will trigger a warning instead of bombing.
It is still in the 0.98.5 maintenance branch, which I presume will be 
the source of the next release. One option would be to put a 
deprecation warning there, but leave the trunk as-is.
What we probably *should* have done was to put a deprecation warning in 
back when 0.98 was first released.
Eric
> 
> 
>> Now, if you can run your app after building from svn,
> 
> Well, I'm not set up to build on Windows...
> 
>> it should become obvious where the numerix import was coming from
> 
> Found it: it was wxmpl. I'm going to send a patch to Ken.
> 
> -Chris
> 
> 
> 
> 

John Hunter wrote:
> On Tue, Feb 24, 2009 at 1:44 PM, Christopher Barker
> <Chr...@no...> wrote:
> 
>>> happy get it out of matplotlib, or phase it out if necessary. I don't
>>> think it should be left there forever.
> 
> I think it can be removed. It lives on the maintenance branch 0.91.
Good point. I am in the process of removing it from the trunk. I 
should be doing this slightly differently, with a single commit, but I 
got ahead of myself, so it will take more than one. Sorry.
Eric
> 
> JDH
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a 600ドル discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Tue, Feb 24, 2009 at 3:48 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Feb 24, 2009 at 1:44 PM, Christopher Barker
> <Chr...@no...> wrote:
>
> >> happy get it out of matplotlib, or phase it out if necessary. I don't
> >> think it should be left there forever.
>
> I think it can be removed. It lives on the maintenance branch 0.91.
>
huzzah

On Tue, Feb 24, 2009 at 1:44 PM, Christopher Barker
<Chr...@no...> wrote:
>> happy get it out of matplotlib, or phase it out if necessary. I don't
>> think it should be left there forever.
I think it can be removed. It lives on the maintenance branch 0.91.
JDH

Eric Firing wrote:
> Why was numerix getting imported?
Good question -- I just figured MPL was doing it!
> Is this inherent in py2exe--that it 
> imports all subpackages of a base, if you use that base (matplotlib)?
nope -- it imports the regular old python way --just with a different 
sys.path
I'll poke into it a bit more, now that I know it shouldn't be doing it.
> Numerix is there only for the convenience of anyone who has code that 
> depends on it; it is completely unused in matplotlib itself.
That's what I was hoping.
 > I would be
> happy get it out of matplotlib, or phase it out if necessary. I don't 
> think it should be left there forever.
I agree.
- Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Chris Barker wrote:
> Hi all,
> 
> I just ran into an issue with py2exe -- my app failed because various 
> numpy sub-packages weren't included. However, I wasn't using them. But 
> it failed because numerix imports them, and they weren't included 
> because it imports them with __import__
> 
> Anyway, I can work around this, but it made me wonder: is it time to 
> retire numerix? We all should be using numpy anyway.
Why was numerix getting imported? Is this inherent in py2exe--that it 
imports all subpackages of a base, if you use that base (matplotlib)?
Numerix is there only for the convenience of anyone who has code that 
depends on it; it is completely unused in matplotlib itself. I would be 
happy get it out of matplotlib, or phase it out if necessary. I don't 
think it should be left there forever.
Eric
> 
> note that the docstring is out of date, too:
> 
> """
> 1. The value of numerix in matplotlibrc: either Numeric or numarray
> 
> 2. If none of the above is done, the default array package is Numeric.
> Because the matplotlibrc always provides *some* value for numerix
> (it has it's own system of default values), this default is most
> likely never used.
> 
> To summarize: the commandline is examined first, the rc file second,
> and the default array package is Numeric.
> """
> 
> -Chris
> 
> 
> 
> 

Hi all,
I just ran into an issue with py2exe -- my app failed because various 
numpy sub-packages weren't included. However, I wasn't using them. But 
it failed because numerix imports them, and they weren't included 
because it imports them with __import__
Anyway, I can work around this, but it made me wonder: is it time to 
retire numerix? We all should be using numpy anyway.
note that the docstring is out of date, too:
"""
1. The value of numerix in matplotlibrc: either Numeric or numarray
2. If none of the above is done, the default array package is Numeric.
 Because the matplotlibrc always provides *some* value for numerix
 (it has it's own system of default values), this default is most
 likely never used.
To summarize: the commandline is examined first, the rc file second,
and the default array package is Numeric.
"""
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Tue, Feb 24, 2009 at 9:53 AM, <jas...@cr...> wrote:
> A few weeks ago, Fernando pointed out the new canvas backend to gnuplot:
>
> http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/
>
> See also:
> http://www.nabble.com/New-terminal-driver%3A----set-term-canvas-tc21364389.html
>
> Is there anyone that has worked on anything similar in matplotlib, i.e.,
> a backend that would provide the interactive features of the GUI
> backends in a web browser? Over in the Sage project, we are very
> interested in something like this. While I can't volunteer at the
> moment to write something like a canvas backend for matplotlib (or maybe
> an interactive svg backend using javascript as well), I'm interested in
> working on this as I have time. We also might have other people in the
> Sage project interested in working on this, though we'd have to come up
> to speed on implementing a matplotlib backend first.
The starting place for implementing a backend is
matplotlib/backends/backend_template.py which has instructions on how
to proceed, which methods need to be overridden, etc. Navigation
will be a bit trickier for an html5 backend because we have only
implemented navigation for traditional GUI canvases so far.
Navigation is enabled by connecting up the backend native events to
the backend_bases.FigureCanvasBase events (button_press_event, etc).
matplotlib.backends.backend_bases.NavigationToolbar2 glues everything
together, so you might need to hack a custom html NavigationToolbar2
subclass, as we do for each GUI backend. Should be interesting! I
don't think anyone on our side has done anything with this yet, though
Charlie Moad did do an AJAZ enabled Turbogears mpl backend at one
point...

A few weeks ago, Fernando pointed out the new canvas backend to gnuplot:
http://skuld.bmsc.washington.edu/~merritt/gnuplot/canvas_demos/
See also:
http://www.nabble.com/New-terminal-driver%3A----set-term-canvas-tc21364389.html
Is there anyone that has worked on anything similar in matplotlib, i.e.,
a backend that would provide the interactive features of the GUI
backends in a web browser? Over in the Sage project, we are very
interested in something like this. While I can't volunteer at the
moment to write something like a canvas backend for matplotlib (or maybe
an interactive svg backend using javascript as well), I'm interested in
working on this as I have time. We also might have other people in the
Sage project interested in working on this, though we'd have to come up
to speed on implementing a matplotlib backend first.
Thanks,
Jason

Done.
> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...]
> Sent: Saturday, February 21, 2009 12:18 PM
> To: James Evans
> Cc: matplotlib development list
> Subject: broken examples/units/*
> 
> James,
> 
> The scripts in examples/units (and run by backend_driver.py) are broken;
> they have not been updated to match your addition of the new mandatory
> axis argument to convert() and default_units(). Would you fix them,
> please? (While you are in the neighborhood, you might also update the
> methods by switching to the @staticmethod decorator.)
> 
> The argument was also missing from the units.py docstring, but I have
> fixed that.
> 
> Thank you.
> 
> Eric

Dear all,
I asked in the user list for a way to have only left and bottom border
in figure frame
(http://sourceforge.net/mailarchive/forum.php?thread_name=1233927942.20817.1.camel%40mineat2.hmi.de&forum_name=matplotlib-users)
Tony S Yu has kindly give a solution and a implementation that maybe it
will be nice to integrate the trunk. I think this is a very nice
feature. Also, it would be good it this could be configured from de
rcParam.
Regards,
Zunbeltz
-- 
Dr. Zunbeltz Izaola
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Methods and Instruments (SF1)
Glienicker Str. 100
D-14109 Berlin
Tel (030) 8062-3179 
Fax (030) 8062-2523 
Room A 349 
-- 
Dr. Zunbeltz Izaola
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Methods and Instruments (SF1)
Glienicker Str. 100
D-14109 Berlin
Tel (030) 8062-3179 
Fax (030) 8062-2523 
Room A 349 

Hi all,
sorry, only reporting, no bugfix. I just discovered that an empty plot 
with drawstyle 'steps', 'steps-pre', 'steps-mid' and 'steps-post' fails. 
I am using matplotlib 0.98.5.2.
Example
plot([], [], drawstyle = 'steps')
...
C:\Python25\lib\site-packages\matplotlib\lines.pyc in 
_draw_steps_pre(self, renderer, gc, path, trans)
 784 def _draw_steps_pre(self, renderer, gc, path, trans):
 785 vertices = self._xy
--> 786 steps = ma.zeros((2*len(vertices)-1, 2), np.float_)
 787
 788 steps[0::2, 0], steps[1::2, 0] = vertices[:, 0], 
vertices[:-1, 0
]
...
ValueError: negative dimensions are not allowed
Gregor