matplotlib-devel Mailing List for matplotlib (Page 4)

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

On Fri, Mar 6, 2009 at 23:00, Eric Firing <ef...@ha...> wrote:
> Sandro Tosi wrote:
>>
>> On Fri, Mar 6, 2009 at 22:12, Sandro Tosi <mo...@de...> 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?
>>
>> Moreover, I will provide a patch to move from
>>
>>>>> from wx import *
>>
>> to
>>
>>>>> import wx
>>
>> that's much more clear. Just let me know if in the patch I will add
>> the wxversion.select or no.
>>
>> Regards,
>
> Sounds good to me, but I am not a wx user, so I might be missing something.
> The only reservation that occurs to me is this: suppose version 2.10 comes
> out, and someone has only that installed. Is there a way to select 2.8 or
> higher, instead of requiring 2.8?
AFAIUI, it's not possible to say "2.8+" == "2.8 and all the higher
versions", but we can specify a list of version to be searched, the
first match is the one "mapped" as default wx. If no-one of the
specified version are available, then an exception is thrown:
>>> import wxversion
>>> wxversion.select(['2.5','2.3','2.9'])
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib/python2.5/site-packages/wxversion.py", line 149, in select
 raise VersionError("Requested version of wxPython not found")
wxversion.VersionError: Requested version of wxPython not found
>>> wxversion.select(['2.5','2.3','2.8'])
>>> import wx
>>> wx.__version__
'2.8.7.1'
In any case, the example code doesn't work with wx2.6 so, as even a
temporary workaround, I think we should enforce the needs for wx2.8.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Sandro Tosi wrote:
> On Fri, Mar 6, 2009 at 22:12, Sandro Tosi <mo...@de...> 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?
> 
> Moreover, I will provide a patch to move from
> 
>>>> from wx import *
> 
> to
> 
>>>> import wx
> 
> that's much more clear. Just let me know if in the patch I will add
> the wxversion.select or no.
> 
> Regards,
Sounds good to me, but I am not a wx user, so I might be missing 
something. The only reservation that occurs to me is this: suppose 
version 2.10 comes out, and someone has only that installed. Is there a 
way to select 2.8 or higher, instead of requiring 2.8?
Eric

On Fri, Mar 6, 2009 at 22:12, Sandro Tosi <mo...@de...> 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?
Moreover, I will provide a patch to move from
>>> from wx import *
to
>>> import wx
that's much more clear. Just let me know if in the patch I will add
the wxversion.select or no.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello,
we are facing a problem in Debian where a user has problems running
embedding_in_wx*.py examples.
The problem is:
>>> from wx import *
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__DocFilter'
>>> import wx
>>> print wx.__version__
2.6.3.2
Since WX2.8 is the one to use, the solution is simple:
>>> 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?
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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

On Thu, Mar 05, 2009 at 11:44:16AM -0500, Rob Clewley wrote:
> If I have a set of scalar sample data on a rectangular 2D mesh that I
> want to plot in the 3D I'd want a simple wireframe rectangular surface
> plot. Can it do that?
My experience from trying to design a simple API to do simple 3D plotting
of data stored as numpy array is that everybody has his own usecase (that
he often believes is universal and obvious), and that designing an API to
make a particular usecase simple is easy, but keeping reasonnably
versatile and powerful API while making it easy to use for all the
'simple' usecases is terribly hard.
That said, Mayavi2 is incredibly powerful and with time (thanks to
feedback from users) we are getting better at having a simple and
powerful API, and a documentation that tries to 'solve your problem'.
I know Mayavi2 has its problems (mainly difficult to instal because of
historical reasons, and big dependencies), but for non trivial 3D
plotting problems, especially with large datasets, keep it in mind. (It
also works well for trivial problems, it is just that if it is not
packaged, I understand that the hassle of installing it may be higher
than the gain of using it).
By the way, I am happy to take feedback on any problems with Mayavi2 (I
am not pretending I will solve them :>). I believe that we have made huge
progress in usability recently, and that it is no longer a monster hard
to master and useless for simple problems, but I may be mistaken.
Cheers,
Gaël

On Thu, Mar 5, 2009 at 11:44 AM, Rob Clewley <rob...@gm...> wrote:
> On Thu, Mar 5, 2009 at 10:39 AM, Ondrej Certik <on...@ce...> wrote:
>
>>> OK, but it wasn't clear from the example that I could plot a 3D array
>>> of arbitrary data points. The way that you put together the demo plots
>>
>> As I understand it, it plots triangles and/or wireframe in the end.
>> Currently I think our plotting mainly works with surfaces. How can you
>> plot a 3D array of arbitrary data points?
>
> E.g., by plotting a dot at the coordinate (x,y,z).
I guess more like a small ball in opengl. I think this can be done
directly in pyglet.
>
>> You need to convert it to
>> some triangles first, e.g. do you want to plot contours (isosurfaces)?
>> Or do you want to cut a plane in your 3D data points and plot that
>> plane?
>>
>
> If I have a set of scalar sample data on a rectangular 2D mesh that I
> want to plot in the 3D I'd want a simple wireframe rectangular surface
> plot. Can it do that?
Yes, that can be done. I can post a simple example, but right now I am
urgently working on getting mayavi2 working in the offline mode in the
Sage notebook for my presentation on Friday, so I'll get back to this
later.
Ondrej

