matplotlib-devel Mailing List for matplotlib (Page 2)

Mike,
Thank you, that's wonderful! I knew dedent was a major speed problem, 
but I couldn't think of how to speed it up, and to my eye keeping the 
docstrings properly indented in the code makes a *huge* difference in 
readability.
Eric
md...@us... wrote:
> Revision: 3744
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3744&view=rev
> Author: mdboom
> Date: 2007年08月28日 12:17:21 -0700 (2007年8月28日)
> 
> Log Message:
> -----------
> Use regular expressions to do dedenting. This is ~15X faster than the
> old implementation. dedent accounted for around 30% of the time spent
> in "import pylab", so was probably worthy of optimization, even if this
> regex approach is less clear. The results are identical to the old
> implementation, with the exception of a single docstring (in
> backend_bases.py) that needed to be fixed.

Mike,
After a quick test, I am puzzled: running "backend_driver.py Template"
takes 0.49 minutes on my machine before and after this change, so the 
dedenting time must have been less than I thought.
Eric
md...@us... wrote:
> Revision: 3744
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=3744&view=rev
> Author: mdboom
> Date: 2007年08月28日 12:17:21 -0700 (2007年8月28日)
> 
> Log Message:
> -----------
> Use regular expressions to do dedenting. This is ~15X faster than the
> old implementation. dedent accounted for around 30% of the time spent
> in "import pylab", so was probably worthy of optimization, even if this
> regex approach is less clear. The results are identical to the old
> implementation, with the exception of a single docstring (in
> backend_bases.py) that needed to be fixed.

Michael Droettboom wrote:
> Darren Dale wrote:
>> On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
>>> Darren Dale wrote:
>>>> If you want all that flexibility, why not do it in the usual way:
>>>>
>>>> #mathtext.it.family : 'serif'
>>>> #mathtext.it.style : 'oblique'
>>> That seems reasonable. I think I had a mental block around this because
>>> of the verbosity (and seeing a font specification as a single unit), but
>>> it does seem to fit in much better with the existing options (i.e. a
>>> subset of font.*).
>>>
>>> *IF* fontconfig is ever adopted, we could use fontconfig patterns as an
>>> alternative, which are at least some kind of standard.
>>
>> Right:
>> mathtext.it : serif-12:italic # use the default serif, 12 pt italic
>> or
>> mathtext.it : times:italic # use the times italic font, default size
>>
>> Could this syntax be adopted, even without fontconfig? Then if we 
>> decided to use fontconfig in the future, the disruption would not be 
>> too great.
> 
> Sure, it's certainly an easy enough format to support.
> 
> Of course, the matching algorithm used by font_manager.py is different 
> from fontconfig. font_manager.py essentially looks for an exact match 
> or falls back to a single default. fontconfig does a nearest neighbor 
> search, so often finds a better alternative. So even if they use the 
> same syntax, the results will be different (in some side cases) if we 
> ever move over to fontconfig. (There are pros and cons to using 
> fontconfig already discussed on this list. I'm not really advocating 
> for or against it myself.)
> 
> Still, IMHO, it's worth supporting this syntax now even though users may 
> need to change their font specifiers later -- those changes should be 
> more minor than if we go with
> 
> #mathtext.it.family : 'serif'
> #mathtext.it.style : 'oblique'
> 
> now.
I just committed code to support fontconfig patterns on all of the 
mathtext.* fonts. You can also use fontconfig patterns in the pylab and 
OO interfaces -- e.g.:
 title("This is my title", fontproperties="Helvetica:italic")
(Note this doesn't actually use fontconfig -- I've just borrowed its 
font-specification syntax.)
I was thinking we probably want to collapse the following options down 
to one as well --->
#font.family : sans-serif
#font.style : normal
#font.variant : normal
#font.weight : medium
#font.stretch : normal
# note that font.size controls default text sizes. To configure
# special text sizes tick labels, axes, labels, title, etc, see the rc
# settings for axes and ticks. Special text sizes can be defined
# relative to font.size, using the following values: xx-small, x-small,
# small, medium, large, x-large, xx-large, larger, or smaller
#font.size : 12.0
probably to "font.default" ? For backward compatibility, we probably 
want to continue to support these, but "font.default" would override 
them if provided. Any ideas on how to best do that? I only have a 
rough sense of where the new traited config stuff is going wrt backward 
compatibility etc.
Cheers,
Mike

