matplotlib-devel Mailing List for matplotlib

On Wed, Apr 27, 2011 at 4:17 AM, Clyng11 <cou...@ya...> wrote:
>
> I run this code, but labels do not appear under the ticks.
>
>   # label the X ticks with years
>   self.mpl.canvas.ax.set_xticks(np.arange(len(years))+width/2,
> [int(year) for year in years])
>   self.mpl.canvas.ax.set_xticklabels([str(year) for year in years])
>
> I Need an help.
Could you post a complete, free-standing example that we can run that
exposes your problem?

I run this code, but labels do not appear under the ticks.
 # label the X ticks with years 
 self.mpl.canvas.ax.set_xticks(np.arange(len(years))+width/2,
[int(year) for year in years])
 self.mpl.canvas.ax.set_xticklabels([str(year) for year in years])
I Need an help.
Thanks.
-- 
View this message in context: http://old.nabble.com/displaying-ticklabels-on-a-graph-tp31484414p31484414.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Mike,
I see you fixed a test side effect that I was not aware of. While you 
are working on the decorator, you might consider how to fix another: 
every test that imports testing/jpl_units is changing the way units are 
handled. This breaks test_axes.test_units_strings. In addition to 
closing the figure, the decorator could re-initialize units.registry 
(and rcParams).
Eric

Hi,
many GNU/Linux distributions discourage to bundle other software like matplotlib
does with PyCXX.
It is understandable you may not want additionally support each new version
of the bundled software.
But you should give the distribution package maintainers an easy way to use
the version available in the system should they wish to do so.
With the current build system this is not possible without rather large modifications.
To allow maintainers to use the system files the bundled CXX must be moved from the
matplotlib root to a subfolder, e.g. CXX -> external/CXX, so gcc will not unintentionally use the bundled headers.
Attached patch makes use of this move and modifies setupext.py to search for the PyCXX
sources in a list of possible folder pairs. The first folder where files are found is chosen.
The found sources and include path have been added to all CXX uses I found.
To prefer the system installed version put the paths to the front of the lists and
it will fall back to the bundled version if they are unavailable.
E.g. for debian:
_pycxx_src_paths = ["/usr/share/python{0}.{1}/".format(*sys.version_info[:2]), "external/"]
_pycxx_h_paths = ["/usr/include/python{0}.{1}/".format(*sys.version_info[:2]), "external/"]
Btw, I also saw you patched CXX for sparc
http://sourceforge.net/tracker/?func=detail&aid=3022815&group_id=80706&atid=560720
has this bug and patch been forwarded to pycxx?
It is not been applied to trunk yet, was it rejected?
PS: please CC me I'm not subscribed to the list.
Best Regards,
Julian Taylor

On Thursday, April 21, 2011, Konrad Bartkowski <k.b...@fz...>
wrote:
> Dear Ben, dear John,
>
> Thank You for the emails. Well, we have modified only the part
> influencing the modules, that we need or will need in our projects. I
> admit that apart from the deceptions connected with human perception
> (for example
> http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.2303 ) still
> the inaccuracy remains. Nevertheless all the surfaces we have rendered
> were unproblematic. Also the examples from the forum rendered correctly
> even for big stride. If it is unsatisfactory one can control the
> precision with the stride size.
Just to make sure, you never really described exactly what "numerical
inaccuracies" you were talking about. From the example you posted, I am
assuming that it is the overlapping/z-sorting issue. If it is something
else, then I am going to need to see some "before / after" images showing
the difference you are talking about. If it is the overlapping issue, then
the strides are only incidental to the problem. The problem exists for any
3d object, with or without strides.
The problem is one of dimensionality. While mplot3d does correctly
calculate the 3d coordinates of each vertex in the perspective coordinate
system, only one value for the depth axis can be reported for each artist.
 If the artist has many vertexes with different depth values, then a single
