matplotlib-devel Mailing List for matplotlib

Ok. I'll change this in SVN.
Nils Wagner wrote:
> On 2008年1月29日 15:33:46 -0500
> Michael Droettboom <md...@st...> wrote:
>> Ok, to save me the trouble of installing Python-2.4 (which doesn't 
>> feel like the culprit, but appears to be the only variable other than 
>> platform) I seem to recall a discussion on numpy about coercion of 
>> scalars to Python int's that may be the culprit here. Can you please 
>> add the following line above the line where the exception is raised in 
>> path.py, line 201, and then send me the output:
>>
>> print code, type(code), codes, type(codes)
>>
> 
> 1 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 2 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 1 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 2 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 
>> Also, does changing:
>>
>> num_vertices = NUM_VERTICES[code]
>>
>> to
>>
>> num_vertices = NUM_VERTICES[int(code)]
>>
>> resolve the problem?
> 
> Yes.
> 
> Cheers,
> Nils
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think it would be a shame to lose the current matplotlib 3d plotting
functionality, even if it's not ideal. I've found it very useful for
plotting small sets of data, and much more straightforward to use than
Mayavi or other vtk-based 3d plotting packages.
Having said that, I'm not volunteering to make the 3d modules work
with the new transforms :-/
Neil
>
> Message: 2
> Date: 2008年1月29日 15:07:31 -0500
> From: Michael Droettboom <md...@st...>
> Subject: Re:
> To: Johann Cohen-Tanugi <co...@sl...>, matplotlib
> development list <mat...@li...>
> Message-ID: <479...@st...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Johann Cohen-Tanugi wrote:
> > is basemap deferred as well? It is kinda 3D no?
>
> I understand basemap is working reasonably well. But Jeff Whitaker
> would know better than I.
>
> > Second a color map or
> > contour plot is kinda 2D either...... unless I am confusing what you
> > mean by 2D : 2D in rendering or in data structure?
>
> I mean 2D in rendering -- matplotlib is fundamentally built on top of 2D
> rendering APIs, which makes doing a lot of 3D things more
> computationally expensive and less flexible than a dedicated 3D plotting
> package.
>
> > Anyway, I am probably not the motivated individual to tackle this work,
> > most of all because I do not know matplotlib internals, I am just a
> > user, albeit with coding abilities.
>
> Well, anyone can jump in ;) Unfortunately, I probably don't have the
> time for that now. I believe John Hunter has some more fully-formed
> ideas about where 3D in matplotlib should go and where the best path may
> be going forward.
>
> Cheers,
> Mike
>
> > Michael Droettboom wrote:
> >> Yes, it is probably a good-sized chunk of work. In the recent
> >> transforms overhaul, the 3d stuff was deferred, so it hasn't been
> >> updated to use the new "way of doing things".
> >>
> >> Just "getting it to work as it did before" is probably less work than
> >> "rethinking what 3D means in the context of matplotlib", which is a
> >> fundamentally 2D plotting environment. And there was some thinking
> >> along the lines of "why bother with the former, if the latter may be
> >> on the horizon?..." But I think it's going to take some motivated
> >> individual to step up and do either of these.
> >>
> >> Cheers,
> >> Mike
> >>

Ok, to save me the trouble of installing Python-2.4 (which doesn't feel 
like the culprit, but appears to be the only variable other than 
platform) I seem to recall a discussion on numpy about coercion of 
scalars to Python int's that may be the culprit here. Can you please 
add the following line above the line where the exception is raised in 
path.py, line 201, and then send me the output:
 print code, type(code), codes, type(codes)
Also, does changing:
 num_vertices = NUM_VERTICES[code]
to
 num_vertices = NUM_VERTICES[int(code)]
resolve the problem?
Cheers,
Mike
Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> Interesting. I can't reproduce this with Python-2.5 on Linux. What 
>> version of numpy do you have installed? Can you send your 
>> matplotlibrc file?
>>
> 
> I tried upgrading numpy to the latest svn version but I still see the 
> same problem. My matplotlibrc file is just the default created at 
> buildtime, I have attached it.
> 
> /Jörgen
> 
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom skrev:
> Interesting. I can't reproduce this with Python-2.5 on Linux. What 
> version of numpy do you have installed? Can you send your matplotlibrc 
> file?
> 
I tried upgrading numpy to the latest svn version but I still see the 
same problem. My matplotlibrc file is just the default created at 
buildtime, I have attached it.
/Jörgen