Jouni K. Seppänen wrote:
> On OS X, using the pdf backend, I get the exception "RuntimeError:
> TrueType font is missing table" when running examples/fonts_demo_kw.py,
> because ttconv is trying to load /System/Library/Fonts/Times.dfont as a
> TrueType font, which it of course is not.
> 
> A simple solution would be to limit the font searching algorithm to only
> look for files matching *.ttf, but that would unnecessarily limit the
> Agg-based backends, since freetype does understand and render dfont
> files. The best solution would be to implement dfont support in the pdf
> backend, but I have no idea how complicated that would be.
Unfortunately, .dfont files aren't used *correctly* by the font manager 
at present, either. .dfont files can contain multiple ttf files -- so 
as a .ttf file always contains a single weight/angle/stretch etc., a 
.dfont usually contains a number of different versions of the same font 
family. The FT2Font class underlying the font manager is hardcoded to 
always look at only the first ttf in the .dfont file. That can probably 
be fixed, of course, but .dfont files will have to be treated 
differently from .ttf files in the font manager anyway.
FWIW, fontconfig 2.4.2 (what MacPorts gives me) doesn't seem to handle 
.dfonts correctly either.
$ fc-match -v HelveticaNeue:italic
Pattern has 28 elts (size 32)
 family: "Helvetica Neue"(s)
	<snip>
 file: "/Library/Fonts/HelveticaNeue.dfont"(s)
 index: 0(i)(s)
$ fc-match -v HelveticaNeue:bold
Pattern has 28 elts (size 32)
 family: "Helvetica Neue"(s)
	<snip>
 file: "/Library/Fonts/HelveticaNeue.dfont"(s)
 index: 0(i)(s)