value will never be sufficient. It is this reduction of the depth
coordinates from many to one that is the source of the problem.
What your solution does is to not reduce the depth coordinates *as much*.
But it still does a reduction, therefore not solving the problem. The only
way to properly solve this is with a 3D rendering engine (like OpenGL).
>The modification was written under the
> assumption not to modify too much in the existing system. While writing
> the code we were naturally keeping in mind the ratio of accuracy to the
> computational effort.
> Since in our projects we didn't need the return value from the
> plot_surface we return the obtained list for the efficiency reasons. But
> if the API should remain unchanged, then one can generate also the
> previous collection and return it instead of the list, while the list is
> added.
This would cause many inconsistencies within the code. For example, if a
user wants to remove the collection from the axes, it won't work because the
collection doesn't exist in the axes object. Also, having a collection
object unconnected to any axis might cause unexpected behavior or could even
throw exceptions.
> I admit, that I didn't consider the changes You mention in the
> consecutive e-mails, since it would mean redesigning Your code. From the
> same reason I also cannot comment them – I simply don't know the
> internal structure of Your code sufficienty. Change on the level of
> Artists would probably imply a lot of other modifications in many, many
> modules.
>
That's ok. It was actually this problem that pushed me to learn matplotlib
to the point that I could become a developer. However, it took me another 6
months before I could understand the problem well enough to realize the
source of the issue and what was needed to solve it properly. If this patch
works well for your purposes, that's great, and I hope it continues to serve
you well. However, for a broader audience, it introduces too many potential
problems for us.
I hope you continue to use matplotlib and find it useful. And feel free to
continue commenting on the mplot3d module and how it can be improved!
Cheers,
Ben Root

Dear Ben, dear John,
 Thank You for the emails. Well, we have modified only the part
influencing the modules, that we need or will need in our projects. I
admit that apart from the deceptions connected with human perception
(for example
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.151.2303 ) still
the inaccuracy remains. Nevertheless all the surfaces we have rendered
were unproblematic. Also the examples from the forum rendered correctly
even for big stride. If it is unsatisfactory one can control the
precision with the stride size. The modification was written under the
assumption not to modify too much in the existing system. While writing
the code we were naturally keeping in mind the ratio of accuracy to the
computational effort.
 Since in our projects we didn't need the return value from the
plot_surface we return the obtained list for the efficiency reasons. But
if the API should remain unchanged, then one can generate also the
previous collection and return it instead of the list, while the list is
added.
 I admit, that I didn't consider the changes You mention in the
consecutive e-mails, since it would mean redesigning Your code. From the
same reason I also cannot comment them – I simply don't know the
internal structure of Your code sufficienty. Change on the level of
Artists would probably imply a lot of other modifications in many, many
modules.
------
Mit freundlichen Grüssen / With friendly greetings,
Konrad Bartkowski
On 04/15/11 23:02, Benjamin Root wrote:
>
>
> On Fri, Apr 15, 2011 at 3:54 PM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
>
>
> On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>
> There might be a possible work-around, though. Maybe (and I am
> just speculating here) if we can get the core part of matplotlib
> to specially treat 3d collection objects in such a way that
> allows the collection to return provide elements and z-order
> pairs. It is either that, or we finally try to get OpenGL
> working again in matplotlib and allow ourselves to specify
> coordinates in 3-D.
>
>
> It should be fairly easy to get a collections object to support
> multiple z-orders *within* the collection. Across artists, damn
> near impossible. I don't think you need to provide elements and
> z-order pairs per-se. The typical way a property is specified for a
> collection if you want it to vary over the elements of the
> collection is that the property is a sequence, and the property is
> accessed as prop[i%N] where i is the element number and N is the
> length of the property vector. So if we make zorder a len(elements)
> sequence of z-orders, we can order the collection by the zorder at
> draw time. Presumably external code would modify the zorder of the
> collection before each draw depending on the view.
>
>
>
> Within a collection, this is already done correctly (or at least, as
> well as one can except with a 2D rendering engine). It is when you have
> multiple artists that exists over parts of the z-order "axis" that there
> are problems. Essentially, if the 3-D bounding boxes overlap, then
> trouble ensues.
>
> Also, that speculation I had wouldn't work either, as the problem still
> would exist for intersecting patches. No, what we really need is a 3D
> rendering engine, and a logical separation between z-order for
> sorting/layering and z-coordinates.
>
> Ben Root
>
>
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de

Hi,
 please forgive me if that is not the appropriate mailing list to send this
