matplotlib-devel Mailing List for matplotlib

Manuel Metz wrote:
> May I ask again: Is there any interest in a step-plotting function?
Yes, so thanks for taking the initiative and for being persistent.
> 
> If so, who will commit the patch? Do I have to add more myself 
> (documentation for sure needs to be added, what else ?)
Please add a docstring and a simple demo suitable for the examples 
subdirectory.  I will commit the patch, or some modification of it.
> 
> Manuel
> 
> Manuel Metz wrote:
>> Hi,
>> okay, I have added a keyword 'where' as suggested. I also now changed 
>> the way the incoming data is converted. I took this from the axes.pie() 
>> function. I don't know much about the unit types yet :-(
>>
>> Concerning masked arrays: Do I have to consider something special there?
I think that if you change the npy.asarray to npyma.array, and similarly 
for the zeros(), that will provide basic masked array support. Please 
look at masked_demo.py for an example of the use of masked arrays.  (It 
is very artificial, of course.  A typical use case for masked arrays is 
when you have a data stream with some bad points that you want to edit 
out, but you want to keep the array dimensions unchanged.  In the case 
of a line plot or step plot, you want the line to break at the missing 
point to show that a point has been removed.)

Eric

>>
>> Manuel
>>
>> Ted Drain wrote:
>>> At 10:36 AM 8/14/2007, Eric Firing wrote:
>>>> Ted Drain wrote:
>>>>> Manuel,
>>>>> We do plots like this all the time.  One thing we've found that's 
>>>>> nice to have is a keyword that controls when the increase in y 
>>>>> happens.  We use a step style keyword that can be 'pre' (go up then 
>>>>> right), 'post' (go right then up), and 'mid' (right 0.5, up, right 
>>>>> 0.5).
>>>> Good idea.
>>>>> Regarding your patch, you might want to check other areas in MPL for 
>>>>> data processing examples.  I could be wrong but I'm not sure you can 
>>>>> assume that incoming data is a float.  Some of the unit conversion 
>>>>> examples or the line collection code might have better examples.
>>>> Incoming data can be any numeric type, but it ends up getting 
>>>> converted to the default float type (not float32) internally.
>>>>
>>>> Whenever possible, it is good to support masked array input.
>>> Agreed - but the way the patch was written, I don't think it will 
>>> support anything but float (especially not the unit types).
>>>
>>>> Eric
>>>>> Ted
>>>>> At 07:59 AM 8/14/2007, Manuel Metz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have created a patch against latest svn that adds a function step 
>>>>>> to the axes class to plot step-functions ;-) It's really simple but 
>>>>>> nice ... Any interest in adding this?
>>>>>>
>>>>>> Manuel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Index: axes.py
>>>>>> ===================================================================
>>>>>> --- axes.py     (revision 3709)
>>>>>> +++ axes.py     (working copy)
>>>>>> @@ -4995,6 +4995,18 @@
>>>>>>                                                   steps=[1, 2, 5, 10],
>>>>>>                                                   integer=True))
>>>>>>          return im
>>>>>> +
>>>>>> +    def step(self, x, y, *args, **kwargs):
>>>>>> +        x2 = npy.zeros((2*len(x)), npy.float32)
>>>>>> +        y2 = npy.zeros((2*len(x)), npy.float32)
>>>>>> +
>>>>>> +        x2[0::2] = x
>>>>>> +        x2[1::2] = x
>>>>>> +
>>>>>> +        y2[1::2] = y
>>>>>> +        y2[2::2] = y[:-1]
>>>>>> +
>>>>>> +        self.plot(x2, y2, *args, **kwargs)
>>>>>>
>>>>>>  class SubplotBase:
>>>>>>      """
>>>>>>
>>>>>> ------------------------------------------------------------------------- 
>>>>>>
>>>>>> This SF.net email is sponsored by: Splunk Inc.
>>>>>> Still grepping through log files to find problems?  Stop.
>>>>>> Now Search log events and configuration files using AJAX and a 
>>>>>> browser.
>>>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.net email is sponsored by: Splunk Inc.
>>>>> Still grepping through log files to find problems?  Stop.
>>>>> Now Search log events and configuration files using AJAX and a browser.
>>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Sorry for taking so long to respond -- I was at SciPy and wanted to make 
sure I had the time to sit down and look at this before responding.

Paul Kienzle wrote:
> On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote:
>> I don't know if we ever reached consensus on how to specify math text 
>> vs. regular text.  I agree with Eric that it's down to two options: 
>> using a new kw argument (probably format="math" to be most future-proof) 
>> or Math('string').  I don't think I have enough "historical perspective" 
>> to really make the call but I do have a concern about the second option 
>> that it may be confusing depending on how "Math" is imported.  (It may 
>> have to be pylab.Math in some instances but not in others.)  But I don't 
>> have a strong objection.
>>
>> Any last objections to going with the new keyword argument?
> 
> I'm guessing that this discussion is already closed, but I would still
> like to propose another option, just like the original: specify the
> format in the string itself by requiring a leading '$'.  
> 
> For example:
> 
>    text(x, y, r'$\sin(x)$')
> 
> or for those functions not starting with math:
> 
>    text(x, y, r'$$phase $[0,2\pi)$')

Unfortunately, this will break if text.usetex is True.  Double-dollar 
signs in LaTeX delimits "display math" mode.

> This is a variant on Math(r'$\sin(x)$') which is a bit more compact.
 >
> As has been pointed out elsewhere, whether or not the string contains
> tex markup is a property of the string, not a property of the function
> that use the string.

I agree with you in a semantic sense.  However, does that distinction 
really matter at the end of the day?  Couldn't the same argument be made 
for the color or font of the text?  All of them have to do with how the 
string is rendered.  I think the oddball (for matplotlib) nature of this 
syntax and the import namespace details make this at least equally as 
cumbersome as the "markup" keyword.  But it's subjective, and I'm 
willing to change the code if there's consensus on this.

> Note that the format keyword will be required for 
> all functions which have string inputs, and may cause problems if there 
> are multiple string inputs to the function.  legend() in particular may 
> be a problem.

legend() doesn't currently accept a "markup" keyword, but obviously it 
should (if we decide to stick with the "markup" keyword).  (And there 
are undoubtedly more holes like this to plug up).  However, I don't know 
if it is necessary to specify the markup of each individual legend 
string, now that math can be easily interleaved with non-math.  Isn't 
that just adding options where none is needed?

As I see it, the only reason to have this stuff optional at all is 
because it's surprising for '$'s to be delimiters.  Performance is a 
very minor issue.  I "benchmarked" global mathtext vs. optional mathtext 
on the "backend_driver.py" script (which admittedly is not a great 
benchmark, but it's something), and the timing differences seem to be 
below the noise threshold:

    all math:       0.78s  0.67s  0.72s
    optional math:  0.72s  0.75s  0.68s

So I don't see why in a legend you would want some labels to be 
interpreted as having math and some without.  If you need a real dollar 
sign, with math on, you can always use "\$".

On a related note, there was a recent thread on matplotlib-users about 
usetex being a global setting:

http://www.mail-archive.com/mat...@li.../msg04101.html

I'm concerned about consistency and/or redundancy between this and the 
new markup kwarg.  I don't know whether or not "usetex" being 
"all-or-nothing" is desirable.  But we could meet in the middle by doing 
one of the following:

   a) only send text to LaTeX for rendering when text.usetex=True and 
markup="tex".  (Which makes usetex=True behave a little more like 
usetex=False).

   b) add another value to markup, to render text with LaTeX.  (If we 
do, I would suggest changing the kwarg to "text_renderer" and having the 
values be "normal", "mathtext" and "latex" or something)

   c) make markup="tex" be all-or-nothing as well (that is, keep the 
rcParam, but drop the kwarg.)  With this flag, you're basically saying 
"I know how to deal with $'s".

b) is probably the most flexible (maybe too flexible, as I can't see why 
one would want to use all three types of rendering in the same plot). 
a) and b) would break backward compatibility with 0.90.1, while c) would 
not.

Any thoughts?

Cheers,
Mike

On Saturday 18 August 2007 12:44:20 pm Fernando Perez wrote:
> Here's some interesting info.  I'm sitting here with Dave Peterson,
> from Enthought, and we've done a bunch of profiling that pointed to
> setuptools, not Traits, being the culprit for the time increase.
> We've now just done an install  of Traits *without* any setuptools
> (right now that requires manual surgery, but later it can be done
> automatically if needed).  Here are the resulting times:
>
> # Using traits
>
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> *** Using Traits!!!
> 1.844u 0.212s 0:02.13 96.2%     0+0k 0+0io 0pf+0w
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> *** Using Traits!!!
> 1.840u 0.216s 0:02.58 79.4%     0+0k 0+0io 0pf+0w
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> *** Using Traits!!!
> 1.836u 0.196s 0:02.12 95.2%     0+0k 0+0io 0pf+0w
>
> # NOT Using traits
>
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> 2.200u 0.280s 0:02.67 92.8%     0+0k 0+0io 0pf+0w
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> 2.248u 0.220s 0:02.74 89.7%     0+0k 0+0io 0pf+0w
> maqroll[mpl-traits-debug]> time ./simple_plot.py
> 2.216u 0.244s 0:02.72 90.0%     0+0k 0+0io 0pf+0w
>
>
> As you'll notice, the traits times are *lower*.  This is what my gut
> told me, since I know how tight the traits code is.  The point is that
> traits can actually give you a performance *benefit*, not a cost.  The
> problem is with setuptools, which goes ballistic on the filesystem at
> init time.  The profiles I sent earlier have already all the
> information on that, if you use kcachegrind to see it (that's how Dave
> and I pinned it down).
>
> This hopefully settles the argument on the performance side.  We'll
> leave the final decision up to you guys, obviously.  For IPython, this
> settles the matter and we're going with traits, with setuptools banned
> til further notice from ipython.

Thank you Dave and Fernando for getting to the bottom of this. 

A lot of work has gone in to making mpl compatible with setuptools. In fact, 
we require it to install on python-2.3. Are the setuptools developers aware 
of the problem?

Darren

May I ask again: Is there any interest in a step-plotting function?

If so, who will commit the patch? Do I have to add more myself 
(documentation for sure needs to be added, what else ?)

Manuel

Manuel Metz wrote:
> Hi,
> okay, I have added a keyword 'where' as suggested. I also now changed 
> the way the incoming data is converted. I took this from the axes.pie() 
> function. I don't know much about the unit types yet :-(
> 
> Concerning masked arrays: Do I have to consider something special there?
> 
> Manuel
> 
> Ted Drain wrote:
>> At 10:36 AM 8/14/2007, Eric Firing wrote:
>>> Ted Drain wrote:
>>>> Manuel,
>>>> We do plots like this all the time.  One thing we've found that's 
>>>> nice to have is a keyword that controls when the increase in y 
>>>> happens.  We use a step style keyword that can be 'pre' (go up then 
>>>> right), 'post' (go right then up), and 'mid' (right 0.5, up, right 
>>>> 0.5).
>>> Good idea.
>>>> Regarding your patch, you might want to check other areas in MPL for 
>>>> data processing examples.  I could be wrong but I'm not sure you can 
>>>> assume that incoming data is a float.  Some of the unit conversion 
>>>> examples or the line collection code might have better examples.
>>>
>>> Incoming data can be any numeric type, but it ends up getting 
>>> converted to the default float type (not float32) internally.
>>>
>>> Whenever possible, it is good to support masked array input.
>>
>> Agreed - but the way the patch was written, I don't think it will 
>> support anything but float (especially not the unit types).
>>
>>> Eric
>>>> Ted
>>>> At 07:59 AM 8/14/2007, Manuel Metz wrote:
>>>>> Hi,
>>>>>
>>>>> I have created a patch against latest svn that adds a function step 
>>>>> to the axes class to plot step-functions ;-) It's really simple but 
>>>>> nice ... Any interest in adding this?
>>>>>
>>>>> Manuel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Index: axes.py
>>>>> ===================================================================
>>>>> --- axes.py     (revision 3709)
>>>>> +++ axes.py     (working copy)
>>>>> @@ -4995,6 +4995,18 @@
>>>>>                                                   steps=[1, 2, 5, 10],
>>>>>                                                   integer=True))
>>>>>          return im
>>>>> +
>>>>> +    def step(self, x, y, *args, **kwargs):
>>>>> +        x2 = npy.zeros((2*len(x)), npy.float32)
>>>>> +        y2 = npy.zeros((2*len(x)), npy.float32)
>>>>> +
>>>>> +        x2[0::2] = x
>>>>> +        x2[1::2] = x
>>>>> +
>>>>> +        y2[1::2] = y
>>>>> +        y2[2::2] = y[:-1]
>>>>> +
>>>>> +        self.plot(x2, y2, *args, **kwargs)
>>>>>
>>>>>  class SubplotBase:
>>>>>      """
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.net email is sponsored by: Splunk Inc.
>>>>> Still grepping through log files to find problems?  Stop.
>>>>> Now Search log events and configuration files using AJAX and a 
>>>>> browser.
>>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On 8/20/07, Michael Droettboom <md...@st...> wrote:
> 
>> UTF-8 is my default system encoding, so I didn't catch this.  I just
>> fixed the comment (the unicode character is unnecessary to get the point
>> across and wasonly in there due to a cut-and-paste accident anyway).
> 
>> I have committed this patch to SVN.
> 
> I thought last time this came up we agreed not to use unicode in the
> src files.  Is it possible to remove the unicode entirely?

