matplotlib-devel Mailing List for matplotlib

Sandro Tosi wrote:

>>>>>> What do you think about adding those 2 line into wx examples?
>> hmmm - only the examples? or should it be in the wx back-end itself?
>> Maybe at least a version check?
> 
> I'll leave this to the mpl gurus...

fair enough.


> yeah, that's what we need: I got 2 version installed (2.6 and 2.8) and
> here is the output

> In [2]: import wxversion
> 
> In [3]: wxversion.ensureMinimal('2.8')
> 
> In [4]: import wx
> 
> In [5]: wx.__version__
> Out[5]: '2.8.7.1'
> 
> So I'm going to use it in the examples. Thanks for spotting it out!

great -- thanks for working on those -- good examples are key!

> I only hope that 2.8->2.10 (or higher) would not introduce such corner
> cases like in 2.6->2.8.

Less likely, with 2.8, we eliminated the compiled parts of the wx 
back-end, by using some new features.

However, if future versions of wxPython get the new enhanced buffer 
interface, it might be nice to use it.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Mon, Mar 9, 2009 at 21:55, Christopher Barker <Chr...@no...> wrote:
> Sandro Tosi wrote:
>>>>>>>> import wxversion
>>>>>>>> wxversion.select('2.8')
>>>>>>>> from wx import *
>>>>>>>> wx.__version__
>>>>> '2.8.7.1'
>>>>>
>>>>> That solves the problem of multi-wx on a system.
>>>>>
>>>>> What do you think about adding those 2 line into wx examples?
>
> hmmm - only the examples? or should it be in the wx back-end itself?
> Maybe at least a version check?

I'll leave this to the mpl gurus...

> Anyway -- certainly the examples

...while I'll concentrate on them :)

>>>> Moreover, I will provide a patch to move from
>>>>
>>>>>>> from wx import *
>>>> to
>>>>>>> import wx
>
> who hoo! thanks!
>
>> AFAIUI, it's not possible to say "2.8+" == "2.8 and all the higher
>> versions",
>
> I think there is:
>
> http://www.wxpython.org/docs/api/wxversion-module.html
>
> you need:
>
> import wxversion
> wxversion.ensureMinimal('2.8')
>
> I think that will do it, but I haven't tested much -- I only have one
> version installed now. If it does work, I say we definitely ue it in the.
>
> Another option is to put it in the wx back-end in a try block:
>
> wxversion.ensureMinimal('2.4')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/usr/local/lib/wxPython-unicode-2.8.9.1/lib/python2.5/site-packages/wxversion.py",
> line 181, in ensureMinimal
>     raise AlreadyImportedError("wxversion.ensureMinimal() must be
> called before wxPython is imported")
> wxversion.AlreadyImportedError: wxversion.ensureMinimal() must be called
> before wxPython is imported
>
> which might be the safest, and would catch both pylab use, and people's
> home-written apps that need the wxversion call.

yeah, that's what we need: I got 2 version installed (2.6 and 2.8) and
here is the output

In [1]: import wxversion

In [2]: help(wxversion.ensureMinimal)

In [3]: wxversion.ensureMinimal('2.6')

In [4]: import wx

In [5]: wx.__version__
Out[5]: '2.6.3.2'

and

In [2]: import wxversion

In [3]: wxversion.ensureMinimal('2.8')

In [4]: import wx

In [5]: wx.__version__
Out[5]: '2.8.7.1'

So I'm going to use it in the examples. Thanks for spotting it out!

I only hope that 2.8->2.10 (or higher) would not introduce such corner
cases like in 2.6->2.8.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Mon, Mar 9, 2009 at 2:39 PM, Jonathan Taylor
<jon...@ut...> wrote:
> Sure, I thought it was going to the list too ;)  So no problem.
>
> I am not sure what you can do with that module.  It seems a shame to
> waste.  Perhaps it should be split out into a seperate 3d only
> plotting library that cares less about being matplotlib'ish than
> something packaged with MPL would.  What do you think?

Yes, we could do that. The problem is that I don't have time to
maintain plotting stuff, so I need to find ways to attract someone
else to take over it. :) So maybe creating some optional addon to
matplotlib, as you say, could attract people's attantion.

Ondrej

Sure, I thought it was going to the list too ;)  So no problem.

I am not sure what you can do with that module.  It seems a shame to
waste.  Perhaps it should be split out into a seperate 3d only
plotting library that cares less about being matplotlib'ish than
something packaged with MPL would.  What do you think?

Jon.