message.
On the first page of the sampledoc
tutorial<http://matplotlib.sourceforge.net/sampledoc/>,
the second paragraph reads:
"The source code for this tutorial lives in mpl svn (see *Fetching the
data*<http://matplotlib.sourceforge.net/sampledoc/getting_started.html#fetching-the-data>)
and you can grab a harcopy of the the sampledoc
PDF<http://matplotlib.sourceforge.net/sampledoc/sampledoc.pdf>
"
I assume that the word 'harcopy' should be 'hardcopy', meanwhile 'the
the<http://en.wikipedia.org/wiki/The_The>'
could be replaced by a single 'the' ...
Just thought of letting you know.
Best,
-Sylvain

On Tue, Apr 19, 2011 at 10:03 AM, James Evans <jre...@ea...> wrote:
> Honestly, I do not know what the units rc param is for. Personally I try to stay away from anything rc parameter related.
>
> I would guess that it was put in to handle default units, but the unit system handles defaults based on the type of data being plotted. Perhaps it was added in the first draft of the unit code and never removed when it was revised?
>
> As far as I know, there is no need for it.
Unfortunately, I can't recall what it was added for either. As Eric
notes, it doesn't even make it into matplotlibrc.template, which
usually has a definition of the param, and I can't find it used
anywhere in the code base either.
JDH

On 04/19/2011 05:03 AM, James Evans wrote:
> Honestly, I do not know what the units rc param is for. Personally I try to stay away from anything rc parameter related.
>
I'm not an rc fan, either, though the rc system does have its benefits.
> I would guess that it was put in to handle default units, but the unit system handles defaults based on the type of data being plotted. Perhaps it was added in the first draft of the unit code and never removed when it was revised?
>
It's a boolean. I suspect that long ago it was for turning experimental 
units support on or off.
> As far as I know, there is no need for it.
I will try removing it.
Eric
>
> --James
>
>
>> -----Original Message-----
>> From: Darren Dale [mailto:dsd...@gm...]
>> Sent: Tuesday, April 19, 2011 4:42 AM
>> To: Eric Firing; jre...@ea...
>> Cc: matplotlib development list
>> Subject: Re: [matplotlib-devel] What is rcParams['units'] for?
>>
>> On Tue, Apr 19, 2011 at 3:07 AM, Eric Firing<ef...@ha...> wrote:
>>> While investigating the imshow problem reported today by Emanuale
>>> Passera (a problem that seems to have been fixed, though I don't know
>>> when or how), I stumbled across the verbose-helpful report of the
>>> "units" rcParams entry. Sure enough, it is in rcsetup.py and in
>>> matplotlibrc.template, but a quick code scan turned up no evidence
>>> that it is used anywhere. Is it vestigial, and a candidate for surgical
>> removal?
>>
>> James, do you know what the units rc parameter was for, and can it be
>> removed?
>>
>> Darren
>>
>> ------------------------------------------------------------------------------
>> 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
>

Honestly, I do not know what the units rc param is for. Personally I try to stay away from anything rc parameter related.
I would guess that it was put in to handle default units, but the unit system handles defaults based on the type of data being plotted. Perhaps it was added in the first draft of the unit code and never removed when it was revised?
As far as I know, there is no need for it.
--James
> -----Original Message-----
> From: Darren Dale [mailto:dsd...@gm...]
> Sent: Tuesday, April 19, 2011 4:42 AM
> To: Eric Firing; jre...@ea...
> Cc: matplotlib development list
> Subject: Re: [matplotlib-devel] What is rcParams['units'] for?
> 
> On Tue, Apr 19, 2011 at 3:07 AM, Eric Firing <ef...@ha...> wrote:
> > While investigating the imshow problem reported today by Emanuale
> > Passera (a problem that seems to have been fixed, though I don't know
> > when or how), I stumbled across the verbose-helpful report of the
> > "units" rcParams entry. Sure enough, it is in rcsetup.py and in
> > matplotlibrc.template, but a quick code scan turned up no evidence
> > that it is used anywhere. Is it vestigial, and a candidate for surgical
> removal?
> 
> James, do you know what the units rc parameter was for, and can it be
> removed?
> 
> Darren
> 
> ------------------------------------------------------------------------------
> 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

