matplotlib-devel Mailing List for matplotlib

On Mon, Apr 11, 2011 at 3:51 PM, Eric Firing <ef...@ha...> wrote:
> On 04/11/2011 07:24 AM, Darren Dale wrote:
>> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<md...@st...> wrote:
>>> I couldn't find the old thread about Sourceforge bug tracker vs. the
>>> Github issue tracker, but maybe we should reevaluate based on the new
>>> Github issue tracker announced on Saturday:
>>>
>>> https://github.com/blog/831-issues-2-0-the-next-generation
>>>
>>> The integration with git commits (closing issues by mentioning them in
>>> the commit message) is particularly compelling.
>>
>> The new issue tracker is a really big improvement over the old github
>> tracker, and I prefer it to the one at sourceforge since it integrates
>> so nicely with github version control. The github tracker is still
>> missing some features that we may want to consider: prioritize issues,
>> add attachments, and perhaps report issues without opening a github
>> account.
>
> It is better, but to my eye, still not good.
>
> Prioritization can be handled via labels or milestones, but the lack of
> a simple, obvious attachment facility is a huge omission. As far as I
> know there is also no simple set of categories for closed status--maybe
> that would also be done with labels. (I'm not positive; I have not
> closed an item, and nothing happens when I click the "60 closed issues"
> tab, expecting to see the closed issues. Similarly, nothing happens
> when I click the "submitted" "updated", and "comments" buttons. Maybe
> all these things are bugs that show up if one does not have Firefox 4 or
> Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all
> comments is a horrible design, and all the more so in the absence of
> file up/download facility.
>
> It's being used; I think we are stuck with it. I have no objection to
> getting the migration over with, if you have the machinery to do it, Dale.
I'm willing to continue working on the conversion, iff (not a typo) it
is what the other developers want. It may be a while before I could
get to it though.
Darren

On Mon, Apr 11, 2011 at 4:16 AM, Konrad Bartkowski <
k.b...@fz...> wrote:
> Ok, forwarding it to the matplotlib-devel list.
>
>
> Best wishes,
>
> Konrad (on behalf of our workgroup)
>
>
> -------- Original Message -------- Subject: Source of inaccuracies in the
> matplotlib library Date: Fri, 8 Apr 2011 18:12:47 +0200 From: Bartkowski,
> Konrad <k.b...@fz...> <k.b...@fz...> To:
> dd...@co... <dd...@co...> <dd...@co...>, md...@st...
> <md...@st...> <md...@st...>, ef...@ha...
> <ef...@ha...> <ef...@ha...>, jdh...@ac...
> <jdh...@ac...> <jdh...@ac...>,
> jd...@gm... <jd...@gm...> <jd...@gm...> CC: Bartkowski,
> Konrad <k.b...@fz...> <k.b...@fz...>,
> el...@in... <el...@in...> <el...@in...>, Matthias Bolten
> <bo...@ma...> <bo...@ma...>,
> Grotendorst, Johannes <j.g...@fz...><j.g...@fz...>,
> Steffen, Bernhard <b.s...@fz...> <b.s...@fz...>
>
> Dear Matplotlib developers,
>
> I am writing about the matplotlib library with the mpl_toolkits. First
> of all let me emphasize how great software it is. Recently, in one of
> our projects we were rendering big surfaces and encountered the
> following problem:
> http://www.mail-archive.com/mat...@li.../msg06869.html
>
> It's not a bug (which all in all is a natural and unavoidable ingredient
> of the software, and especially in such a big and complex system like
> matplotlib would be fully natural), since the software does exactly the
> projection mathematics that it is expected to do, but a source of the
> inaccuracies, which is especially visible in the critical examples. For
> the profit of the Python community we are sending You a proposition of a
> modification of the surface plotting rendering system, in case You find
> it interesting enough to include in the consecutive version of the
> library. In the source code from the attachment we redesigned a little
> bit the computation process – since the computations are especially
> sensible to numerical errors, that are for example amplified while
> norming or processing the quaterions in the various stages (for example
> division over coordinate in the perspective projection). Therefore the
> computational focus can be shifted from the Polygon collection to the
> polygons itself. In the example from the above forum or the slightly
> modified one, one can observe a big difference in the numerical
> precision while the speed of the computations does not decrease (at
> least visibly). While instead of the surfaces from the forum, the
> following surfaces are rendered:
>
> u = np.linspace(0, 2 * np.pi, 100)
> v = np.linspace(0, np.pi, 100)
>
> x = 10 * np.outer(np.cos(u), np.sin(v))
> y = 10 * np.outer(np.sin(u), np.sin(v))
> z = 10 * np.outer(np.ones(np.size(u)), np.cos(v))
>
> ax.plot_surface(x, y, z, rstride=8, cstride=8, color='y', alpha=0.5)
> shiftX=28
> shiftY=28
> X,Y=np.meshgrid(range(-20+shiftX,20+shiftX),range(-20+shiftY,20+shiftY))
> Z=np.ones((X.shape[0], Y.shape[1]))
> ax.plot_surface(X, Y, Z, color='r', rstride=10, cstride=10, alpha=1.0)
>
> the issue is visible for example at the azimuth=40 , elevation=70 – with
> those parameters the mentioned case is visible on the red surface, while
> with elevation=68 not. Moreover, now also the stride is big (in the new
> approach the influence of increasing stride on the numerical precision
> grows).
> So again let me use this opportunity to thank You for empowering the
> Python community worldwide in a great, powerful scientific visualization
> tool.
>
> Best wishes,
> Konrad Bartkowski
>
>
Konrad,
Thank you for this contribution. It seems that I am currently the de facto
maintainer of the mplot3d code, but I have been focused on my PhD for the
past month. I will take a look at the code in more detail over the weekend.
Thanks!
Ben Root