That's exactly what I did.  Sorry I wasn't clear -- I only committed the 
second and unrelated patch to SVN (which eliminates a Gtk version check 
within a method call).

Cheers,
Mike

On 8/20/07, Michael Droettboom <md...@st...> wrote:

> UTF-8 is my default system encoding, so I didn't catch this.  I just
> fixed the comment (the unicode character is unnecessary to get the point
> across and wasonly in there due to a cut-and-paste accident anyway).

> I have committed this patch to SVN.

I thought last time this came up we agreed not to use unicode in the
src files.  Is it possible to remove the unicode entirely?

JDH

Fernando Perez wrote:
> Hi all,
> 
> here's a small patch for two little things I saw today:
> 
> 1. The new mathtext has some unicode in it and on my system, python2.5
> was throwing a syntax error due to the lack of an encoding
> declaration.  I just stuck utf-8 though I don't know if that's really
> corrrect.  Since the complaint was about characters in a comment it
> doesn't matter too much, but it still might be a good idea to do the
> right thing, so someone who actually knows should check what the right
> value is.

UTF-8 is my default system encoding, so I didn't catch this.  I just 
fixed the comment (the unicode character is unnecessary to get the point 
across and wasonly in there due to a cut-and-paste accident anyway).

> 2. Move a simple version check from runtime to class declaration time
> in the cairo backend.  While this causes a repeated line, the code is
> small enough that it seems cleaner not to pay the version check on
> every method call.