On Tue, Apr 19, 2011 at 3:07 AM, Eric Firing <ef...@ha...> wrote:
> While investigating the imshow problem reported today by Emanuale
> Passera (a problem that seems to have been fixed, though I don't know
> when or how), I stumbled across the verbose-helpful report of the
> "units" rcParams entry. Sure enough, it is in rcsetup.py and in
> matplotlibrc.template, but a quick code scan turned up no evidence that
> it is used anywhere. Is it vestigial, and a candidate for surgical removal?
James, do you know what the units rc parameter was for, and can it be removed?
Darren

While investigating the imshow problem reported today by Emanuale 
Passera (a problem that seems to have been fixed, though I don't know 
when or how), I stumbled across the verbose-helpful report of the 
"units" rcParams entry. Sure enough, it is in rcsetup.py and in 
matplotlibrc.template, but a quick code scan turned up no evidence that 
it is used anywhere. Is it vestigial, and a candidate for surgical removal?
Eric

Hi Eric,
Thanks for the quick fix.
I can confirm it works for me (on windows with PyQt4.7).
The problem reported with TkAgg was possibly a mistake, as I am unable to 
reproduce it now...
Please consider the issue solved.
Re: Constrained zoom to x axis broken ?
by efiring Apr 17, 2011; 11:14pm :: Rate this Message: - Use ratings to 
moderate (?)
Reply | Print | View Threaded | Show Only this Message
On 04/17/2011 07:59 AM, Eric Firing wrote:
> On 04/16/2011 08:44 PM, butterw@... wrote:
>> > > http://matplotlib.sourceforge.net/users/navigation_toolbar.html
>> Constrained zoom to x axis (hold x key + left click zoom icon) is broken
>> for me with master.
>> Tested with TkAgg, Qt4Agg backend
>> features was working on mpl 1.0.0
> It works for me with gtk and Tk, but not with qt4.
> Eric
... [show rest of quote]
https://github.com/matplotlib/matplotlib/pull/86
Above is a fix for qt4.
Eric
------------------------------------------------------------------------------

On 04/17/2011 07:59 AM, Eric Firing wrote:
> On 04/16/2011 08:44 PM, bu...@gm... wrote:
>> > > http://matplotlib.sourceforge.net/users/navigation_toolbar.html
>> Constrained zoom to x axis (hold x key + left click zoom icon) is broken
>> for me with master.
>>
>> Tested with TkAgg, Qt4Agg backend
>> features was working on mpl 1.0.0
>
> It works for me with gtk and Tk, but not with qt4.
>
> Eric
https://github.com/matplotlib/matplotlib/pull/86
Above is a fix for qt4.
Eric

On 04/16/2011 08:44 PM, bu...@gm... wrote:
> > > http://matplotlib.sourceforge.net/users/navigation_toolbar.html
> Constrained zoom to x axis (hold x key + left click zoom icon) is broken
> for me with master.
>
> Tested with TkAgg, Qt4Agg backend
> features was working on mpl 1.0.0
It works for me with gtk and Tk, but not with qt4.
Eric

> > http://matplotlib.sourceforge.net/users/navigation_toolbar.html
Constrained zoom to x axis (hold x key + left click zoom icon) is broken 
for me with master.
Tested with TkAgg, Qt4Agg backend
features was working on mpl 1.0.0

> hist(range(10))
creates a list of rectangles in ax.patches.
With the current implementation, is it possible to modify (change the 
label, hide, delete or change the color) of a plotted histogram in a single 
command ? As currently there is no histogram object, it looks like you have 
to change each patch individually.
Would it make sense to implement the histogram plot object as a 
PatchCollection rather than a list of patches ?