On Mon, Mar 9, 2009 at 5:36 PM, Ondrej Certik <on...@ce...> wrote:
> On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik <on...@ce...> wrote:
>> I posted only to you by a mistake -- can I reply to the list?
>
> Oops, I posted to the list by mistake too -- sorry about it. Anyway,
> here is the email that I sent to Jonathan only by a mistake:
>
> On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor
> <jon...@ut...> wrote:
>> Just because we are using all the 2D drawing code to make the plots,
>> which is why the 3d code is so small, maintainable and is visually
>> consistent with 2D matplotlib.  I believe that moving to OpenGL would
>> require a substantial effort.
>
> Ok, now I understand the motivation. So if one wanted to go the OpenGL
> route, it would have to be created as a matplotlib backend? Then the
> 3D plots would be fast enough.
>
> Ondrej
>
>
>
> and he replied in my previous email, that I just wanted to ask if I
> can post to the list.
>
> Ondrej
>

On Mon, Mar 9, 2009 at 2:34 PM, Ondrej Certik <on...@ce...> wrote:
> I posted only to you by a mistake -- can I reply to the list?

Oops, I posted to the list by mistake too -- sorry about it. Anyway,
here is the email that I sent to Jonathan only by a mistake:

On Sun, Mar 8, 2009 at 9:44 PM, Jonathan Taylor
<jon...@ut...> wrote:
> Just because we are using all the 2D drawing code to make the plots,
> which is why the 3d code is so small, maintainable and is visually
> consistent with 2D matplotlib.  I believe that moving to OpenGL would
> require a substantial effort.

Ok, now I understand the motivation. So if one wanted to go the OpenGL
route, it would have to be created as a matplotlib backend? Then the
3D plots would be fast enough.

Ondrej



and he replied in my previous email, that I just wanted to ask if I
can post to the list.

Ondrej

I posted only to you by a mistake -- can I reply to the list?

On Mon, Mar 9, 2009 at 2:20 PM, Jonathan Taylor
<jon...@ut...> wrote:
> I think that it would be a little bit more complicated than that.  I
> believe that the current backends act as a canvas that you paint onto.
>  I do not think an OpenGL "canvas" would give us a big speed
> improvement.  In order to get the speed improvement, the "canvas"
> would have to be 3D and the M3D code would paint into this 3D space
> and let OpenGL (and your video card) worry about rendering it.  I
> think that it would be hard to make what came out of this process look
> like what we have now.  Perhaps it would be possible using
> orthographic projection.
>
> Again, for simplicity, I am interested to see how much mileage we can
> get out of our current implementation, perhaps by rewriting a few of
> the algebraic routines in cython.

Ok, I think I understand now and your approach seems reasonable to me.
I can use mayavi if I need some fast and fancy stuff and one can use
mpl if one just wants some regular 3d stuff.

So what do you think we should do with our 3d plots in sympy? It's too
simple for mayavi, too complex for mpl,... Well. :)

Ondrje

Sandro Tosi wrote:
>>>>>>> import wxversion
>>>>>>> wxversion.select('2.8')
>>>>>>> from wx import *
>>>>>>> wx.__version__
>>>> '2.8.7.1'
>>>>
>>>> That solves the problem of multi-wx on a system.
>>>>
>>>> What do you think about adding those 2 line into wx examples?

hmmm - only the examples? or should it be in the wx back-end itself? 
Maybe at least a version check?

Anyway -- certainly the examples

>>> Moreover, I will provide a patch to move from
>>>
>>>>>> from wx import *
>>> to
>>>>>> import wx

who hoo! thanks!

> AFAIUI, it's not possible to say "2.8+" == "2.8 and all the higher
> versions",

I think there is:

http://www.wxpython.org/docs/api/wxversion-module.html

you need:

import wxversion
wxversion.ensureMinimal('2.8')

I think that will do it, but I haven't tested much -- I only have one 
version installed now. If it does work, I say we definitely ue it in the.

Another option is to put it in the wx back-end in a try block:

wxversion.ensureMinimal('2.4')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"/usr/local/lib/wxPython-unicode-2.8.9.1/lib/python2.5/site-packages/wxversion.py", 
line 181, in ensureMinimal
     raise AlreadyImportedError("wxversion.ensureMinimal() must be 
called before wxPython is imported")
wxversion.AlreadyImportedError: wxversion.ensureMinimal() must be called 
before wxPython is imported

which might be the safest, and would catch both pylab use, and people's 
home-written apps that need the wxversion call.

thanks for working on this,

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Just because we are using all the 2D drawing code to make the plots,
which is why the 3d code is so small, maintainable and is visually
consistent with 2D matplotlib.  I believe that moving to OpenGL would
require a substantial effort.

J

On Mon, Mar 9, 2009 at 12:17 AM, Ondrej Certik <on...@ce...> wrote:
> On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor
> <jon...@ut...> wrote:
>> Hi,
>>
>> Thanks for the patch.  How slow is it for you?  I find it slow but
>
> Well, when I use mouse to rotate the image, I can see that it lags behind.
>
>> quite usable.  The main problem, I imagine, is that sympy is using
>> OpenGL and thus your graphics card performs all the 3d -> 2d rendering
>> whereas we do much of this in python/numpy.  When I get a chance I am
>> going to see if I can somewhat speed some of it up by adding an
>> optional module to perform a few of these operations in C.
>
> Why not to use OpenGL as well?
>
> Ondrej
>

On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor
<jon...@ut...> wrote:
> Hi,
>
> Thanks for the patch.  How slow is it for you?  I find it slow but

Well, when I use mouse to rotate the image, I can see that it lags behind.

> quite usable.  The main problem, I imagine, is that sympy is using
> OpenGL and thus your graphics card performs all the 3d -> 2d rendering
> whereas we do much of this in python/numpy.  When I get a chance I am
> going to see if I can somewhat speed some of it up by adding an
> optional module to perform a few of these operations in C.

Why not to use OpenGL as well?

Ondrej

Hi,

Thanks for the patch.  How slow is it for you?  I find it slow but
quite usable.  The main problem, I imagine, is that sympy is using
OpenGL and thus your graphics card performs all the 3d -> 2d rendering
whereas we do much of this in python/numpy.  When I get a chance I am
going to see if I can somewhat speed some of it up by adding an
optional module to perform a few of these operations in C.

Jon.

On Sun, Mar 8, 2009 at 11:37 PM, Ondrej Certik <on...@ce...> wrote:
> On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor
> <jon...@ut...> wrote:
>> Hi Reinier,
>>
>> Awesome.  Those plots are making me smile! I also agree with your
>> refactoring and have applied your patch to my git repository.
>>
>> I agree with you concerning the sympy plotting routines.  I think what
>> we have here is quite flexible and does a very good job of replicating
>> the equivalent functionality of MATLAB.  I think it would be a huge
>> effort trying to make 2D plots and 3D plots look consistent if another
>> approach was taken.  Indeed, this is a desirable characteristic.  In
>> addition, the code is actually very short and easy to maintain.  Given
>> that matplotlib has had trouble maintaining 3D code in the past, it
>> might not be a good idea to switch to a more complicated codebase.
>>
>> You should grab some of my more recent changes as I have added a few
>> more fixes.  Most importantly, if you reuse the same figure, the old
>> event handlers will still attached preventing Axes objects from dieing
>> and causing interactive manipulation of the plots to be very sluggish.
>>  Also, in terms of performance, I have found that switching to TkAgg
>> from GTKAgg was helpful.
>>
>> Also, I think the original code from John Porter was under a BSD
>> license.  I am thinking of adding our names and the BSD license to the
>> top of each file to protect it while its not officially part of
>> matplotlib.  What do you think?
>
> A trivial patch is attached to make proj3d.py work.
>
> I tried the examples and it looks great. However, it's pretty slow, at
> least on my machine. The plotting in sympy is much faster. Is there
> some way to make the mplot3d faster?
>
> Ondrej
>

On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor
<jon...@ut...> wrote:
> Hi Reinier,
>
> Awesome.  Those plots are making me smile! I also agree with your
> refactoring and have applied your patch to my git repository.
>
> I agree with you concerning the sympy plotting routines.  I think what
> we have here is quite flexible and does a very good job of replicating
> the equivalent functionality of MATLAB.  I think it would be a huge
> effort trying to make 2D plots and 3D plots look consistent if another
> approach was taken.  Indeed, this is a desirable characteristic.  In
> addition, the code is actually very short and easy to maintain.  Given
> that matplotlib has had trouble maintaining 3D code in the past, it
> might not be a good idea to switch to a more complicated codebase.
>
> You should grab some of my more recent changes as I have added a few
> more fixes.  Most importantly, if you reuse the same figure, the old
> event handlers will still attached preventing Axes objects from dieing
> and causing interactive manipulation of the plots to be very sluggish.
>  Also, in terms of performance, I have found that switching to TkAgg
> from GTKAgg was helpful.
>
> Also, I think the original code from John Porter was under a BSD
> license.  I am thinking of adding our names and the BSD license to the
> top of each file to protect it while its not officially part of
> matplotlib.  What do you think?

A trivial patch is attached to make proj3d.py work.

I tried the examples and it looks great. However, it's pretty slow, at
least on my machine. The plotting in sympy is much faster. Is there
some way to make the mplot3d faster?

Ondrej

Hi Reinier,

Awesome.  Those plots are making me smile! I also agree with your
refactoring and have applied your patch to my git repository.

I agree with you concerning the sympy plotting routines.  I think what
we have here is quite flexible and does a very good job of replicating
the equivalent functionality of MATLAB.  I think it would be a huge
effort trying to make 2D plots and 3D plots look consistent if another
approach was taken.  Indeed, this is a desirable characteristic.  In
addition, the code is actually very short and easy to maintain.  Given
that matplotlib has had trouble maintaining 3D code in the past, it
might not be a good idea to switch to a more complicated codebase.

You should grab some of my more recent changes as I have added a few
more fixes.  Most importantly, if you reuse the same figure, the old
event handlers will still attached preventing Axes objects from dieing
and causing interactive manipulation of the plots to be very sluggish.
 Also, in terms of performance, I have found that switching to TkAgg
from GTKAgg was helpful.

Also, I think the original code from John Porter was under a BSD
license.  I am thinking of adding our names and the BSD license to the
top of each file to protect it while its not officially part of
matplotlib.  What do you think?

Best,
Jonathan.

On Sun, Mar 8, 2009 at 8:04 PM, Reinier Heeres <re...@he...> wrote:
> Hi,
>
> I've done some further refactoring of mplot3d:
>
> - Almost all of the test plotting functions work, except for
> test_bar2D. Filled contours are not perfect yet and need a bit more
> work. Try "python axes.py" with the attached files to see how it
> looks!
>
> - I removed the Wrap2D class, which was using private class members
> throughout. I replaced this approach with dynamically changing the
> class type for Artist objects (e.g. PolyCollection to
> Poly3DCollection). This is also a bit of voodoo, but I think in the
> end it results in a bit less code, which is also more readable.
>
> - Much more code could still be removed (and added again later if necessary)
>
> Regards,
> Reinier
>
> BTW: I think plugging sympy's plotting functionality into matplotlib
> would not be so easy! The mplot3d code is much better suited for
> this...
>
> On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux
> <gae...@no...> wrote:
>> On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote:
>>> Nevertheless, I hate to think of matplotlib sending people to mayavi2 each
>>> time 3D plotting is needed. Basic functionalities built-in would still be
>>> highly desirable.
>>
>> Absolutely. I think we need basic 3D plotting functionnality that work
>> without any 3D rendering library, both for robustess and for simplicity.
>>
>> I used to think different, because I believe that this approach is bound
>> to fail on anything but very simple problems (my experience with gnuplot
>> :>). I fear people are going to try and pull too far the simple 3D
>> implementation.
>>
>> Nevertheless, it would be great to have some 3D in matplotlib, for easier
>> mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary
>> file, loading the result with matplotlib's imread, and displaying it with
>> an imshow -- ugly!), and to have backend-universal, robust, 3D plotting.
>>
>> Gaël
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Reinier Heeres
> Waalstraat 17
> 2515 XK Den Haag
> The Netherlands
>
> Tel: +31 6 10852639
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,