On Thu, Apr 14, 2011 at 5:54 PM, John Hunter <jd...@gm...> wrote:
>
>
>
>
> On Apr 14, 2011, at 5:08 PM, Benjamin Root <ben...@gm...> wrote:
>
> It was added a while back, unless I only added it to the master...?
>
>
> Could be. It appears the mplot3d tutorial rest document in the release
> branch refers to it, but it is not committed in the branch. You can either
> commit the file or remove the doc reference from the branch.
>
Ok, I just double-check what happened. I added a feature to mplot3d, and
because it was a new feature, it was not added to the maintenance branch
(although, that is the only reason why it was not backported). The missing
demo requires that feature, therefore, it is the docs that are wrong in the
v1.0.x branch.
I am still in the middle of my work (although the load has lightened today),
and so I haven't been git-minded in a while. Would a change to the v1.0.x
branch "stay" on the v1.0.x branch, or is there something I have to do to
prevent subsequent merges from going into master?
Ben Root

On Apr 14, 2011, at 5:08 PM, Benjamin Root <ben...@gm...> wrote:
> It was added a while back, unless I only added it to the master...?
> 
Could be. It appears the mplot3d tutorial rest document in the release branch refers to it, but it is not committed in the branch. You can either commit the file or remove the doc reference from the branch. 

It was added a while back, unless I only added it to the master...?
Ben Root
On Thu, Apr 14, 2011 at 4:39 PM, John Hunter <jd...@gm...> wrote:
> Doc build is failing with a missing file
>
> .. plot:: mpl_examples/mplot3d/contourf3d_demo2.py
>
> I can work around it, but this should get added...
>
> JDH
>

Hi,
"For details on what's new, see the detailed
changelog<http://matplotlib.sourceforge.net/_static/CHANGELOG> or
browse the source code <https://github.com/matplotlib/matplotlib.git>. "
The source code links broken. https://github.com/matplotlib/matplotlib.git
 -> https://github.com/matplotlib/matplotlib
<https://github.com/matplotlib/matplotlib>and the changelog could point to
https://github.com/matplotlib/matplotlib/blob/master/CHANGELOG instead of
http://matplotlib.sourceforge.net/_static/CHANGELOG
On Thu, Apr 14, 2011 at 4:01 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Apr 14, 2011 at 9:53 AM, John Hunter <jd...@gm...> wrote:
> > On Tue, Apr 12, 2011 at 6:18 PM, Fernando Perez <fpe...@gm...>
> wrote:
> >> On Tue, Apr 12, 2011 at 4:13 PM, John Hunter <jd...@gm...> wrote:
> >>> Yes, I'll get thus fixed ASAP
> >>
> >> John, quick note: our local network is down (firewall transfer went
> >> awry), so if you need to rebuild the docs, you'll need to do it on
> >> another system than my box (I'm using a laptop over wireless to send
> >> this).
> >
> > Any idea when this will be back up -- building the docs on my solaris
> > box here at work is proving more difficult than expected (segfaults
> > due to a bug in numpy's complex dtype handling, reported months ago
> > but still unfixed)
>
> Docs are now pushed to sf -- preliminary look looks good. Thanks
> Fernando for the build resources.
>
> JDH
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Gökhan