On Fri, Apr 15, 2011 at 3:54 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> There might be a possible work-around, though. Maybe (and I am just
>> speculating here) if we can get the core part of matplotlib to specially
>> treat 3d collection objects in such a way that allows the collection to
>> return provide elements and z-order pairs. It is either that, or we finally
>> try to get OpenGL working again in matplotlib and allow ourselves to specify
>> coordinates in 3-D.
>>
>>
> It should be fairly easy to get a collections object to support multiple
> z-orders *within* the collection. Across artists, damn near impossible. I
> don't think you need to provide elements and z-order pairs per-se. The
> typical way a property is specified for a collection if you want it to vary
> over the elements of the collection is that the property is a sequence, and
> the property is accessed as prop[i%N] where i is the element number and N is
> the length of the property vector. So if we make zorder a len(elements)
> sequence of z-orders, we can order the collection by the zorder at draw
> time. Presumably external code would modify the zorder of the collection
> before each draw depending on the view.
>
Within a collection, this is already done correctly (or at least, as well as
one can except with a 2D rendering engine). It is when you have multiple
artists that exists over parts of the z-order "axis" that there are
problems. Essentially, if the 3-D bounding boxes overlap, then trouble
ensues.
Also, that speculation I had wouldn't work either, as the problem still
would exist for intersecting patches. No, what we really need is a 3D
rendering engine, and a logical separation between z-order for
sorting/layering and z-coordinates.
Ben Root

On Fri, Apr 15, 2011 at 3:42 PM, Benjamin Root <ben...@ou...> wrote:
>
> There might be a possible work-around, though. Maybe (and I am just
> speculating here) if we can get the core part of matplotlib to specially
> treat 3d collection objects in such a way that allows the collection to
> return provide elements and z-order pairs. It is either that, or we finally
> try to get OpenGL working again in matplotlib and allow ourselves to specify
> coordinates in 3-D.
>
>
It should be fairly easy to get a collections object to support multiple
z-orders *within* the collection. Across artists, damn near impossible. I
don't think you need to provide elements and z-order pairs per-se. The
typical way a property is specified for a collection if you want it to vary
over the elements of the collection is that the property is a sequence, and
the property is accessed as prop[i%N] where i is the element number and N is
the length of the property vector. So if we make zorder a len(elements)
sequence of z-orders, we can order the collection by the zorder at draw
time. Presumably external code would modify the zorder of the collection
before each draw depending on the view.

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,
Ok, I have examined the attached file, and I see what you have done. First,
the shading issue has long since been resolved and is in the development
branch (but probably won't be backported to v1.0.x because the changes were
extensive).
Second, the zorder sorting issue is a PITA to say the least. Your approach,
however, only pushes the problem down to smaller parts, and still doesn't
address the same problems with PatchCollection objects. That being said, I
would still be inclined to have the problem solved for surfaces and leave
patches to be buggy, except that this approach completely breaks the API.
plot_surface returns a Poly3DCollection object, not a list of
Poly3DCollection objects.
The Collections object is a double-edge sword. It allows for easy
manipulation of many artist objects, but ultimately the Collection object
must report a single z-order value to represent the z-order for plotting all
of the artist elements.
There might be a possible work-around, though. Maybe (and I am just
speculating here) if we can get the core part of matplotlib to specially
treat 3d collection objects in such a way that allows the collection to
return provide elements and z-order pairs. It is either that, or we finally
try to get OpenGL working again in matplotlib and allow ourselves to specify
coordinates in 3-D.
Ben Root

On Fri, Apr 15, 2011 at 9:27 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Benjamin Root <ben...@gm...> writes:
>
> > 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?
>
> Since v1.0.x is supposed to be merged into master frequently, your
> change would propagate into master. To prevent it:
>
> 1. make sure v1.0.x is merged into master (usually it is, but
> if not, start by doing that merge)
> 2. merge your change to v1.0.x
> 3. merge v1.0.x to master with
>
> git checkout master
> git merge --strategy=ours v1.0.x
>
> This means that (1) the merge commit on top of v1.0.x will be in
> master's history, so it will not be merged again; (2) the merge is done
> by selecting the version of each file that is already in master, so the
> contents of master do not change.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
Ok, thanks, I did that, and everything looks ok. I pushed the fixes up.
Hopefully, the next merge doesn't screw things up.
Ben

Benjamin Root <ben...@gm...> writes:
> 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?
Since v1.0.x is supposed to be merged into master frequently, your
change would propagate into master. To prevent it:
1. make sure v1.0.x is merged into master (usually it is, but
 if not, start by doing that merge)
2. merge your change to v1.0.x
3. merge v1.0.x to master with
 git checkout master
 git merge --strategy=ours v1.0.x
This means that (1) the merge commit on top of v1.0.x will be in
master's history, so it will not be merged again; (2) the merge is done
by selecting the version of each file that is already in master, so the
contents of master do not change.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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