I've done some further refactoring of mplot3d:

- Almost all of the test plotting functions work, except for
test_bar2D. Filled contours are not perfect yet and need a bit more
work. Try "python axes.py" with the attached files to see how it
looks!

- I removed the Wrap2D class, which was using private class members
throughout. I replaced this approach with dynamically changing the
class type for Artist objects (e.g. PolyCollection to
Poly3DCollection). This is also a bit of voodoo, but I think in the
end it results in a bit less code, which is also more readable.

- Much more code could still be removed (and added again later if necessary)

Regards,
Reinier

BTW: I think plugging sympy's plotting functionality into matplotlib
would not be so easy! The mplot3d code is much better suited for
this...

On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux
<gae...@no...> wrote:
> On Thu, Mar 05, 2009 at 07:03:00PM +0100, Cohen-Tanugi Johann wrote:
>> Nevertheless, I hate to think of matplotlib sending people to mayavi2 each
>> time 3D plotting is needed. Basic functionalities built-in would still be
>> highly desirable.
>
> Absolutely. I think we need basic 3D plotting functionnality that work
> without any 3D rendering library, both for robustess and for simplicity.
>
> I used to think different, because I believe that this approach is bound
> to fail on anything but very simple problems (my experience with gnuplot
> :>). I fear people are going to try and pull too far the simple 3D
> implementation.
>
> Nevertheless, it would be great to have some 3D in matplotlib, for easier
> mixing of 2D and 3D (I do this with Mayavi2 by saving to a temporary
> file, loading the result with matplotlib's imread, and displaying it with
> an imshow -- ugly!), and to have backend-universal, robust, 3D plotting.
>
> Gaël
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands

Tel: +31 6 10852639