headers
Glen W. Mabey | 1 Jan 16:32
Favicon

Re: [Matplotlib-users] [Numpy-discussion] which fft I should use

On Wed, Dec 27, 2006 at 12:58:24PM -0500, Robert Kern wrote:
> Gennan Chen wrote:
> > Hi! all,
> > 
> > 	There are so many fft routines in Scipy/Numpy. Does anyone know  
> > which one should be used officially?
> 
> For maximum portability and speed, use numpy.dual.fft() and its friends. That
> will use the optimized functions in scipy.fftpack if it is available and
> numpy.fft otherwise.

This was seen on numpy-discussion.  Is this the behavior implemented in
matplotlib/numerix/fft/__init__.py ?

Doesn't look like it to me ...

Glen

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Hunter | 3 Jan 19:07

Re: 2954 removal of log kwarg from bar?


Hey Eric, I'm CC-ing the devel list because some of this has
potentially far reaching consequences.

>>>>> "Eric" == Eric Firing <efiring@...> writes:

    Eric> In connection with the colorbar sizing problem I have been
    Eric> thinking about adding a function list to axes, with the
    Eric> functions to be executed early in the draw() method, to
    Eric> handle this sort of thing.  Using this mechanism to handle

I think this is a very nice idea -- I saw a talk at pycon one year about
the utility of adding hooks, eg before_somefunc_hook and after_somefunc_hook
that are customizable *for every function in your API*.  The questions are

  1) what is the right data structure -- a single callable, a
     sequence, or a dictionary registry with connect/disconnect
     semantics (eg the backend event callback handler)

  2) what is the signature (see below)

  3) which artists should support it

Most elegant, but most expensive, is something like a ordered
dictionary which is supported for every artist.  By renaming all the
artist draw methods _draw, we can do this quite simply in
backend_bases.Renderer with

def draw(self, renderer):
    for func in self.before_draw_hook.ordered_values():
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Hunter | 3 Jan 20:51

coding guide


Eric Firing had the excellent idea of making a CODING_GUIDE which
summarizes the conventions used in matplotlib development, and I've
added this to svn.  Feel free to make changes, additions and
comments.  I think we could add a lot here, including an overview of
the API.  Here  is the document I just committed::

Devs, feel free to edit this document.  This is meant to be a guide to
developers on the mpl coding practices and standards

== Committing Changes ==

When committing changes to matplotlib, there are a few things to bear
in mind.  

  * if your changes are nontrivial, please make an entry in the
    CHANGELOG

  * if you change the API, please document it in API_CHANGES, and
    consider posing to mpl-devel

  * Are your changes python2.3 compatible?  We are still trying to
    support 2.3, so avoid 2.4 only features like decorators until we
    remove 2.3 support

  * Are your changes Numeric, numarray and numpy compatible?  Try
    running simple_plot.py or image_demo.py with --Numeric, --numarray
    and --numpy (Note, someone should add examples to
    backend_driver.py which explicitly require numpy, numarray and
    Numeric so we can automatically catch these)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eric Firing | 3 Jan 20:57
Favicon
Gravatar

Re: 2954 removal of log kwarg from bar?

John Hunter wrote:
> Hey Eric, I'm CC-ing the devel list because some of this has
> potentially far reaching consequences.
> 
>>>>>> "Eric" == Eric Firing <efiring@...> writes:
> 
>     Eric> In connection with the colorbar sizing problem I have been
>     Eric> thinking about adding a function list to axes, with the
>     Eric> functions to be executed early in the draw() method, to
>     Eric> handle this sort of thing.  Using this mechanism to handle
> 
> I think this is a very nice idea -- I saw a talk at pycon one year about
> the utility of adding hooks, eg before_somefunc_hook and after_somefunc_hook
> that are customizable *for every function in your API*.  The questions are
> 
>   1) what is the right data structure -- a single callable, a
>      sequence, or a dictionary registry with connect/disconnect
>      semantics (eg the backend event callback handler)
> 
>   2) what is the signature (see below)
> 
>   3) which artists should support it
> 
> Most elegant, but most expensive, is something like a ordered
> dictionary which is supported for every artist.  By renaming all the
> artist draw methods _draw, we can do this quite simply in
> backend_bases.Renderer with
> 
> def draw(self, renderer):
>     for func in self.before_draw_hook.ordered_values():
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Firing | 3 Jan 21:19
Favicon
Gravatar

Re: coding guide


>   * Are your changes python2.3 compatible?  We are still trying to
>     support 2.3, so avoid 2.4 only features like decorators until we
>     remove 2.3 support

Good, I thought we were still restricted to 2.2!

Does this mean boilerplate.py should be updated?  (Or maybe it isn't 
worth fiddling with it.)
# wrap the plot commands defined in axes.  The code generated by this
# file is pasted into pylab.py.  We did try to do this the smart way,
# with callable functions and new.function, but could never get the
# docstrings right for python2.2.  See
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/dcd63ec13096a0f6/17739e70ac6f710c?lnk=gst&q=dcd63ec13096a0f6&rnum=1#17739e70ac6f710c