On Thu, Apr 14, 2011 at 3:01 PM, John Hunter <jd...@gm...> wrote:
> Docs are now pushed to sf -- preliminary look looks good. Thanks
> Fernando for the build resources.
My pleasure; my office has no heating, but everytime a mpl doc build
happens it gets a little less chilly here :)
f

On Thu, Apr 14, 2011 at 9:53 AM, John Hunter <jd...@gm...> wrote:
> On Tue, Apr 12, 2011 at 6:18 PM, Fernando Perez <fpe...@gm...> wrote:
>> On Tue, Apr 12, 2011 at 4:13 PM, John Hunter <jd...@gm...> wrote:
>>> Yes, I'll get thus fixed ASAP
>>
>> John, quick note: our local network is down (firewall transfer went
>> awry), so if you need to rebuild the docs, you'll need to do it on
>> another system than my box (I'm using a laptop over wireless to send
>> this).
>
> Any idea when this will be back up -- building the docs on my solaris
> box here at work is proving more difficult than expected (segfaults
> due to a bug in numpy's complex dtype handling, reported months ago
> but still unfixed)
Docs are now pushed to sf -- preliminary look looks good. Thanks
Fernando for the build resources.
JDH

Doc build is failing with a missing file
.. plot:: mpl_examples/mplot3d/contourf3d_demo2.py
I can work around it, but this should get added...
JDH

On Thu, Apr 14, 2011 at 2:10 PM, Paul Ivanov <piv...@gm...> wrote:
> Fernando Perez, on 2011年04月14日 11:08, wrote:
>> On Thu, Apr 14, 2011 at 7:53 AM, John Hunter <jd...@gm...> wrote:
>> > Any idea when this will be back up -- building the docs on my solaris
>> > box here at work is proving more difficult than expected (segfaults
>> > due to a bug in numpy's complex dtype handling, reported months ago
>> > but still unfixed)
>>
>> Give me an hour or so, I'll ping you back...
Thanks Paul, I'm all set up on Fernando's machine so I'll hold off a
bit to see if he can resuscitate it. If the problem persists, I'll
give yours a try.

Fernando Perez, on 2011年04月14日 11:08, wrote:
> On Thu, Apr 14, 2011 at 7:53 AM, John Hunter <jd...@gm...> wrote:
> > Any idea when this will be back up -- building the docs on my solaris
> > box here at work is proving more difficult than expected (segfaults
> > due to a bug in numpy's complex dtype handling, reported months ago
> > but still unfixed)
> 
> Give me an hour or so, I'll ping you back...
> 
> f
> 
John, Fernando, and others:
I'm happy to make my work machine available for building the
docs, or general development, testing, etc - it's has 64 bit
Ubuntu 8.04 (python 2.5.2) on it at the moment. I can provide
access to anyone who gives me their public ssh key. 
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Thu, Apr 14, 2011 at 7:53 AM, John Hunter <jd...@gm...> wrote:
> Any idea when this will be back up -- building the docs on my solaris
> box here at work is proving more difficult than expected (segfaults
> due to a bug in numpy's complex dtype handling, reported months ago
> but still unfixed)
Give me an hour or so, I'll ping you back...
f

On Tue, Apr 12, 2011 at 6:18 PM, Fernando Perez <fpe...@gm...> wrote:
> On Tue, Apr 12, 2011 at 4:13 PM, John Hunter <jd...@gm...> wrote:
>> Yes, I'll get thus fixed ASAP
>
> John, quick note: our local network is down (firewall transfer went
> awry), so if you need to rebuild the docs, you'll need to do it on
> another system than my box (I'm using a laptop over wireless to send
> this).
Any idea when this will be back up -- building the docs on my solaris
box here at work is proving more difficult than expected (segfaults
due to a bug in numpy's complex dtype handling, reported months ago
but still unfixed)

Fernando Perez, on 2011年04月13日 17:59, wrote:
> http://www.wired.com/wiredscience/2011/04/crashing-into-wall/
> 
> need to teach him about annotations, though, because the acceleration
> plot looks annotated by hand after the fact (from the fonts, I'm
> guessing on a Mac, maybe with Keynote).
Maybe citations, too? I'm guessing you inferred he used mpl from
the plots and the python tag on the post - but what are mere
mortals supposed to do?
:)
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

http://www.wired.com/wiredscience/2011/04/crashing-into-wall/
need to teach him about annotations, though, because the acceleration
plot looks annotated by hand after the fact (from the fonts, I'm
guessing on a Mac, maybe with Keynote).
cheers
f