For some reason, when axis() is called, the "emit" flag (which 
determines whether to update all of the shared axes) was being set to 
False by default. There may be a good reason for this that I'm not 
aware of, but it seems reasonably harmless, and doesn't break the 
existing shared_axis examples. I've fixed this on the branch and the 
trunk, but I'm happy to revert if anyone says "stop, bad idea!!!"
Cheers,
Mike
Jörgen Stenarson wrote:
> Hi,
> 
> I have problem setting the axis limits when using a twinx plot. I assume 
> it should be possible to set both x-axis limits after a pylab.twinx() 
> call by issuing only one call to pylab.axis.
> 
> The attached tries to plot the same figure in two different ways the 
> first way ends up with different x axis limits for the two plots. The 
> second shows my workaround.
> 
> /Jörgen
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Johann Cohen-Tanugi wrote:
> is basemap deferred as well? It is kinda 3D no?
I understand basemap is working reasonably well. But Jeff Whitaker 
would know better than I.
> Second a color map or 
> contour plot is kinda 2D either...... unless I am confusing what you 
> mean by 2D : 2D in rendering or in data structure?
I mean 2D in rendering -- matplotlib is fundamentally built on top of 2D 
rendering APIs, which makes doing a lot of 3D things more 
computationally expensive and less flexible than a dedicated 3D plotting 
package.
> Anyway, I am probably not the motivated individual to tackle this work, 
> most of all because I do not know matplotlib internals, I am just a 
> user, albeit with coding abilities.
Well, anyone can jump in ;) Unfortunately, I probably don't have the 
time for that now. I believe John Hunter has some more fully-formed 
ideas about where 3D in matplotlib should go and where the best path may 
be going forward.
Cheers,
Mike
> Michael Droettboom wrote:
>> Yes, it is probably a good-sized chunk of work. In the recent 
>> transforms overhaul, the 3d stuff was deferred, so it hasn't been 
>> updated to use the new "way of doing things".
>>
>> Just "getting it to work as it did before" is probably less work than 
>> "rethinking what 3D means in the context of matplotlib", which is a 
>> fundamentally 2D plotting environment. And there was some thinking 
>> along the lines of "why bother with the former, if the latter may be 
>> on the horizon?..." But I think it's going to take some motivated 
>> individual to step up and do either of these.
>>
>> Cheers,
>> Mike
>>
>> Johann Cohen-Tanugi wrote:
>>> is there a lot of work involved in getting it in? I can wait a bit, 
>>> or even try to help out.... It is not critical as I know plenty other 
>>> way to get the plot I want.... Just that I love matplotlib and scipy
>>>
>>> best,
>>> Johann
>>>
>>> Michael Droettboom wrote:
>>>> The axes3d stuff is not currently working on the SVN trunk. You 
>>>> probably want to use 0.91.2 or the v0_91_maint branch in SVN instead.
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Johann Cohen-Tanugi wrote:
>>>>> hello,
>>>>> thanks for answering. I actually fail with the import :
>>>>> In [1]: from matplotlib import axes3d
>>>>> --------------------------------------------------------------------------- 
>>>>>
>>>>> ImportError Traceback (most recent 
>>>>> call last)
>>>>>
>>>>> /home/cohen/bstw/<ipython console> in <module>()
>>>>>
>>>>> /usr/lib/python2.5/site-packages/matplotlib/axes3d.py in <module>()
>>>>> 14 from axes import Axes
>>>>> 15 import cbook
>>>>> ---> 16 from transforms import unit_bbox
>>>>> 17
>>>>> 18 import numpy as npy
>>>>>
>>>>> ImportError: cannot import name unit_bbox
>>>>>
>>>>> any idea?
>>>>>
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> Message: 1
>>>>>> Date: 2008年1月27日 22:18:00 +0000
>>>>>> From: "Neil Crighton" <nei...@gm...>
>>>>>> Subject: Re: [Matplotlib-users] plotting a series of 3D points and
>>>>>> picker=True and 3D
>>>>>> To: mat...@li...
>>>>>> Message-ID:
>>>>>> <637...@ma...>
>>>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>>>
>>>>>> I think scatter3D does what you want:
>>>>>>
>>>>>> from matplotlib import axes3d
>>>>>> import pylab as pl
>>>>>> fig = pl.figure()
>>>>>> ax = axes3d.Axes3D(fig)
>>>>>> ax.scatter3D(data[:,0],data[:,1],data[:,2])
>>>>>> ax.set_xlabel('X value')
>>>>>> ax.set_ylabel('Y value')
>>>>>> ax.set_zlabel('Z value')
>>>>>> pl.show()
>>>>>>
>>>>>> You could also change the colour and size of each point based on 
>>>>>> other
>>>>>> array values:
>>>>>>
>>>>>> col = ax.scatter3D(data[:,0], data[:,1], data[:,2], c=data[:,3],
>>>>>> cmap=pl.cm.jet, s=data[:,4])
>>>>>> cbar = fig.colorbar(col,shrink=0.9,extend='both')
>>>>>> cbar.ax.set_ylabel('axis 3 data values')
>>>>>>
>>>>>> Pretty nifty.
>>>>>>
>>>>>> Neil
>>>>>>
>>>>>> 
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Interesting. I can't reproduce this with Python-2.5 on Linux. What 
version of numpy do you have installed? Can you send your matplotlibrc 
file?
Cheers,
Mike
Jörgen Stenarson wrote:
> Hi,
> 
> I think there is a bug in the pdf backend (png-files save ok) that makes 
> plots crash when they contain a marker.
> 
> The attached script crashes on the last savefig. I have also attached a 
> traceback.
> 
> I run matplotlib-svn-4904 on windows with python 2.4
> 
> /Jörgen
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Yes, it is probably a good-sized chunk of work. In the recent 
transforms overhaul, the 3d stuff was deferred, so it hasn't been 
updated to use the new "way of doing things".
Just "getting it to work as it did before" is probably less work than 
"rethinking what 3D means in the context of matplotlib", which is a 
fundamentally 2D plotting environment. And there was some thinking 
along the lines of "why bother with the former, if the latter may be on 
the horizon?..." But I think it's going to take some motivated 
individual to step up and do either of these.
Cheers,
Mike
Johann Cohen-Tanugi wrote:
> is there a lot of work involved in getting it in? I can wait a bit, or 
> even try to help out.... It is not critical as I know plenty other way 
> to get the plot I want.... Just that I love matplotlib and scipy
> 
> best,
> Johann
> 
> Michael Droettboom wrote:
>> The axes3d stuff is not currently working on the SVN trunk. You 
>> probably want to use 0.91.2 or the v0_91_maint branch in SVN instead.
>>
>> Cheers,
>> Mike
>>
>> Johann Cohen-Tanugi wrote:
>>> hello,
>>> thanks for answering. I actually fail with the import :
>>> In [1]: from matplotlib import axes3d
>>> --------------------------------------------------------------------------- 
>>>
>>> ImportError Traceback (most recent call 
>>> last)
>>>
>>> /home/cohen/bstw/<ipython console> in <module>()
>>>
>>> /usr/lib/python2.5/site-packages/matplotlib/axes3d.py in <module>()
>>> 14 from axes import Axes
>>> 15 import cbook
>>> ---> 16 from transforms import unit_bbox
>>> 17
>>> 18 import numpy as npy
>>>
>>> ImportError: cannot import name unit_bbox
>>>
>>> any idea?
>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: 2008年1月27日 22:18:00 +0000
>>>> From: "Neil Crighton" <nei...@gm...>
>>>> Subject: Re: [Matplotlib-users] plotting a series of 3D points and
>>>> picker=True and 3D
>>>> To: mat...@li...
>>>> Message-ID:
>>>> <637...@ma...>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>>
>>>> I think scatter3D does what you want:
>>>>
>>>> from matplotlib import axes3d
>>>> import pylab as pl
>>>> fig = pl.figure()
>>>> ax = axes3d.Axes3D(fig)
>>>> ax.scatter3D(data[:,0],data[:,1],data[:,2])
>>>> ax.set_xlabel('X value')
>>>> ax.set_ylabel('Y value')
>>>> ax.set_zlabel('Z value')
>>>> pl.show()
>>>>
>>>> You could also change the colour and size of each point based on other
>>>> array values:
>>>>
>>>> col = ax.scatter3D(data[:,0], data[:,1], data[:,2], c=data[:,3],
>>>> cmap=pl.cm.jet, s=data[:,4])
>>>> cbar = fig.colorbar(col,shrink=0.9,extend='both')
>>>> cbar.ax.set_ylabel('axis 3 data values')
>>>>
>>>> Pretty nifty.
>>>>
>>>> Neil
>>>>
>>>> 
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I have problem setting the axis limits when using a twinx plot. I assume 
it should be possible to set both x-axis limits after a pylab.twinx() 
call by issuing only one call to pylab.axis.
The attached tries to plot the same figure in two different ways the 
first way ends up with different x axis limits for the two plots. The 
second shows my workaround.
/Jörgen

Hi,
I think there is a bug in the pdf backend (png-files save ok) that makes 
plots crash when they contain a marker.
The attached script crashes on the last savefig. I have also attached a 
traceback.
I run matplotlib-svn-4904 on windows with python 2.4
/Jörgen