Hello again Alberto,
On 4 July Alberto Azevedo wrote:
> When I use the triplot function with 100-1000 points it works well. The
> problem is that in my work I often use grids with 3-10
> points. With those grids triplot takes a long time to compute (I never
> wait for the results, it take
Hello Ian,
I'm really sorry for my comment, it was not my intention to offend anyone.
You are absolutely right about that, therefore I would like to apologize
to all developers, in particular to you, for my comment regarding the
matlab comparison.
The only thing I can promise is that won't hap
On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo wrote:
> I'm really sorry for my comment, it was not my intention to offend anyone.
> You are absolutely right about that, therefore I would like to apologize to
> all developers, in particular to you, for my comment regarding the matlab
> comparison
On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas wrote:
> Yes, it does indeed take a long time for large grids. The bottleneck is line
> 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a
> separate Line2D object for each edge in the triangulation, and there can be
> a lot of edg
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg06691.html
Looking back through mail, I noticed the above thread that was still
hanging with respect to 1.0.
A few minutes ago, in 8494, I went ahead and committed a change that
makes show block in tkagg and fltkagg, just as
After some more digging, I think I finally found the source of my issues. I
have noticed that there are inconsistencies between the keys and sections
listed in the default matplotlib.conf file and in the class MPLConfig().
While in most cases, these inconsistencies are innocuous and do not cause
e
On 07/05/2010 10:22 AM, Benjamin Root wrote:
> After some more digging, I think I finally found the source of my
> issues. I have noticed that there are inconsistencies between the keys
> and sections listed in the default matplotlib.conf file and in the class
> MPLConfig(). While in most cases,
On Mon, Jul 5, 2010 at 3:38 PM, Eric Firing wrote:
> On 07/05/2010 10:22 AM, Benjamin Root wrote:
> > After some more digging, I think I finally found the source of my
> > issues. I have noticed that there are inconsistencies between the keys
> > and sections listed in the default matplotlib.con
Although there are many active issues that are undergoing constant
work, none of these seem release critical and we can continue to
improve them on the branch and trunk as need be. Eric, who has been
doing the lion's share of the work managing, fixing and closing bugs,
feels like we are ready to g
Just re-pinging to see if there is any interest in this patch.
Ben Root
On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote:
> Hello all,
>
> I have always been a bit troubled with how Axes3D object is a bit of a
> 2nd-class citizen in matplotlib. In particular, it is very common to create
> a
On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote:
> Hello all,
>
> I have always been a bit troubled with how Axes3D object is a bit of a
> 2nd-class citizen in matplotlib. In particular, it is very common to create
> a new axes using .add_subplot() or .gca(), but you can't do that with
> Axes
11 matches
Mail list logo