I would have expected the index value to be different. But maybe I'm 
just misusing/misunderstanding fontconfig...
> What would be a reasonable interim solution? Perhaps the font manager
> should identify the file type of each font file it knows about, so e.g.
> the pdf backend could request a list of just the TrueType fonts.
> 
> (See also:
> http://article.gmane.org/gmane.comp.python.matplotlib.general/10069 )
I definitely agree with what you're saying. Taking a step back, though, 
I worry about the user needing to know about the surprises in the 
font-compatibility space. Say a user develops a plot using an 
interactive backend (with Agg), and then decides to publish the plot 
using PDF and is surprised when it picks up completely different fonts. 
 At the very least we should find a way to inform the user that the 
first choice font (a dfont) was bypassed in favor of a ttf font, since 
the backend doesn't support it.
Part of me is thinking that for simplicity, we should only support .ttf 
fonts everywhere (excluding text.usetex == True), as that is the lowest 
common denominator, but I know that might be limited and disappointing 
to some. Mac users could run fondu over their fonts to get .ttfs from 
.dfonts.
Cheers,
Mike

On OS X, using the pdf backend, I get the exception "RuntimeError:
TrueType font is missing table" when running examples/fonts_demo_kw.py,
because ttconv is trying to load /System/Library/Fonts/Times.dfont as a
TrueType font, which it of course is not.
A simple solution would be to limit the font searching algorithm to only
look for files matching *.ttf, but that would unnecessarily limit the
Agg-based backends, since freetype does understand and render dfont
files. The best solution would be to implement dfont support in the pdf
backend, but I have no idea how complicated that would be.
What would be a reasonable interim solution? Perhaps the font manager
should identify the file type of each font file it knows about, so e.g.
the pdf backend could request a list of just the TrueType fonts.
(See also:
http://article.gmane.org/gmane.comp.python.matplotlib.general/10069 )
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Darren Dale wrote:
> On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
>> Darren Dale wrote:
>>> If you want all that flexibility, why not do it in the usual way:
>>>
>>> #mathtext.it.family : 'serif'
>>> #mathtext.it.style : 'oblique'
>> That seems reasonable. I think I had a mental block around this because
>> of the verbosity (and seeing a font specification as a single unit), but
>> it does seem to fit in much better with the existing options (i.e. a
>> subset of font.*).
>>
>> *IF* fontconfig is ever adopted, we could use fontconfig patterns as an
>> alternative, which are at least some kind of standard.
> 
> Right: 
> 
> mathtext.it : serif-12:italic # use the default serif, 12 pt italic
> or
> mathtext.it : times:italic # use the times italic font, default size
> 
> Could this syntax be adopted, even without fontconfig? Then if we decided to 
> use fontconfig in the future, the disruption would not be too great.
Sure, it's certainly an easy enough format to support.
Of course, the matching algorithm used by font_manager.py is different 
from fontconfig. font_manager.py essentially looks for an exact match 
or falls back to a single default. fontconfig does a nearest neighbor 
search, so often finds a better alternative. So even if they use the 
same syntax, the results will be different (in some side cases) if we 
ever move over to fontconfig. (There are pros and cons to using 
fontconfig already discussed on this list. I'm not really advocating 
for or against it myself.)
Still, IMHO, it's worth supporting this syntax now even though users may 
need to change their font specifiers later -- those changes should be 
more minor than if we go with
#mathtext.it.family : 'serif'
#mathtext.it.style : 'oblique'
now.
If we go this way, it would also be worthwhile to support this syntax 
internally (anywhere a FontProperties object is currently accepted it 
could alternatively be a fontconfig string.)
Cheers,
Mike

On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
> Darren Dale wrote:
> > On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
> >> I realize it's hacky. The most obvious alternative is to expect a
> >> dictionary here, e.g.:
> >>
> >> rm = { 'family': ['serif'], 'style': 'oblique' }
> >>
> >> But that's less like the FontProperties constructor.
> >
> > Why do you say that? Here is the constructor:
> >
> > def __init__(self,
> > family = None,
> > style = None,
> > variant= None,
> > weight = None,
> > stretch= None,
> > size = None,
> > fname = None,
> > ):
> >
> > wouldnt FontProperties(**rm) work?
>
> Sure. I just meant that
>
> rm = { 'family': ['serif'], 'style': 'oblique' }
>
> is syntactically different from
>
> rm = FontProperties(['serif'], style='oblique')
>
> >> My goal was to
> >> make specifying fonts as similar as possible to the FontProperties
> >> object so the user doesn't have to learn a new syntax. Is there a
> >> better way to do this with Traits? Can the user specify the arguments
> >> (with keyword arguments) to a constructor?
> >
> > I think this is getting a little out of hand, isnt it?:
> >
> > #mathtext.cal : ['cursive']
> > #mathtext.rm : ['serif']
> > #mathtext.tt : ['monospace']
> > #mathtext.it : ['serif'], style='oblique'
> > #mathtext.bf : ['serif'], weight='bold'
> > #mathtext.sf : ['sans-serif']
> >
> > That means we have comma-separated strings for lists of fonts, but
> > bracket-enclosed comma-separated quoted strings for mathtext properties.
>
> Well, they are different beasts. The former only specifies a choice of
> families. The latter specifies a specific font. I didn't intend to
> invent something new for mathtext -- there were no other instances where
> a full set of font properties was required to specify a font. (Sure
> font.* is a sort of example of that, but it includes other things as
> well...)
>
> > If you want all that flexibility, why not do it in the usual way:
> >
> > #mathtext.it.family : 'serif'
> > #mathtext.it.style : 'oblique'
>
> That seems reasonable. I think I had a mental block around this because
> of the verbosity (and seeing a font specification as a single unit), but
> it does seem to fit in much better with the existing options (i.e. a
> subset of font.*).
>
> *IF* fontconfig is ever adopted, we could use fontconfig patterns as an
> alternative, which are at least some kind of standard.
Right: 
mathtext.it : serif-12:italic # use the default serif, 12 pt italic
or
mathtext.it : times:italic # use the times italic font, default size
Could this syntax be adopted, even without fontconfig? Then if we decided to 
use fontconfig in the future, the disruption would not be too great.
Darren 

Darren Dale wrote:
> On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
>> I realize it's hacky. The most obvious alternative is to expect a
>> dictionary here, e.g.:
>>
>> rm = { 'family': ['serif'], 'style': 'oblique' }
>>
>> But that's less like the FontProperties constructor. 
> 
> Why do you say that? Here is the constructor:
> 
> def __init__(self,
> family = None,
> style = None,
> variant= None,
> weight = None,
> stretch= None,
> size = None,
> fname = None,
> ):
> 
> wouldnt FontProperties(**rm) work?
Sure. I just meant that
 rm = { 'family': ['serif'], 'style': 'oblique' }
is syntactically different from
 rm = FontProperties(['serif'], style='oblique')
>> My goal was to 
>> make specifying fonts as similar as possible to the FontProperties
>> object so the user doesn't have to learn a new syntax. Is there a
>> better way to do this with Traits? Can the user specify the arguments
>> (with keyword arguments) to a constructor?
> 
> I think this is getting a little out of hand, isnt it?:
> 
> #mathtext.cal : ['cursive']
> #mathtext.rm : ['serif']
> #mathtext.tt : ['monospace']
> #mathtext.it : ['serif'], style='oblique'
> #mathtext.bf : ['serif'], weight='bold'
> #mathtext.sf : ['sans-serif']
> 
> That means we have comma-separated strings for lists of fonts, but 
> bracket-enclosed comma-separated quoted strings for mathtext properties.
Well, they are different beasts. The former only specifies a choice of 
families. The latter specifies a specific font. I didn't intend to 
invent something new for mathtext -- there were no other instances where 
a full set of font properties was required to specify a font. (Sure 
font.* is a sort of example of that, but it includes other things as 
well...)
> If you want all that flexibility, why not do it in the usual way:
> 
> #mathtext.it.family : 'serif'
> #mathtext.it.style : 'oblique'
That seems reasonable. I think I had a mental block around this because 
of the verbosity (and seeing a font specification as a single unit), but 
it does seem to fit in much better with the existing options (i.e. a 
subset of font.*).
*IF* fontconfig is ever adopted, we could use fontconfig patterns as an 
alternative, which are at least some kind of standard.
> But is that much flexibility needed?
The flexibility is certainly needed, and came directly out of a request 
on matplotlib-user. There are cases where you want the variable names 
(the 'it' font in TeX parlance) to be in an upright serif font. So you 
can't hardcode either the family or the style. And there is no way 
(AFAIK) to go from a given serif font to its companion sans-serif font, 
so when changing to a new font "collection", each one will have to be 
specified individually.
Cheers,
Mike

On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
> This was an attempt to do a direct translation from what I had in the
> "classic" rcsetup.py. (The previous version in mplconfig.py was
> semantically incorrect.) I had tested this with settings in my
> matplotlib.conf, but didn't realise that the default wasn't validated
> (and thus not interpreted into a FontPropertiesProxy object).
>
> Darren Dale wrote:
> > I am trying to work out some way to make rcdefaults() work with the
> > traited config. Along the way, I discovered this in mplconfig:
> >
> > class mathtext(TConfig):
> > cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
> > rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
> > tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
> > it = T.Trait("['serif'], style='oblique'",
> > mplT.FontPropertiesHandler())
> > bf = T.Trait("['serif'], weight='bold'",
> > mplT.FontPropertiesHandler()) sf = T.Trait("['sans-serif']",
> > mplT.FontPropertiesHandler()) use_cm = T.true
> > fallback_to_cm = T.true
> >
> > I dont think that will work. One of the highlights of the new config
> > files is that when a file says:
> >
> > [mathtext]
> > rm = ['serif', 'sans-serif']
> >
> > you actually get a list, not a string, to pass to
> > mplT.FontPropertiesHandler().
>
> Right. But it works like:
>
> rm = "['serif', 'sans-serif']"
>
> I realize it's hacky. The most obvious alternative is to expect a
> dictionary here, e.g.:
>
> rm = { 'family': ['serif'], 'style': 'oblique' }
>
> But that's less like the FontProperties constructor. 
Why do you say that? Here is the constructor:
 def __init__(self,
 family = None,
 style = None,
 variant= None,
 weight = None,
 stretch= None,
 size = None,
 fname = None,
 ):
wouldnt FontProperties(**rm) work?
> My goal was to 
> make specifying fonts as similar as possible to the FontProperties
> object so the user doesn't have to learn a new syntax. Is there a
> better way to do this with Traits? Can the user specify the arguments
> (with keyword arguments) to a constructor?
I think this is getting a little out of hand, isnt it?:
#mathtext.cal : ['cursive']
#mathtext.rm : ['serif']
#mathtext.tt : ['monospace']
#mathtext.it : ['serif'], style='oblique'
#mathtext.bf : ['serif'], weight='bold'
#mathtext.sf : ['sans-serif']
That means we have comma-separated strings for lists of fonts, but 
bracket-enclosed comma-separated quoted strings for mathtext properties.
If you want all that flexibility, why not do it in the usual way:
#mathtext.it.family : 'serif'
#mathtext.it.style : 'oblique'
But is that much flexibility needed?
Darren

I've committed a fix so this at least works. (We can change how the 
trait is specified later if necessary.) The validation is not as tight 
as it should be, yet.
I think I've passed through this bug onto another one, though:
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", 
line 469, in update
 self[key] = arg[key]
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", 
line 454, in __setitem__
 See rcParams.keys() for a list of valid parameters.'%key)
KeyError: 'text.fontangle is not a valid rc parameter.See 
rcParams.keys() for a list of valid parameters.'
It seems that unlike the regular string choice traits, the custom Trait 
handlers *are* called with the default value when initialized. Is that 
something to be relied on? (Other parts of mplconfig, such as the 
colors, depend on this).
Cheers,
Mike
Michael Droettboom wrote:
> This was an attempt to do a direct translation from what I had in the 
> "classic" rcsetup.py. (The previous version in mplconfig.py was 
> semantically incorrect.) I had tested this with settings in my 
> matplotlib.conf, but didn't realise that the default wasn't validated 
> (and thus not interpreted into a FontPropertiesProxy object).
> 
> Darren Dale wrote:
>> I am trying to work out some way to make rcdefaults() work with the traited 
>> config. Along the way, I discovered this in mplconfig:
>>
>> class mathtext(TConfig):
>> cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
>> rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
>> tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
>> it = T.Trait("['serif'], style='oblique'", 
>> mplT.FontPropertiesHandler())
>> bf = T.Trait("['serif'], weight='bold'", mplT.FontPropertiesHandler())
>> sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
>> use_cm = T.true
>> fallback_to_cm = T.true
>>
>> I dont think that will work. One of the highlights of the new config files is 
>> that when a file says:
>>
>> [mathtext]
>> rm = ['serif', 'sans-serif']
>>
>> you actually get a list, not a string, to pass to 
>> mplT.FontPropertiesHandler().
> 
> Right. But it works like:
> 
> rm = "['serif', 'sans-serif']"
> 
> I realize it's hacky. The most obvious alternative is to expect a 
> dictionary here, e.g.:
> 
> rm = { 'family': ['serif'], 'style': 'oblique' }
> 
> But that's less like the FontProperties constructor. My goal was to 
> make specifying fonts as similar as possible to the FontProperties 
> object so the user doesn't have to learn a new syntax. Is there a 
> better way to do this with Traits? Can the user specify the arguments 
> (with keyword arguments) to a constructor?
> 
> Cheers,
> Mike
> 
> -------------------------------------------------------------------------
> 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 was an attempt to do a direct translation from what I had in the 
"classic" rcsetup.py. (The previous version in mplconfig.py was 
semantically incorrect.) I had tested this with settings in my 
matplotlib.conf, but didn't realise that the default wasn't validated 
(and thus not interpreted into a FontPropertiesProxy object).
Darren Dale wrote:
> I am trying to work out some way to make rcdefaults() work with the traited 
> config. Along the way, I discovered this in mplconfig:
> 
> class mathtext(TConfig):
> cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
> rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
> tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
> it = T.Trait("['serif'], style='oblique'", 
> mplT.FontPropertiesHandler())
> bf = T.Trait("['serif'], weight='bold'", mplT.FontPropertiesHandler())
> sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
> use_cm = T.true
> fallback_to_cm = T.true
> 
> I dont think that will work. One of the highlights of the new config files is 
> that when a file says:
> 
> [mathtext]
> rm = ['serif', 'sans-serif']
> 
> you actually get a list, not a string, to pass to 
> mplT.FontPropertiesHandler().
Right. But it works like:
rm = "['serif', 'sans-serif']"
I realize it's hacky. The most obvious alternative is to expect a 
dictionary here, e.g.:
 rm = { 'family': ['serif'], 'style': 'oblique' }
But that's less like the FontProperties constructor. My goal was to 
make specifying fonts as similar as possible to the FontProperties 
object so the user doesn't have to learn a new syntax. Is there a 
better way to do this with Traits? Can the user specify the arguments 
(with keyword arguments) to a constructor?
Cheers,
Mike

I am trying to work out some way to make rcdefaults() work with the traited 
config. Along the way, I discovered this in mplconfig:
 class mathtext(TConfig):
 cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
 rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
 tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
 it = T.Trait("['serif'], style='oblique'", 
mplT.FontPropertiesHandler())
 bf = T.Trait("['serif'], weight='bold'", mplT.FontPropertiesHandler())
 sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
 use_cm = T.true
 fallback_to_cm = T.true
I dont think that will work. One of the highlights of the new config files is 
that when a file says:
[mathtext]
rm = ['serif', 'sans-serif']
you actually get a list, not a string, to pass to 
mplT.FontPropertiesHandler(). I discovered the code by trying to do this:
rcParams.update(rcParamsDefault)
Another thing about T.Trait to keep in mind:
T.Trait("['cursive']", mplT.FontPropertiesHandler())
"['cursive']" is the default value and is *not validated*. Nor is it 
necessarily an allowed value. For example:
 T.Trait('small', 'medium', 'large') 
'small' is the default value, but any future attempt to set that trait 
to 'small' will fail. Only items following the default are allowed.
 T.Trait('small', 'small', 'medium', 'large') 
Now 'small' is a valid setting.
Darren

Manuel Metz wrote:
> Hello,
> I have attached a patch that adds the ability to draw upper/lower limits 
> indicators for errorbars. New keyword args had to be introduced to the 
> errorbar command, and I also had to add new plot styles. I chose 
> 'y','Y','z' and 'Z' as new linestyles for arrowheads pointing up,down, 
> left, right (see lines.py).
> 
> An example and its output is also attached.
> 
> Eric: I know, I don't use masked array in this patch ;_) . The reason 
> was that errorbar() also doesn't use them, and a did not want to 
> completely change that function but just add the new feature. Switching 
> to masked arrays should be straight forward, I think :-)
OK, thanks. I don't think that masked array support is needed for 
errorbar plots; certainly it is not high priority.
I will look at your patch later this week; I am pretty thoroughly tied 
up right now.
Eric

Hello,
I have attached a patch that adds the ability to draw upper/lower limits 
indicators for errorbars. New keyword args had to be introduced to the 
errorbar command, and I also had to add new plot styles. I chose 
'y','Y','z' and 'Z' as new linestyles for arrowheads pointing up,down, 
left, right (see lines.py).
An example and its output is also attached.
Eric: I know, I don't use masked array in this patch ;_) . The reason 
was that errorbar() also doesn't use them, and a did not want to 
completely change that function but just add the new feature. Switching 
to masked arrays should be straight forward, I think :-)
Manuel

Manuel,
Thank you.
I will look at this ASAP, but it might not be right away. Just to be 
safe, if you haven't heard from me by Friday send me a message off the list.
Manuel Metz wrote:
> Okay, I changed from npy.asarray -> npy.ma.array and checked that it 
> works. I also added a doc. The patch as well as an example code and its 
> output are attached.
> 
> Please note that the example actually call ax.step directly instead of 
> using the pylab interface; I guess this has to be added (boilerplate.py?)
Yes, I can take care of that. No problem.
Eric
> 
> Manuel
> 
> Eric Firing wrote:
>>
>>
>> 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
> 
> ------------------------------------------------------------------------
> 
> Index: axes.py
> ===================================================================
> --- axes.py	(revision 3720)
> +++ axes.py	(working copy)
> @@ -4987,7 +4987,54 @@
> steps=[1, 2, 5, 10],
> integer=True))
> return im
> + 
> + def step(self, x, y, *args, **kwargs):
> + '''
> + STEP(x, y, *args, **kwargs)
> + 
> + Make a step plot. The args and keyword args to step are the same
> + as the args to plot. See help plot for more info.
> + 
> + Additional keyword args for step:
> + 
> + * where: can be 'pre', 'post' or 'mid'. Determines where the
> + step occurs.
> + '''
> + 
> + where = kwargs.pop('where', 'pre')
> + 
> + if not iterable(x): x = npy.ma.array([x]).astype(npy.float32)
> + else: x = npy.ma.array(x).astype(npy.float32)
> + 
> + if not iterable(y): x = npy.ma.array([y]).astype(npy.float32)
> + else: y = npy.ma.array(y).astype(npy.float32)
> + 
> + if where=='pre':
> + x2 = npy.ma.zeros((2*len(x)-1,), npy.float32)
> + y2 = npy.ma.zeros((2*len(y)-1,), npy.float32)
> + 
> + x2[0::2], x2[1::2] = x, x[:-1]
> + y2[0::2], y2[1:-1:2] = y, y[1:]
> 
> + elif where=='post':
> + x2 = npy.ma.zeros((2*len(x)-1,), npy.float32)
> + y2 = npy.ma.zeros((2*len(y)-1,), npy.float32)
> + 
> + x2[::2], x2[1:-1:2] = x, x[1:]
> + y2[0::2], y2[1::2] = y, y[:-1]
> + 
> + elif where=='mid':
> + x2 = npy.ma.zeros((2*len(x),), npy.float32)
> + y2 = npy.ma.zeros((2*len(y),), npy.float32)
> + 
> + x2[1:-1:2] = 0.5*(x[:-1]+x[1:])
> + x2[2::2] = 0.5*(x[:-1]+x[1:])
> + x2[0], x2[-1] = x[0], x[-1]
> + 
> + y2[0::2], y2[1::2] = y, y
> + 
> + return self.plot(x2, y2, *args, **kwargs)
> +
> class SubplotBase:
> """
> Emulate matlab's(TM) subplot command, creating axes with
> 
> 
> ------------------------------------------------------------------------
> 
> import matplotlib.numerix as npy
> from pylab import *
> 
> x = npy.arange(1.,10.)
> y = arange(1.,10.)
> x[4] += 0.4
> 
> fig = figure()
> ax = fig.gca()
> 
> ax.step(x,y, where='post')
> 
> y += 1.
> ax.step(x,y,where='pre')
> 
> y += 1.5
> ax.step(x,y,where='mid')
> 
> xlim(0,10)
> ylim(-1,13)
> 
> show()
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Darren Dale wrote:
> On Monday 20 August 2007 10:18:27 am Michael Droettboom wrote:
>> 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).
> 
> This seems like a bad idea. If I want to use tex as my text layout engine, now 
> I have two settings to keep track of. We'll get lots of posts asking why 
> latex is not being used when usetex is True.
I agree with this point. My counter-worry is that people may be 
surprised when their dollar signs behave differently when usetex is on 
or off. Maybe people don't change that setting all that often in 
practice, though... We could (and I'm not necessarily advocate this), 
pre-process the string sent to LaTeX when usetex is True and markup == 
'plain', so that the dollar signs are escaped (and will appear as dollar 
signs in the output).
>> 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)
> 
> This seems reasonable. Although, if we make it so latex can be used to layout 
> some text but not others, I worry that we will get no end of posts 
> complaining about how the latex fonts dont match the mathtext or normal 
> fonts.
Agreed.
>> 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?
> 
> I think b) fits best. Maybe backward compatibility can be maintained. usetex 
> would be deprecated, and would set the text_renderer rcParam to latex when 
> True.
That seems like a good approach, if we go with option b).
> Or does 0.90.1 already have the markup kwarg?
The markup kwarg is only a couple weeks old.
> Again, there must be a 
> way. The new validation mechanism in rcParams (not traits, the stuff I did 
> right before traits) could probably provide a route for transition without 
> actually breaking anything.
Good point.
> I am pretty busy this week at work, and will be 
> on vacation for 11 days starting August 24, just letting you know.
Thanks. I don't think there's a huge rush to decide this (the 
implementation should be straightforward no matter what we decide). But 
it would make sense to sort this out before the next release.
Cheers,
Mike

On Monday 20 August 2007 10:18:27 am Michael Droettboom wrote:
> 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).
This seems like a bad idea. If I want to use tex as my text layout engine, now 
I have two settings to keep track of. We'll get lots of posts asking why 
latex is not being used when usetex is True.
> 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)
This seems reasonable. Although, if we make it so latex can be used to layout 
some text but not others, I worry that we will get no end of posts 
complaining about how the latex fonts dont match the mathtext or normal 
fonts.
> 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?
I think b) fits best. Maybe backward compatibility can be maintained. usetex 
would be deprecated, and would set the text_renderer rcParam to latex when 
True. Or does 0.90.1 already have the markup kwarg? Again, there must be a 
way. The new validation mechanism in rcParams (not traits, the stuff I did 
right before traits) could probably provide a route for transition without 
actually breaking anything. I am pretty busy this week at work, and will be 
on vacation for 11 days starting August 24, just letting you know.
Darren

Hi All-
FYI, I am seeing the same problem on intel OSX 10.4.10
Andrew
Eric Firing wrote:
> Rob, Mike,
> 
> What this implies to me is that either there is a problem with the code 
> that is generating afmdict (and I did not change that code, I just 
> caused it to be invoked when the fontManager instance is created.), or 
> there is a problem with some .afm files on Rob's machine.
> 
> I really don't know how to troubleshoot it beyond this.
> 
> (As a separate issue, I probably I should change font_manager.py so that 
> if the rcParams value below was changed since the cache was made, it 
> will be rebuilt with the new value.)
> 
> Eric
> 
> Rob Hetland wrote:
>> On Aug 14, 2007, at 1:55 PM, Eric Firing wrote:
>>
>>> rcParams['pdf.use14corefonts']
>> Indeed, reversing this value fixes the problem.
>>
>> My value had been set to False.
>> 	pdf.use14corefonts : True
>> in the mplrc file works with the latest revision.
>>
>> -r
>>
>> ----
>> Rob Hetland, Associate Professor
>> Dept. of Oceanography, Texas A&M University
>> http://pong.tamu.edu/~rob
>> phone: 979-458-0096, fax: 979-845-6331
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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...@pu...
>> 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/

Okay, I changed from npy.asarray -> npy.ma.array and checked that it 
works. I also added a doc. The patch as well as an example code and its 
output are attached.
Please note that the example actually call ax.step directly instead of 
using the pylab interface; I guess this has to be added (boilerplate.py?)
Manuel
Eric Firing wrote:
> 
> 
> 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

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