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 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.
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...
mplot3d_20080309.tgz (15.5 KB)
···
On Thu, Mar 5, 2009 at 7:13 PM, Gael Varoquaux <gael.varoquaux@...427...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
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 <reinier@...707...> 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 > <gael.varoquaux@...427...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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
0001-Make-proj3d.py-work-by-importing-pylab.patch (591 Bytes)
···
On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor <jonathan.taylor@...247...> 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?
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 <ondrej@...583...> wrote:
On Sun, Mar 8, 2009 at 7:45 PM, Jonathan Taylor > <jonathan.taylor@...247...> 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,
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 <jonathan.taylor@...247...> 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.
J
···
On Mon, Mar 9, 2009 at 12:17 AM, Ondrej Certik <ondrej@...583...> wrote:
On Sun, Mar 8, 2009 at 9:01 PM, Jonathan Taylor > <jonathan.taylor@...247...> 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,
I updated my patch a bit more, and now all tests are running (try
"python axes3d.py"). Only the contourf3D is not working correctly yet,
but I'm sure it's fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I've not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
Regards,
Reinier
···
On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor <jonathan.taylor@...247...> 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?
Best,
Jonathan.
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
Hi, that is great! Can you give me a git repository address to pull
from? I can't from the web viewer.
Thanks,
J.
···
On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres <reinier@...707...> wrote:
Hi,
I updated my patch a bit more, and now all tests are running (try
"python axes3d.py"). Only the contourf3D is not working correctly yet,
but I'm sure it's fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I've not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
Regards,
Reinier
On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor > <jonathan.taylor@...247...> 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?
Best,
Jonathan.
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
One thing you can do is send a patch against lib/mpl-toolkits and I’ll apply it to svn trunk.
I was briefly scrolling through the recent diffs on art3d, and noticed
Except in very special cases, we do not allow blanket excepts – eg you should catch explicitly the error you are trying to trap. Also, it is usually better to try just the part you are trying to catch and then do the rest in an else. So if you are trying to catch the case where zs is not a float
try:
zs = float(zs)
except TypeError:
pass
else:
zs = [zs for i in range(len(paths))]
Also, again I am not excatly sure what you are trying to do here, mpl has “duck typing” helpers to test whether something is iterable or num-like. So you can do
import matplotlib.cbook as cbook
if not cbook.iterable(zs):
zs =float(zs)
zs = [zs for i in range(len(paths))]
Anyway – great work so far. I’m having trouble making a git co work so I am looking forward to testing this when you have a snapshot or svn diff.
JDH
···
On Wed, Mar 11, 2009 at 3:25 AM, Reinier Heeres <reinier@…707…> wrote:
Hi,
I updated my patch a bit more, and now all tests are running (try
“python axes3d.py”). Only the contourf3D is not working correctly yet,
but I’m sure it’s fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I’ve not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
Hi John,
You should be able to check out a copy from my git repo via
git clone http://jonathantaylor.ca/mplot3d.git
cd mplot3d
git pull
I am missing Reiniers final update though but you should be able to
run demo.py and the first few examples in the __name__ == '__main__'
clause of axes3d.py.
Best, J.
···
On Wed, Mar 11, 2009 at 2:21 PM, John Hunter <jdh2358@...149...> wrote:
On Wed, Mar 11, 2009 at 3:25 AM, Reinier Heeres <reinier@...707...> wrote:
Hi,
I updated my patch a bit more, and now all tests are running (try
"python axes3d.py"). Only the contourf3D is not working correctly yet,
but I'm sure it's fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I've not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
One thing you can do is send a patch against lib/mpl-toolkits and I'll apply
it to svn trunk.
I was briefly scrolling through the recent diffs on art3d, and noticed
+ try:
+ zs = float(zs)
+ zs = [zs for i in range(len(paths))]
+ except:
+ pass
Except in very special cases, we do not allow blanket excepts -- eg you
should catch explicitly the error you are trying to trap. Also, it is
usually better to try just the part you are trying to catch and then do the
rest in an else. So if you are trying to catch the case where zs is not a
float
try:
zs = float(zs)
except TypeError:
pass
else:
zs = [zs for i in range(len(paths))]
Also, again I am not excatly sure what you are trying to do here, mpl has
"duck typing" helpers to test whether something is iterable or num-like. So
you can do
import matplotlib.cbook as cbook
if not cbook.iterable(zs):
zs =float(zs)
zs = [zs for i in range(len(paths))]
Anyway -- great work so far. I'm having trouble making a git co work so I
am looking forward to testing this when you have a snapshot or svn diff.
JDH
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Hi Jon,
Good point, I forgot about that!
It's available for cloning now: git clone
http://qtwork.nano.tudelft.nl/public_git/users/rwh/mplot3d
Cheers,
Reinier
···
On Wed, Mar 11, 2009 at 6:43 PM, Jonathan Taylor <jonathan.taylor@...247...> wrote:
Hi, that is great! Can you give me a git repository address to pull
from? I can't from the web viewer.
Thanks,
J.
On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres <reinier@...707...> wrote:
Hi,
I updated my patch a bit more, and now all tests are running (try
"python axes3d.py"). Only the contourf3D is not working correctly yet,
but I'm sure it's fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I've not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
Regards,
Reinier
On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor >> <jonathan.taylor@...247...> 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?
Best,
Jonathan.
--
Reinier Heeres
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
Hi all,
I reworked the code in axis3d so that the XYZ-planes are always behind
the object you're plotting. I also updated the label/ticks drawing a
bit and dropped a lot of unnecessary code. I pushed it to my git repo
at http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Regards,
Reinier
···
On Wed, Mar 11, 2009 at 11:22 PM, Reinier Heeres <reinier@...707...> wrote:
Hi Jon,
Good point, I forgot about that!
It's available for cloning now: git clone
http://qtwork.nano.tudelft.nl/public_git/users/rwh/mplot3d
Cheers,
Reinier
On Wed, Mar 11, 2009 at 6:43 PM, Jonathan Taylor > <jonathan.taylor@...247...> wrote:
Hi, that is great! Can you give me a git repository address to pull
from? I can't from the web viewer.
Thanks,
J.
On Wed, Mar 11, 2009 at 4:25 AM, Reinier Heeres <reinier@...707...> wrote:
Hi,
I updated my patch a bit more, and now all tests are running (try
"python axes3d.py"). Only the contourf3D is not working correctly yet,
but I'm sure it's fixable soon. There are also some obvious bugs (e.g.
the semi-3D histograms are not depth-sorted).
Anyway, I have applied the commit in a different git repo that also
has gitweb.cgi for viewing:
http://qtwork.nano.tudelft.nl/cgi-bin/gitweb.cgi?p=users/rwh/mplot3d;a=summary
Jon, I got rid of the spurious commit-and-revert entries but included
your latest commits; perhaps you can clone from this tree now?
Although I've not had a close look at the BSD license it definitely
sounds like a good idea to add it if it applies to the original code.
Shall we try to work to some sort of easily-installable form of the
again-working code?
Regards,
Reinier
On Mon, Mar 9, 2009 at 3:45 AM, Jonathan Taylor >>> <jonathan.taylor@...247...> 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?
Best,
Jonathan.
--
Reinier Heeres
--
Reinier Heeres
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639