I have committed this patch to SVN.

Cheers,
Mike

> 
> ------------------------------------------------------------------------
> 
> Index: lib/matplotlib/mathtext.py
> ===================================================================
> --- lib/matplotlib/mathtext.py	(revision 3715)
> +++ lib/matplotlib/mathtext.py	(working copy)
> @@ -1,3 +1,4 @@
> +# -*- coding: utf-8 -*-
>  r"""
>  
>  OVERVIEW
> Index: lib/matplotlib/backends/backend_gtkcairo.py
> ===================================================================
> --- lib/matplotlib/backends/backend_gtkcairo.py	(revision 3715)
> +++ lib/matplotlib/backends/backend_gtkcairo.py	(working copy)
> @@ -29,12 +29,16 @@
>  
>  
>  class RendererGTKCairo (backend_cairo.RendererCairo):
> -    def set_pixmap (self, pixmap):
> -        if gtk.pygtk_version >= (2,7,0):
> +    # Do the version check at class declaration time, so we don't pay for it on
> +    # every invocation of the set_pixmap method.
> +    if gtk.pygtk_version >= (2,7,0):
> +        def set_pixmap (self, pixmap):
>              self.ctx = pixmap.cairo_create()
> -        else:
> +            self.ctx.save()  # restore, save  - when call new_gc()
> +    else:
> +        def set_pixmap (self, pixmap):
>              self.ctx = cairo.gtk.gdk_cairo_create (pixmap)
> -        self.ctx.save()  # restore, save  - when call new_gc()
> +            self.ctx.save()  # restore, save  - when call new_gc()
>  
>  
>  class FigureCanvasGTKCairo(FigureCanvasGTK):
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,

here's a small patch for two little things I saw today:

1. The new mathtext has some unicode in it and on my system, python2.5
was throwing a syntax error due to the lack of an encoding
declaration.  I just stuck utf-8 though I don't know if that's really
corrrect.  Since the complaint was about characters in a comment it
doesn't matter too much, but it still might be a good idea to do the
right thing, so someone who actually knows should check what the right
value is.

2. Move a simple version check from runtime to class declaration time
in the cairo backend.  While this causes a repeated line, the code is
small enough that it seems cleaner not to pay the version check on
every method call.

Cheers,

f