matplotlib-devel Mailing List for matplotlib

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