On Thu, Mar 5, 2009 at 10:39 AM, Ondrej Certik <on...@ce...> wrote:
>> OK, but it wasn't clear from the example that I could plot a 3D array
>> of arbitrary data points. The way that you put together the demo plots
>
> As I understand it, it plots triangles and/or wireframe in the end.
> Currently I think our plotting mainly works with surfaces. How can you
> plot a 3D array of arbitrary data points?
E.g., by plotting a dot at the coordinate (x,y,z).
> You need to convert it to
> some triangles first, e.g. do you want to plot contours (isosurfaces)?
> Or do you want to cut a plane in your 3D data points and plot that
> plane?
>
If I have a set of scalar sample data on a rectangular 2D mesh that I
want to plot in the 3D I'd want a simple wireframe rectangular surface
plot. Can it do that?
-Rob

On Thu, Mar 5, 2009 at 10:15 AM, Rob Clewley <rob...@gm...> wrote:
>>> Yes, I didn't know that either. But it's not clear if I can plot
>>> discrete data using this interface - at least the examples on the wiki
>>
>> I am not sure if I understand your question, but It only plots
>> discrete data --- it takes some sympy expression, evaluates it on a
>> discrete grid and plots it. So you would just take the plotting stuff.
>
> OK, but it wasn't clear from the example that I could plot a 3D array
> of arbitrary data points. The way that you put together the demo plots
As I understand it, it plots triangles and/or wireframe in the end.
Currently I think our plotting mainly works with surfaces. How can you
plot a 3D array of arbitrary data points? You need to convert it to
some triangles first, e.g. do you want to plot contours (isosurfaces)?
Or do you want to cut a plane in your 3D data points and plot that
plane?
> involved a symbolic function that would be called to generate the
> points. Maybe you could add an example that plots some arbitrary data
> that has been imported from a text file?
>
>>> make it look that way. I'm also +1 on seeing it moved into mpl, but I
>>> don't know if the APIs and dependencies are too dissimilar to make it
>>> work.
>>
>> There are no dependencies besides pyglet (e.g. it does not depend on
>> sympy, or if it does, it can be trivially fixed).
>
> Well, I meant more like is there a design dependency that is
> incompatible with mpl. I'll shut up now because I know zilch about
> mpl's internals!
The best thing is to just look into our sources, it's pretty well documented.
Ondrej

>> Yes, I didn't know that either. But it's not clear if I can plot
>> discrete data using this interface - at least the examples on the wiki
>
> I am not sure if I understand your question, but It only plots
> discrete data --- it takes some sympy expression, evaluates it on a
> discrete grid and plots it. So you would just take the plotting stuff.
OK, but it wasn't clear from the example that I could plot a 3D array
of arbitrary data points. The way that you put together the demo plots
involved a symbolic function that would be called to generate the
points. Maybe you could add an example that plots some arbitrary data
that has been imported from a text file?
>> make it look that way. I'm also +1 on seeing it moved into mpl, but I
>> don't know if the APIs and dependencies are too dissimilar to make it
>> work.
>
> There are no dependencies besides pyglet (e.g. it does not depend on
> sympy, or if it does, it can be trivially fixed).
Well, I meant more like is there a design dependency that is
incompatible with mpl. I'll shut up now because I know zilch about
mpl's internals!

On Thu, Mar 5, 2009 at 10:02 AM, Rob Clewley <rob...@gm...> wrote:
> On Thu, Mar 5, 2009 at 5:14 AM, Johann Cohen-Tanugi
> <co...@sl...> wrote:
>> wouaouh..... if I had known that sumpy had this functionality, I would
>> have downloaded it ages ago. This is a good example of justified
>> 'taylorisation', IMHO.
>> Big +1 on seing this moved from sympy to matplotlib. I am not expert at
>> coding guis et al, but if you need reviewers/testers or doc writers, I
>> will be happy to give a hand (even two).
>> best,
>> Johann
>
> Yes, I didn't know that either. But it's not clear if I can plot
> discrete data using this interface - at least the examples on the wiki
I am not sure if I understand your question, but It only plots
discrete data --- it takes some sympy expression, evaluates it on a
discrete grid and plots it. So you would just take the plotting stuff.
> make it look that way. I'm also +1 on seeing it moved into mpl, but I
> don't know if the APIs and dependencies are too dissimilar to make it
> work.
There are no dependencies besides pyglet (e.g. it does not depend on
sympy, or if it does, it can be trivially fixed).
As to the API, just look into sympy/plotting. And play with the 3D
plots in sympy to see how it looks like and how fast/slow it is (I
think it's pretty fast). Then you will have to decide, if it's easier
for you to implement something from scratch, or take our stuff.
As I said, I would love if mpl has similar capability, so that we can
get rid of this from sympy. If you decide to go this way, I (and other
sympy developers) will be at hand to help you integrate it.
Ondrej

On Thu, Mar 5, 2009 at 5:14 AM, Johann Cohen-Tanugi
<co...@sl...> wrote:
> wouaouh..... if I had known that sumpy had this functionality, I would
> have downloaded it ages ago. This is a good example of justified
> 'taylorisation', IMHO.
> Big +1 on seing this moved from sympy to matplotlib. I am not expert at
> coding guis et al, but if you need reviewers/testers or doc writers, I
> will be happy to give a hand (even two).
> best,
> Johann
Yes, I didn't know that either. But it's not clear if I can plot
discrete data using this interface - at least the examples on the wiki
make it look that way. I'm also +1 on seeing it moved into mpl, but I
don't know if the APIs and dependencies are too dissimilar to make it
work.

wouaouh..... if I had known that sumpy had this functionality, I would 
have downloaded it ages ago. This is a good example of justified 
'taylorisation', IMHO.
Big +1 on seing this moved from sympy to matplotlib. I am not expert at 
coding guis et al, but if you need reviewers/testers or doc writers, I 
will be happy to give a hand (even two).
best,
Johann
Ondrej Certik wrote:
> Hi,
>
> On Wed, Mar 4, 2009 at 11:38 AM, Jonathan Taylor
> <jon...@ut...> wrote:
> 
>> Great. I applied your patch and pushed it to the web repository.
>>
>> I agree, that some more serious refactoring might be good. I have
>> been leaving comments throughout the code with my thoughts on this.
>> 
>
> John just pointed me to this thread, so I just wanted to mention that
> we have 3d plots in sympy, that are pure python and use pyglet, here
> are some examples and docs:
>
> http://wiki.sympy.org/wiki/Plotting_Module
>
> http://docs.sympy.org/modules/plotting.html
>
> and if anyone would be interested in taking the code and use it for
> some of the 3D stuff that you want to do, I would fully support it.
> Ideally, if any of you would take it and maintain it, so that we don't
> have to, it'd be really awesome. We would like to just concentrate on
> symbolic manipulation with sympy and leave all the plotting to
> matplotlib, or other packages, if needed.
>
> Let me know if you are interested, we can help with integrating it.
>
> Ondrej
>
> ------------------------------------------------------------------------------
> 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,
On Wed, Mar 4, 2009 at 11:38 AM, Jonathan Taylor
<jon...@ut...> wrote:
> Great. I applied your patch and pushed it to the web repository.
>
> I agree, that some more serious refactoring might be good. I have
> been leaving comments throughout the code with my thoughts on this.
John just pointed me to this thread, so I just wanted to mention that
we have 3d plots in sympy, that are pure python and use pyglet, here
are some examples and docs:
http://wiki.sympy.org/wiki/Plotting_Module
http://docs.sympy.org/modules/plotting.html
and if anyone would be interested in taking the code and use it for
some of the 3D stuff that you want to do, I would fully support it.
Ideally, if any of you would take it and maintain it, so that we don't
have to, it'd be really awesome. We would like to just concentrate on
symbolic manipulation with sympy and leave all the plotting to
matplotlib, or other packages, if needed.
Let me know if you are interested, we can help with integrating it.
Ondrej

That fixes it for me. Thanks a lot for the quick fixes!
Ryan
On Wed, Mar 4, 2009 at 2:53 PM, Michael Droettboom <md...@st...> wrote:
> I was rounding where I should have been truncating. I think this is fixed
> now in SVN.
>
> Mike
>
> Ryan May wrote:
>
>> On Wed, Mar 4, 2009 at 12:16 PM, Michael Droettboom <md...@st...<mailto:
>> md...@st...>> wrote:
>>
>> The 'regular' font stuff just isn't very well tested yet. I think
>> I have a fix in SVN now.
>>
>>
>> Thanks for the quick fix, it got rid of my errors. However, I'm seeing a
>> little more of the funky font baseline that you had fixed. My original
>> script doesn't show any problem, but I've attached an image produced with
>> the mathtext_demo.py. Notice the odd baseline for versus in the title and
>> sin in the equation on the graph. Thoughts?
>>
>> Ryan
>>
>> --
>> Ryan May
>> Graduate Research Assistant
>> School of Meteorology
>> University of Oklahoma
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.