Mike, Jan,
The thread
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg08342.html
culminated in changeset r6106, which seemed to fix the immediate problem, but in fact introduced a major bug: polar plotting was broken for lines or patches with angles crossing zero.
The real solution to the original problem is not a change to mpl, but to user code. In the example from the thread,
r = np.transpose(.1+np.arange ( 0 , 0.7 , 0.001))
theta = -4.5 * np.pi *r
freq = r*10e9
data = np.multiply(r,np.exp(1j*theta))
ax.plot(np.unwrap(angle(data)),abs(data)) # note added call to unwrap
the original problem was that the angle was jumping from near minus pi to near plus pi, and the solution is to use the unwrap function, or equivalent, to make the angle vary smoothly from start to finish, with no jumps.
Any attempt to normalize the angles to a fixed range of length 2 pi inside of mpl is sure to wreck valid user code; it merely moves the trouble spot to a different angle.
In 6731 I reverted the normalization change from 6106, and also improved the r-tick locations in cases where the actual r-data range is small.
Mike, of course I realized too late that I should have made the change in the maintenance branch and used svnmerge to propagate it to the trunk; should I just make the change manually in the branch?
Polar plotting could still use more work, but I doubt I will be able to do much any time soon.
Eric
Eric Firing wrote:
Mike, Jan,
Any attempt to normalize the angles to a fixed range of length 2 pi inside of mpl is sure to wreck valid user code; it merely moves the trouble spot to a different angle.
Thanks for catching this. Clearly that was a bone-headed fix on my part... 
In 6731 I reverted the normalization change from 6106, and also improved the r-tick locations in cases where the actual r-data range is small.
Mike, of course I realized too late that I should have made the change in the maintenance branch and used svnmerge to propagate it to the trunk; should I just make the change manually in the branch?
That should work fine. Then run "svnmerge merge ; svn commit" back on the trunk to mark it as merged.
Polar plotting could still use more work, but I doubt I will be able to do much any time soon.
Yeah -- there's lots of tricky side issues.
Cheers,
Mike
Michael Droettboom wrote:
Eric Firing wrote:
Mike, Jan,
Any attempt to normalize the angles to a fixed range of length 2 pi inside of mpl is sure to wreck valid user code; it merely moves the trouble spot to a different angle.
Thanks for catching this. Clearly that was a bone-headed fix on my part...
In 6731 I reverted the normalization change from 6106, and also improved the r-tick locations in cases where the actual r-data range is small.
Mike, of course I realized too late that I should have made the change in the maintenance branch and used svnmerge to propagate it to the trunk; should I just make the change manually in the branch?
That should work fine. Then run "svnmerge merge ; svn commit" back on the trunk to mark it as merged.
Mike,
The following is the result of svnmerge merge and svn status; I have not yet run svn commit because the status output suggests to me that things are getting merged that perhaps should not, since I don't know anything about them. Advice?
Eric
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S v0_98_5_maintproperty 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
--- Merging r6717 through r6732 into '.':
U lib/matplotlib/path.py
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svn status
M .
? svnmerge-commit-message.txt
? doc/build
? doc/examples
? doc/_static/inheritance0ca9968ee0.pdf
? doc/_static/inheritance1bda3e63b5.pdf
? doc/_static/inheritance829eaf436e.pdf
? doc/_static/inheritance47732b7b79.pdf
? doc/_static/inheritance0ca9968ee0.png
? doc/_static/inheritancecbc02086c0.pdf
? doc/_static/inheritance1bda3e63b5.png
? doc/_static/inheritance829eaf436e.png
? doc/_static/inheritance47732b7b79.png
? doc/_static/mathmpl
? doc/_static/inheritancecbc02086c0.png
? doc/_static/plot_directive
? doc/_static/examples
M doc/sphinxext/gen_gallery.py
M doc/sphinxext/gen_rst.py
M doc/pyplots/README
? lib/matplotlib/cbook0.py
? lib/matplotlib/colors0.py
? lib/matplotlib/transform.py
? lib/matplotlib/axes0.py
M lib/matplotlib/path.py
? examples/tests/ps
? examples/tests/agg
? examples/tests/svg
? examples/tests/pdf
? examples/tests/template
Eric Firing wrote:
Michael Droettboom wrote:
Eric Firing wrote:
Mike, Jan,
Any attempt to normalize the angles to a fixed range of length 2 pi inside of mpl is sure to wreck valid user code; it merely moves the trouble spot to a different angle.
Thanks for catching this. Clearly that was a bone-headed fix on my part...
In 6731 I reverted the normalization change from 6106, and also improved the r-tick locations in cases where the actual r-data range is small.
Mike, of course I realized too late that I should have made the change in the maintenance branch and used svnmerge to propagate it to the trunk; should I just make the change manually in the branch?
That should work fine. Then run "svnmerge merge ; svn commit" back on the trunk to mark it as merged.
Mike,
The following is the result of svnmerge merge and svn status; I have not yet run svn commit because the status output suggests to me that things are getting merged that perhaps should not, since I don't know anything about them. Advice?
Eric
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svnmerge merge -S v0_98_5_maintproperty 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
--- Merging r6717 through r6732 into '.':
U lib/matplotlib/path.py
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svn status
M .
? svnmerge-commit-message.txt
? doc/build
? doc/examples
? doc/_static/inheritance0ca9968ee0.pdf
? doc/_static/inheritance1bda3e63b5.pdf
? doc/_static/inheritance829eaf436e.pdf
? doc/_static/inheritance47732b7b79.pdf
? doc/_static/inheritance0ca9968ee0.png
? doc/_static/inheritancecbc02086c0.pdf
? doc/_static/inheritance1bda3e63b5.png
? doc/_static/inheritance829eaf436e.png
? doc/_static/inheritance47732b7b79.png
? doc/_static/mathmpl
? doc/_static/inheritancecbc02086c0.png
? doc/_static/plot_directive
? doc/_static/examples
M doc/sphinxext/gen_gallery.py
M doc/sphinxext/gen_rst.py
M doc/pyplots/README
? lib/matplotlib/cbook0.py
? lib/matplotlib/colors0.py
? lib/matplotlib/transform.py
? lib/matplotlib/axes0.py
M lib/matplotlib/path.py
? examples/tests/ps
? examples/tests/agg
? examples/tests/svg
? examples/tests/pdf
? examples/tests/template
These other modified files all look to be no-ops (they are property-only -- no diffs) -- probably the result of someone else manually backporting changes to the branch and not merging back to the trunk yet. All seemed harmless, so I went ahead and committed the merge.
Mike