Eric

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 2 comments |
headers
John Hunter | 3 Jan 22:08

Re: coding guide

>>>>> "Eric" == Eric Firing <efiring@...> writes:

    >> * Are your changes python2.3 compatible?  We are still trying
    >> to support 2.3, so avoid 2.4 only features like decorators
    >> until we remove 2.3 support

    Eric> Good, I thought we were still restricted to 2.2!

I was wondering how long it would take for someone to notice that
<wink>

I think we could lose python2.2 support if there is a good reason.  Is
anyone still using it?  I'll also post to the user's list.  Perhaps in
the next release we should issue deprecation warnings for 2.2 and
encourage people to post to the list if they have an objection.
Typically with these things you don't see complaints until you take
something away.

We haven't been compiling 2.2 for windows for sometime now.

JDH

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
John Hunter | 3 Jan 22:42

Re: 2954 removal of log kwarg from bar?

>>>>> "Eric" == Eric Firing <efiring@...> writes:

    Eric> Nice, simple, elegant, but it doesn't quite match what I had
    Eric> in mind for axes.  I was thinking that the place to put the
    Eric> hook call is inside the draw() method, so it can take
    Eric> advantage of the intial work done there: getting a cached
    Eric> renderer, checking for visibility.  Maybe this doesn't
    Eric> matter.

Well for these two pieces, perhaps the method should look like

    def draw(self, renderer=None, **kwargs):
        if renderer is None:
            renderer = self._cachedRenderer

        if renderer is None:
            raise RuntimeError('No renderer defined')
        if not self.get_visible(): return

        for func in self.before_draw_hook.ordered_values():
            func(self, renderer)
        self._draw(renderer, **kwargs)
        for func in self.after_draw_hook.ordered_values():
            func(self, renderer)

and perhaps the renderer caching should be done at the figure level

       if renderer is None:
            renderer = self.figure._cachedRenderer
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Hunter | 4 Jan 00:05

Re: coding guide

>>>>> "John" == John Hunter <jdhunter@...> writes:
    John> I think we could lose python2.2 support if there is a good
    John> reason.  Is anyone still using it?  I'll also post to the
    John> user's list.  Perhaps in the next release we should issue
    John> deprecation warnings for 2.2 and encourage people to post to
    John> the list if they have an objection.  Typically with these
    John> things you don't see complaints until you take something
    John> away.

Well, I was just about to post to the user list to see if anyone
objected to remove 2.2 support, and wondered, do we really support 2.2
currently?  I just tried to compile under 2.2 and got

peds-pc311:~/mpl> sudo python2.2 setup.py install
Traceback (most recent call last):
  File "setup.py", line 63, in ?
    from setupext import build_agg, build_gtkagg, build_tkagg,
    build_wxagg,\
  File "setupext.py", line 120, in ?
    win32_compiler = get_win32_compiler()
  File "setupext.py", line 117, in get_win32_compiler
    if 'mingw32' in v:
TypeError: 'in <string>' requires character as left operand

And this has probably been in there for a while.  So we haven't
supported 2.2 for sometime and noone is complaining so let's make 2.3
the official target rather than fix this.  At least 2.3 compiles and
runs.

I'll update the docs and website when I get a minute.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Firing | 4 Jan 00:36
Favicon
Gravatar

Re: coding guide

John Hunter wrote:
[...]
I am in the process of changing your shiny new kwdocd machinery 
slightly.  I added artist.kwdoc so that

> artist.kwdocd['Line2D'] = '\n'.join(artist.ArtistInspector(Line2D).pprint_setters(leadingspace=12))
> 

becomes

artist.kwdocd['Line2D'] = artist.kwdoc(Line2D)

> Then in any function accepting Line2D passthrough kwargs, eg
> matplotlib.axes.Axes.plot
> 
>     def plot(self, *args, **kwargs):
>         """
> 	Some stuff omitted
> 
>         The kwargs are Line2D properties:
> %(Line2D)s

and the line above is changed to be indented the same as the rest of the 
string (improves readability to my eye)

> 
>         kwargs scalex and scaley, if defined, are passed on
>         to autoscale_view to determine whether the x and y axes are
>         autoscaled; default True.  See Axes.autoscale_view for more
>         information
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Hunter | 4 Jan 04:58

Re: coding guide

>>>>> "Eric" == Eric Firing <efiring@...> writes:

    Eric> I can continue making the necessary changes if that is OK
    Eric> with you, but I don't want our versions to get tangled up if
    Eric> you are still working on this aspect, or if you don't like
    Eric> the strategy modification outlined above.  I committed
    Eric> dedent but not the other changes.

This looks very good and a definite improvement.  You might consider
extending this a bit to have a custom class that handles all the
details.  The general sketch is

class Kwdocd(dict):

    def inspect(self, artist):
        # add artist to kwdocd, using __name__ or __class__ to get the key

    def expand_doc(self, method):
        # interpolate kwdocd into method.__doc__ altering
        # method.__doc__ in place

kwdocd = Kwdocd()

and then we have

class Line2D:
    pass

kwdocd.inspect(Line2D)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane