matplotlib-users Mailing List for matplotlib

Mark Bakker wrote:
> Hello -
> 
> This used to work:
> fill( [0,1,1], [0,0,1], '#FFFF66')
> 
> But it doesn't work anymore under 0.90.1.
> I thought it still worked under 0.90.0

I don't think this behavior is documented, and a very quick look at 
recent changes to axes.py did not reveal a corresponding change, but it 
looks like it would be easy add and it seems to me like a useful and 
logical extension.  The idea is that if a string is a valid mpl 
colorspec (including, but not limited to, hex strings as in the example 
above), then it sets the color; otherwise the present code is used to 
interpret strings like '-k' etc.

If no one is working on this, and if there is no objection, I can 
implement it later today or tomorrow.  Does anyone see any ambiguity or 
other problem with this?

Eric

> 
> Anybody see the same problem?
> Plot seems to have the same problem:
> plot([1,2,3],'#afeeee')
> 
> Error message for the plot statement:
> Traceback (most recent call last):
>   File "<pyshell#11>", line 1, in ?
>     plot([1,2,3],'#afeeee')
>   File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 2028, 
> in plot
>     ret =  gca().plot(*args, **kwargs)
>   File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 2535, in 
> plot
>     for line in self._get_lines(*args, **kwargs):
>   File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 421, in 
> _grab_next_args
>     for seg in self._plot_2_args(remaining, **kwargs):
>   File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 313, in 
> _plot_2_args
>     linestyle, marker, color = _process_plot_format(fmt)
>   File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 153, in 
> _process_plot_format
>     raise ValueError, err
> ValueError: Unrecognized character # in format string
> 
> Thanks, Mark
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Marek,

See the unicode_demo.py and the tex_unicode_demo.py in the examples
directory.

Marek Wojciechowski wrote:
> Hi.
> How can I get polish letters in, for example, plot title? Now I have empty
> squares instead...
> 
> Thanks in advance for any help.

Hi.
How can I get polish letters in, for example, plot title? Now I have empty
squares instead...

Thanks in advance for any help.
-- 
Marek Wojciechowski

I just added support for native plotting of python date and datetime
objects (you still can, but don't have to use plot_date with date2num
conversions).  We will continue to do conversion to floats under the
hood, but the conversion can be handled automagically.  I also added
support for loading CSV files (or general space/tab/comma delimited
files) into numpy record arrays, and the type conversions (int, float,
date, etc...) happen automagically.  The function assumes there is a
header row, and these strings will be munged to give valid python
attribute names.  It inspects the first checkrows lines after the
header to try and infer the datatype and set the appropriate
conversion function.   It's not entirely bullet proof, but it should
cover a lot of common use cases.

Here is an example (svn only)

  from matplotlib.mlab import csv2rec
  from pylab import figure, show

  a = csv2rec('data/msft.csv')
  fig = figure()
  ax = fig.add_subplot(111)
  ax.plot(a.date, a.adj_close, '-')
  fig.autofmt_xdate()
  show()

The autofmt_xdate is optional, but is a new function that does a few
things you usually want in date plots: turns off tick labels in the
upper subplots if any, rotates the tick labels on the lowest axes and
right aligns them, and increases the bottom of the subplots adjust to
make room for the rotated tick labels.

Here is what the dtype looks like from the example above.

  In [3]: !head -3 data/msft.csv
  Date,Open,High,Low,Close,Volume,Adj. Close*
  19-Sep-03,29.76,29.97,29.52,29.96,92433800,29.79
  18-Sep-03,28.49,29.51,28.42,29.50,67268096,29.34

  In [4]: a = csv2rec('data/msft.csv')

  In [5]: a.dtype
  Out[5]: dtype([('date', '|O4'), ('open', '<f8'), ('high', '<f8'),
('low', '<f8'), ('close', '<f8'),   ('volume', '<i4'), ('adj_close',
'<f8')])

  In [6]: a.date[:2]
  Out[6]: array([2003-09-19 00:00:00, 2003-09-18 00:00:00], dtype=object)

I'll probably add a few performance features to the csv2rec function,
mainly to let you skip columns and supply conversion functions where
desired because the autodate parser is pretty slow if you want to
parse date strings, but this is enough to make it useful.  Another
useful feature will be able to support customizable type dependent
NULL value conversion (eg convert to numpy.nan for floats,
'0000-00-00' for dates, etc...)

Record arrays are your friend; have fun!
JDH

Werner F. Bruhin wrote:
> Hi Andrew,
>
> Werner F. Bruhin wrote:
>   
>> Hi Andrew,
>>
>> Andrew Straw wrote:
>>   
>>     
>>> Dear Werner,
>>>
>>> This seems to be an unintended side-effect of reorganizing the mpl 
>>> data file location that I did prior to this release. (I.e. it's not 
>>> your code that broke, I think it's mpl.) Unfortunately, since I didn't 
>>> (and still don't) use py2exe, it will be hard for me to fix this. Can 
>>> you send a patch that gets py2exe working again?
>>>     
>>>       
>> The work around I did is using glob.glob instead as follows:
>>
>> # matplotlib data
>> ##mpdir, mpfiles = matplotlib.get_py2exe_datafiles()
>> mpfiles = glob.glob('C:\Python25\lib\site-packages\matplotlib\mpl-data\*.*')
>>
>> But I can't confirm yet that this works as I am also trying out 
>> something else in my InnoSetup script.  Will confirm ASAP and will try 
>> and look into matplotlib.get_py2exe_datafiles() and see how it could be 
>> fixed.
>>   
>>     
> I have change matplotlib.get_py2exe_datafiles() to:
> def get_py2exe_datafiles():
>     import glob
>    
>     mplfiles = []
>     for item in glob.glob(os.sep.join([get_data_path(), '*/*'])):
>         if os.path.isdir(item):
>             mplfiles += glob.glob(os.sep.join([item, '/*']))
>            
>     mplfiles.append(os.sep.join([get_data_path(), 'matplotlibrc']))
>
>     try:
>         mplfiles.remove(os.sep.join([get_data_path(), 'Matplotlib.nib']))
>     except:
>         pass
>
>     return ('matplotlibdata', mplfiles)
>
> Now this creates a "flat" folder, i.e. all datafiles are directly under 
> matplotlibdata.  In my tests this works for me in my limited tests, with 
> the exception that I also get the "Could not match Bitstream Vera 
> ......etc" error - but this is something I also get with py2exe, so I 
> don't know if this is an issue.
>
> Andrew, do you know if the sub-folder structure should be retained when 
> using py2exe for matplotlib to work correctly in all circumstances?  If 
> that would be the case let me know and I try to come up with something.
Dear Werner,

I am reluctant to eliminate the sub-folder structure because I think it 
would add the possibility of unnecessary bugs to just the py2exe built 
version. Would it be possible for you to re-factor this to include the 
directory layout? When you test it, can you test some interactive plot 
to make sure all the button icons are loaded properly?

Thanks,
Andrew

Hi Matplotlib users.

I've been fiddling with colorbars a bit today and having a bit of difficulty
with the borders.

Take, for example, subplots_adjust.py: it makes nice colorbar up the side of
the image. But there is a black border, plus numbers, around the colorbar.
Is there an easy way of getting rid of the border, just leaving the blue to
red scaled colorbar?

Matthew

Eric Firing a écrit :
> You may need to post a small code example so we can see what you are 
> doing; but an interactive example using ipython -pylab may give you 
> enough information to answer your question:
Hi ,

Not really ;-), but no problem.

I got a fix.
The trick is to pass axes colorbar as argument to colorbar function:

    def update_colorbar(self):
        if (self.cb is None):
            self.cb = self.display.figure.colorbar(self.img,
                                                   ticks=self.cbticks,
                                                   format='%g')
        else:
            self.display.figure.colorbar(self.img,
                                         self.cb.ax,
                                         ticks=self.cbticks,
                                         format='%g')

that works perfectly.


Cheers,

-- 
http://scipy.org/FredericPetit

Hi Andrew,

Werner F. Bruhin wrote:
> Hi Andrew,
>
> Andrew Straw wrote:
>   
>> Dear Werner,
>>
>> This seems to be an unintended side-effect of reorganizing the mpl 
>> data file location that I did prior to this release. (I.e. it's not 
>> your code that broke, I think it's mpl.) Unfortunately, since I didn't 
>> (and still don't) use py2exe, it will be hard for me to fix this. Can 
>> you send a patch that gets py2exe working again?
>>     
> The work around I did is using glob.glob instead as follows:
>
> # matplotlib data
> ##mpdir, mpfiles = matplotlib.get_py2exe_datafiles()
> mpfiles = glob.glob('C:\Python25\lib\site-packages\matplotlib\mpl-data\*.*')
>
> But I can't confirm yet that this works as I am also trying out 
> something else in my InnoSetup script.  Will confirm ASAP and will try 
> and look into matplotlib.get_py2exe_datafiles() and see how it could be 
> fixed.
>   
I have change matplotlib.get_py2exe_datafiles() to:
def get_py2exe_datafiles():
    import glob
   
    mplfiles = []
    for item in glob.glob(os.sep.join([get_data_path(), '*/*'])):
        if os.path.isdir(item):
            mplfiles += glob.glob(os.sep.join([item, '/*']))
           
    mplfiles.append(os.sep.join([get_data_path(), 'matplotlibrc']))

    try:
        mplfiles.remove(os.sep.join([get_data_path(), 'Matplotlib.nib']))
    except:
        pass

    return ('matplotlibdata', mplfiles)

Now this creates a "flat" folder, i.e. all datafiles are directly under 
matplotlibdata.  In my tests this works for me in my limited tests, with 
the exception that I also get the "Could not match Bitstream Vera 
......etc" error - but this is something I also get with py2exe, so I 
don't know if this is an issue.

Andrew, do you know if the sub-folder structure should be retained when 
using py2exe for matplotlib to work correctly in all circumstances?  If 
that would be the case let me know and I try to come up with something.

Werner

Just checked in an even cleaner solution:

in _auto_legend_data, the internal routine get_handles() was overly compl=
ex:
first, it would merge lines, patches and linecollections into one list,
only to then
handle each kind separately. I simplified the code to avoid that issue,
so get_handle only
appears internally in Axes.legend()



Jouni K. Sepp=E4nen wrote:
> Norbert Nemec <Nor...@gm...> writes:
>
>  =20
>> Thanks for the hint. I just fixed the problem in SVN.
>>    =20
>
> I thought I had fixed this in March... see
> http://thread.gmane.org/gmane.comp.python.matplotlib.devel/2574
>
> But that was the get_handles() in legend.py, while this one is in
> axes.py. Probably the code was originally copied from one place to the
> other, but the functions have diverged since: one copy has had this
> bug fixed, the other has been extended to handle RegularPolyCollections=
=2E=20
> Perhaps get_handles() should be promoted from internal function to a=20
> method of Axes?
>
> Also, if someone were interested in creating a unit test suite for
> matplotlib, a good way to start could be to identify the intended
> types of member variables (e.g. "list of Line2D objects"), run various
> example scripts and check that the variables have the correct kind of
> data.
>
>  =20

Hello -

This used to work:
fill( [0,1,1], [0,0,1], '#FFFF66')

But it doesn't work anymore under 0.90.1.
I thought it still worked under 0.90.0

Anybody see the same problem?
Plot seems to have the same problem:
plot([1,2,3],'#afeeee')

Error message for the plot statement:
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in ?
    plot([1,2,3],'#afeeee')
  File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 2028, in
plot
    ret =  gca().plot(*args, **kwargs)
  File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 2535, in
plot
    for line in self._get_lines(*args, **kwargs):
  File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 421, in
_grab_next_args
    for seg in self._plot_2_args(remaining, **kwargs):
  File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 313, in
_plot_2_args
    linestyle, marker, color = _process_plot_format(fmt)
  File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 153, in
_process_plot_format
    raise ValueError, err
ValueError: Unrecognized character # in format string

Thanks, Mark

Norbert Nemec <Nor...@gm...> writes:

> Thanks for the hint. I just fixed the problem in SVN.

I thought I had fixed this in March... see
http://thread.gmane.org/gmane.comp.python.matplotlib.devel/2574

But that was the get_handles() in legend.py, while this one is in
axes.py. Probably the code was originally copied from one place to the
other, but the functions have diverged since: one copy has had this
bug fixed, the other has been extended to handle RegularPolyCollections. 
Perhaps get_handles() should be promoted from internal function to a 
method of Axes?

Also, if someone were interested in creating a unit test suite for
matplotlib, a good way to start could be to identify the intended
types of member variables (e.g. "list of Line2D objects"), run various
example scripts and check that the variables have the correct kind of
data.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks for the hint. I just fixed the problem in SVN.

No idea how this problem would have popped up recently. I did some
changes in legend just before 0.90.1, but I do not see how these would
have caused the problem to show up. From what I see, the flaw should
have been there all along. Well, whatever ... it is fixed now.


Jessica Lu wrote:
> Hi,
>
> I just downloaded and installed the latest matplotlib (0.90.1) and the
> following problem occurred:
>
>
> >>>
> plot([0,1])
> scatter([0.5], [0.5])
>
> # Should be one Line2D
> print gca().lines
> # Should be one RegularPolyCollection
> print gca().collections
>
> # Now load a legend:
> legend()
>
> # Should be one Line2D  !!! BUT NOW THERE IS A RegularPolyCollection !!!
> print gca().lines
> # Should be one RegularPolyCollection
> print gca().collections
>
> # Clearing throws the exception cuz it is trying to call
> # line methods (get_xdata) on a poly-collection
> clf()
> >>>
>
> To fix this problem, I edited my axes.py file. In the legend()
> function, there is a get_handles() function which does the following
> (in psuedo code):
>
> handles = self.lines
> handles.extend(self.patches)
> handles.extend( --- collections ---)
>
> This is actually modifying the self.lines object. If instead I import
> the copy module and do:
>
> handles = copy.copy(self.lines)
>
> then everything behaves better. I haven't done extensive testing to
> see if this breaks anything else though. Is there some place to enter
> bugs or is posting to this mailing list good enough?
>
> Cheers,
> Jessica
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

I'm trying to replicate a plot like this:

http://tinyurl.com/2uwjn8

In this case, the y-axis on the left (the black dots) is linear
(thought the values are logged) and the y-axis on the right (red data)
is log base 2.

I'm running into some problems.

1. How do I display the right-hand y-axis so that is includes the
range above 32 and below 0? When I try to include 0 or below in the
axis range, I get an error. When I do auto, it ranged from 2 to 32.

2. How do I line up the centers of both axes. in this case, the y-axis
on the left needs to have the 0 value lined up with the value of 2 on
the y axis on the right.

3. I can't get matplotlib to make such small dots (like the black dots
in this figure). Is that possible?

Thanks for the advice.

Hi,

I just downloaded and installed the latest matplotlib (0.90.1) and  
the following problem occurred:


 >>>
plot([0,1])
scatter([0.5], [0.5])

# Should be one Line2D
print gca().lines
# Should be one RegularPolyCollection
print gca().collections

# Now load a legend:
legend()

# Should be one Line2D  !!! BUT NOW THERE IS A RegularPolyCollection !!!
print gca().lines
# Should be one RegularPolyCollection
print gca().collections

# Clearing throws the exception cuz it is trying to call
# line methods (get_xdata) on a poly-collection
clf()
 >>>

To fix this problem, I edited my axes.py file. In the legend()  
function, there is a get_handles() function which does the following  
(in psuedo code):

handles = self.lines
handles.extend(self.patches)
handles.extend( --- collections ---)

This is actually modifying the self.lines object. If instead I import  
the copy module and do:

handles = copy.copy(self.lines)

then everything behaves better. I haven't done extensive testing to  
see if this breaks anything else though. Is there some place to enter  
bugs or is posting to this mailing list good enough?

Cheers,
Jessica