matplotlib-devel Mailing List for matplotlib

Hi,

I found a minor bug. Clicking with the pan and zoom tool on a plot with 
markers and the markevery option makes the markers disappear.

OS: Ubuntu
Matplotlib svn revision 6861
Backend: GTKAgg. Didn't test any others.

Example script:

------------------------------------------------
import matplotlib.pyplot as pl
import numpy as np

pl.plot(np.arange(100.0),np.arange(100.0),marker="+",markevery=5)
pl.show()
------------------------------------------------

Just left click with the pan and zoom tool, or otherwise use the pan and 
  zoom tool and the markers will disappear.

Regards,
João Silva

Note: Posted to matplotlib-devel and debian-science. 

Sandro, 
       Firstly, good luck with the book. 

The sort of book I'd buy would explain how to use the combination of
matplotlib/ipython/scipy/numpy to analyse data. 

> - what are you using matplotlib for?


I want to use matplotlib/ipython/numpy/scipy for analysis of
experimental data - plotting and fitting models to it. Also perhaps
simulation of the data. 

I have also wanted to use matplotlib to plot data as it was acquired -
see below.

I've not really used matplotlib in anger - but am likely to do so in
the future (and it would have been useful during my PhD had it been
around then).

> - what are the things you like the most of matplotlib, that you want
> to give emphasis to? And why?

Quality plots. The ability to add TeX labels. 

I've been keeping an eye on matplotlib for several years - it looks
good. I really must spend some time exploring it. 

> - what are the (basic) things that, when you were beginning to use
> matplotlib, you wanted to see grouped up but couldn't find?
> - what would you like to see in a book about matplotlib?

Start off by reading data from a file, plotting it and fitting a
function to that data.

Often, several scans are in the same data file. An elegant solution to
reading data something like this example would be useful.

# Scan: 1
# Time: 18:00
# Temperature: 21
# t data
1 12
2 33
3 14
4 40
5 60

# Scan: 2
# Time: 18:02
# Temperature: 30
# t data
1 22
2 33
3 44
4 55

And so on. 


Fitting a function to several data sets - with some of the parameters
fitted to both sets of data and some not would be useful.



> - what are some those advanced feature that made you yell "WOW!!" ?
> - what are the things you'd like to explore of matplotlib and never
> had time to do?

Plotting with related scales
----------------------------

Sometimes it is useful to plot related scales on x1 and x2 axes. I've
come across this several times in different contexts. In its simplest
form, there is a linear relationship between the axes. In a mechanical test, you might want extension on the x1 axis and strain on the x2 axis (for example). 

Sometimes there is not a linear relationship. For example you might
want to plot frequency (or photon energy) on x1 and wavelength on x2.

An even more complex example is a Hall-Petch plot:

(Yield Stress) = k/sqrt(Grain Size)

So plotting 1/Sqrt(Grain Size) on the X1 axis gives a linear
plot, but it would be useful to plot the grain size on the X2 scale. 


ipython and emacs
-----------------

Suppose I want to write a script to analyse some data (perhaps I want
a record of what I've done, or perhaps I'd like to perform the same
analysis on several data sets). I'd probably do so in emacs - but it
is useful to do some experimentation in ipython - tab completion is
particularly useful. I feel there must be a good way to do my
experimentation in ipython and save the important bits in emacs - but
I've not sat down and worked out an efficient way of doing this.


Data aqcuisition and experimental control:
-----------------------------------------

Writing a simple application to acquire data - ideally from multiple
sources and plot the data as it is acquired. In my case I wanted to
combine mechanical with electrical tests. A couple of interesting
articles by G Varoquaux are listed at
http://wiki.debian.org/DebianScience/DataAcquisition

This is perhaps beyond the scope of the book, but it has come up on
the mailing lists a couple of times. The ideal application would have
a gui for simple use, but a command line (probably ipython) for more
more complex use - perhaps performing a series of tests under
different conditions.


Some discussion of plotting non gridded 2d data should also be in
there.

> 
> Your suggestions are really appreciated :) And wish me good luck!

I don't think it is the thrust of your book, but another book I was
looking for is "A cookbook of Numerical simulations of classic
physics/engineering problems". For use by physicists/engineers who
don't want to rewrite things from scratch.

Good luck. 

Chris

On Fri, Jan 30, 2009 at 9:30 AM, Ondrej Certik <on...@ce...> wrote:

>> I *wish* matplotlib would replace their stupid deprecation warnings by
>> something that just updates the matplotlibrc file, and say makes a
>> copy of the old one.  Is there any way we could catch the warnings and
>> if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file,
>> then put a new matplotlibrc in place and print a message that this
>> just happened?  You could do that by making slightly patching
>> matplotlib as well.  I think matplotlib's behavior of emitting
>> warnings but doing nothing helpful to resolve them is just obnoxious.
>
> Maybe matplotlib developers would accept a patch fixing this.

To address this problem, we went to an all commented out rc file.
That way, when people change their mpl version, they don't get
deprecation warnings.  Only people who make specific changes to their
rc file will get deprecation warnings.  Those people will know what rc
is and how to change it.  I'm disinclined to overwrite files people
have changed -- they may be running multiple versions of mpl under
different scenarios, and each version would be competing with one
another to overwrite the file.  mpl has a general philospohy of not
trying to be too helpful -- we want to make it easy for users to
customize, we don't want to customize it for them.

The verbose deprecation warnings are in my opinion mostly a solved
problem: get a new rc file which is all commented out.  Just change
the things you want to change, and you will get very few warnings
going forward.  When you get them, fix the problem and you will get no
more warnings.

JDH

On Thu, Jan 29, 2009 at 5:49 PM, William Stein <ws...@gm...> wrote:
>
> On Wed, Jan 28, 2009 at 10:07 PM, Jason Grout
> <jas...@cr...> wrote:
>>
>> I just finished upgrading the matplotlib spkg to the newest version.
>> See http://trac.sagemath.org/sage_trac/ticket/4774
>>
>> This version of matplotlib deprecates some of the constructs found in
>> Sage's matplotlibrc (which is located in $SAGE_ROOT and automatically
>> copied to $DOT_SAGE if needed every time sage starts up).  The result is
>> a bunch of deprecation warnings every time Sage starts up (when
>> matplotlib loads Sage's matplotlibrc file).  In trying to figure out
>> what to do about this with several other developers, one option that
>> came up was just throwing away/ignoring the special Sage matplotlibrc
>> and using the normal, standard defaults for matplotlibrc (including the
>> standard location for a customized matplotlibrc).
>>
>> In investigating things more deeply, there were only a few real changes
>> we made to the default behavior of matplotlib.  IIRC, a few font choices
>> were reordered, legends were changed to display a bit more of the
>> function, and the dpi of saved images was bumped up from 80 dpi to 100
>> dpi (but this should be set when Sage saves an image anyway, so I don't
>> know that this changes anything).
>>
>> So here's a proposal: Should Sage stop distributing a custom
>> matplotlibrc, and ignore matplotlibrc files that already exist in the
>> $DOT_SAGE directories?
>>
>> Note that if people really want to customize the matplotlib settings,
>> they can always use the standard location for matplotlibrc (i.e.,
>> ~/.matplotlib/matplotlibrc, I think).  This will clean code out of the
>> bin repository and reduce startup time for sage as well.  Patches which
>> do this are posted to #4774.
>>
>> I vote yes, provided some sort of note is made in the release notes
>> about the ignored matplotlibrc file.
>
> I vote no, since I created the $DOT_SAGE/matplotlib directory
> *precisely* because of problems that happen if you were to do what you
> describe above.  For starters, people often also used a system-wide
> Python with their own version of matplotlib -- then end result was
> that if they tried to switch back and forth between sage and
> python/ipython/matplotlib, they would get tons of deprecation
> warnings, since the systemwide version of matplotlib is often
> different than the sage version.
>
> Second, how will what you suggest solve any problems?  All you do is
> move the problem from $DOT_SAGE/matplotlib/matplotlibc to
> $HOME/.matplotlibrc.  It's exactly the same problem.   You just
> temporarily put it off for a while.
>
> I *wish* matplotlib would replace their stupid deprecation warnings by
> something that just updates the matplotlibrc file, and say makes a
> copy of the old one.  Is there any way we could catch the warnings and
> if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file,
> then put a new matplotlibrc in place and print a message that this
> just happened?  You could do that by making slightly patching
> matplotlib as well.  I think matplotlib's behavior of emitting
> warnings but doing nothing helpful to resolve them is just obnoxious.

Maybe matplotlib developers would accept a patch fixing this.

Ondrej

On Thu, Jan 29, 2009 at 3:30 PM, Evans, James R
<jam...@jp...> wrote:
> Is there a reason why Axis.get_label returns the label as a Text instance, or should there really be set_label/get_label methods that takes a string and set the text value of the Text instance and returns the string value of the Text instance?
>
> Everywhere it is used in the code it is used in a two-step process to really just get and set the string value of the Text instance.

I don't think there is an easy answer to this one.  Many of the axis
getters return either artists or lists of artists, so I am
disinclined to change the behavior since it does what it is documented
to do and it is a minor inconvenience to have to "get_text".  The end
user might just as well want to set the font color, so returning the
text instance facilitates that.  What makes it trickier is that
"label" is overloaded here, as all artists have a label property (eg
the legend uses the label property for autolegending) which *is* a
simple string.  It's a bit more confusing still because the Axes
accessor methods *do* convert these labels to strings, eg
ax.get_xlabel and ax.get_xticklabels.

To solve the label property clash, a better name would probably be
"axislabel" or something like that, but I'm -0 on doing anything about
it since in practice noone is using the label property in this way
(though someone may want to down the road) .  If there is a compelling
use case for fixing it I'm amenable, but it looks more like a wart
that is worth keeping rather than breaking someone's code is a way
that may take them a while to figure out.

JDH

On Thu, Jan 29, 2009 at 3:24 PM, Nils Wagner
<nw...@ia...> wrote:

>>> I tried to build the HTML documentation.
>>> Here are some failures

Hi Nils, thanks for the report.  The doc build makes every example in
the examples directories.  Unfortunately, a few of these have gone
stale due to code rot, but we are aware of the ones you mentioned.  In
particular, they are in the mpl units dir, and we are trying to get
better about having an automated test harness.  In fact, the JPL is
almost finished with a preliminary unit testing framework for mpl to
catch these problems early, motivated by the units problems we have
had.

For you purposes though, the failures are mostly harmless, as it just
means a few examples won't build thumbnails in the gallery because
they are broken.

JDH

Is there a reason why Axis.get_label returns the label as a Text instance, or should there really be set_label/get_label methods that takes a string and set the text value of the Text instance and returns the string value of the Text instance?

Everywhere it is used in the code it is used in a two-step process to really just get and set the string value of the Text instance.

--James Evans

  

   --- the forwarded message follows ---

Comments below.

Nils Wagner wrote:
> Hi all,
>
> I tried to build the HTML documentation.
> Here are some failures
>
>
> matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py
> Traceback (most recent call last):
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>      runfile(fullpath)
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>      module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>    File "axes_divider.py", line 168
>       rs, as = s.get_size(renderer)
>            ^
>   SyntaxError: invalid syntax
>
>    warnings.warn(s)
> examples/pylab_examples/axes_grid 
> /home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py:190: 
> UserWarning: Exception running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_grid.py
> Traceback (most recent call last):
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>      runfile(fullpath)
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>      module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>    File "axes_grid.py", line 5, in <module>
>    File 
> "/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py", 
> line 168
>       rs, as = s.get_size(renderer)
>            ^
>   SyntaxError: invalid syntax
>   
I can't reproduce this here.  What version of matplotlib are you running?
>    warnings.warn(s)
>   Traceback (most recent call last):
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>      runfile(fullpath)
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>      module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>    File "geo_demo.py", line 9, in <module>
>    File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/pyplot.py", 
> line 636, in subplot
>      a = fig.add_subplot(*args, **kwargs)
>    File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/figure.py", 
> line 690, in add_subplot
>      a = subplot_class_factory(projection_class)(self, 
> *args, **kwargs)
>    File 
> "/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/axes.py", 
> line 7460, in __init__
>      self._axes_class.__init__(self, fig, self.figbox, 
> **kwargs)
>    File "custom_projection_example.py", line 35, in 
> __init__
> TypeError: expected string or Unicode object, NoneType 
> found
> oc/sphinxext/plot_directive.py:190: UserWarning: Exception 
> running plot 
> /home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/loadrec.py
> Traceback (most recent call last):
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 187, in makefig
>      runfile(fullpath)
>    File 
> "/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
> line 128, in runfile
>      module = imp.load_module("__main__", fd, fname, 
> ('py', 'r', imp.PY_SOURCE))
>    File "loadrec.py", line 14, in <module>
>    File 
> "/home/nwagner/local/lib64/python2.6/site-packages/mpl_toolkits/exceltools.py", 
> line 31, in <module>
>      raise ImportError('You must install xlwt or 
> pyExcelterator to use the exceltools')
> ImportError: You must install xlwt or pyExcelterator to 
> use the exceltools
>   
This is exactly as it says:

"You must install xlwt or pyExcelterator to 
use the exceltools"

Since that particular example uses the exceltools, and you haven't installed it's requirements, it can't generate the example.  Worst case, however, it should continue to generate the rest of the docs without it.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

The current matplotlib Mac binary installer unfortunately reintroduces 
an old problem: it does not work if the user has a 3rd party Tcl/Tk 
installed (as anyone who uses Tkinter seriously would have).

The solution is simple: if one is building a matplotlib Mac binary 
installer then please, please install ActiveState Tcl/Tk first 
(preferably the latest version of 8.4 -- which is 8.4.19 last I 
checked). The resulting binary will work with the built-in Tcl/Tk as 
well as any user's 3rd party Tcl/Tk.

Without this "fix", the resulting binary will abort with any attempt to 
produce a graph using TkAgg and a 3rd party Tcl/Tk.

ISo...could I request a new Mac binary with this fix in place? Or at 
least that future Mac binaries will be built this way?

-- Russell

P.S. the situation could get "interesting" with a future version of 
MacOS X during the transition from Tcl/Tk 8.4 to 8.5. But for now just 
sticking with 8.4 is safe since it is the recommended version for Python 
2.5 and is also what comes with MacOS X.

P.P.S. I suspect (but have not confirmed) that Mac Python 2.5.4 has this 
same problem. Mac Python 2.5.2 is definitely OK.

Hi all,

I tried to build the HTML documentation.
Here are some failures


matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py
Traceback (most recent call last):
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
     runfile(fullpath)
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
     module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
   File "axes_divider.py", line 168
      rs, as = s.get_size(renderer)
           ^
  SyntaxError: invalid syntax

   warnings.warn(s)
examples/pylab_examples/axes_grid 
/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py:190: 
UserWarning: Exception running plot 
/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_grid.py
Traceback (most recent call last):
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
     runfile(fullpath)
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
     module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
   File "axes_grid.py", line 5, in <module>
   File 
"/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/axes_divider.py", 
line 168
      rs, as = s.get_size(renderer)
           ^
  SyntaxError: invalid syntax

   warnings.warn(s)
  Traceback (most recent call last):
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
     runfile(fullpath)
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
     module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
   File "geo_demo.py", line 9, in <module>
   File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/pyplot.py", 
line 636, in subplot
     a = fig.add_subplot(*args, **kwargs)
   File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/figure.py", 
line 690, in add_subplot
     a = subplot_class_factory(projection_class)(self, 
*args, **kwargs)
   File 
"/home/nwagner/local/lib64/python2.6/site-packages/matplotlib/axes.py", 
line 7460, in __init__
     self._axes_class.__init__(self, fig, self.figbox, 
**kwargs)
   File "custom_projection_example.py", line 35, in 
__init__
TypeError: expected string or Unicode object, NoneType 
found
oc/sphinxext/plot_directive.py:190: UserWarning: Exception 
running plot 
/home/nwagner/svn/matplotlib/doc/mpl_examples/pylab_examples/loadrec.py
Traceback (most recent call last):
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 187, in makefig
     runfile(fullpath)
   File 
"/home/nwagner/svn/matplotlib/doc/sphinxext/plot_directive.py", 
line 128, in runfile
     module = imp.load_module("__main__", fd, fname, 
('py', 'r', imp.PY_SOURCE))
   File "loadrec.py", line 14, in <module>
   File 
"/home/nwagner/local/lib64/python2.6/site-packages/mpl_toolkits/exceltools.py", 
line 31, in <module>
     raise ImportError('You must install xlwt or 
pyExcelterator to use the exceltools')
ImportError: You must install xlwt or pyExcelterator to 
use the exceltools

Nils

On Thu, Jan 29, 2009 at 12:07 PM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> while reading the doc, I've encountered some little errors I've fixed
> in the attached patch; nothing extremely difficult, but still worth
> fixing :)
>
> I'm even wondering if the svnmerge section in "Coding guide" is still
> valid, since I've seen some emails passing here about that, but that's
> too hard for me (as of now) :) .

Thanks Sandro -- applied to the branch and trunk.  The merge docs are
up to date.

JDH

Hello,
while reading the doc, I've encountered some little errors I've fixed
in the attached patch; nothing extremely difficult, but still worth
fixing :)

I'm even wondering if the svnmerge section in "Coding guide" is still
valid, since I've seen some emails passing here about that, but that's
too hard for me (as of now) :) .

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Okay. Done.

--James

> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Wednesday, January 28, 2009 11:46 AM
> To: James Evans
> Cc: Eric Firing; matplotlib development list
> Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
> 
> On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jre...@ea...> wrote:
> > Eric,
> >
> > I was looking at it from the perspective of most of the other API calls throughout matplotlib have
> the Axes or Axis as the first
> > argument.  Typically this is because it is what wants the work to be done or is being worked on.  I
> was just following suit.  I can
> > see where you are coming from.  I have no real strong argument for or against, so if I should swap
> them around as you had suggested,
> > then I have no problem changing it.
> 
> I tend to agree with Eric -- then people writing converters who don't
> care about the axis input can ignore it more easily.
> 
> JDH

I just completed some open-heart surgery on the path simplification code 
to resolve this and other issues.  Though the integer overflow bug is on 
the maintenance branch, the proper solution was large enough and risky 
enough that I have only committed it to the development trunk.

Before, the path simplification code jumbled a number of discrete steps 
together in the code:

   1. Nan (nonfinite) handling
   2. Clipping
   3. Quantization
   4. Simplification


This has been rewritten (see path_converters.h) so each step is handled 
by a separate iterator class that can be independently switched on-and-off.

This refactoring made it much easier to rewrite the clipping algorithm 
to actually bisect line segments at the figure boundary, rather than (as 
before) simply removing vertices after crossing outside the boundary.

Additionally, nan-value-handling was formerly handled in both Python and 
C++, which was both double the maintenance and slower in Python.  Now, 
the C++ version of the entire pipeline has been exposed to Python, so we 
have a single (and faster) code path to debug.  (Note that whereas it 
behaves as an iterator in C++, it actually writes to a new array in the 
Python-wrapped version to avoid lots of tiny Python function calls).  
All backends now use this pipeline (through the use of 
Path.iter_segments). 

A side effect of this is that whereas before Python backends were forced 
to get clipping and simplification together, they now have independent 
control.  This fixes two long-standing bugs in non-Agg backends:

   1.   large values would cause integer overflow (causes the lines to
      appear to go in the wrong direction)
   2.   clipping should be turned off for filled regions, but that
      wasn't previously possible without also losing simplification


Lastly, the threshold of angular similarity below which simplification 
will start removing vertices has been exposed to the user as an rcParam 
(path.simplify_threshold).  It can also be set on an individual basis to 
any Path object.

The one remaining major piece is to get the native Cocoa backend to 
support this infrastructure.  Right now, it reimplements its own 
nan-handling and doesn't perform any of the other steps.  This will 
probably require some code compiled in C++ but exported as C to make it 
accessible to Objective-C.  The general roadmap is in "cleanup_path" in 
_path.cpp.  I'm happy to help with this, but without a Mac, it will be 
hard to compile and test these changes.

I've looked through all the backend_driver images, and everything seems 
ok, but let me know if you see any strangely drawn paths etc.

Cheers,
Mike



Michael Droettboom wrote:
> Okay -- I think I've at least narrowed it down to a cause.  Agg uses 
> fixed-point arithmetic to render at the low-level -- by default it uses 
> 24.8 (i.e. 24 integer bits and 8 fractional bits).  Therefore, it can 
> only handle pixel coordinates in the range -2^23 to 2^23.  Both of the 
> provided examples, after the data has been scaled, draw outside of this 
> range, which results in integer overflow, hence things going in the 
> wrong direction etc.
>
> We could change the fixed point in agg_basics.h, but I hesitate to do 
> so, as it's at the expense of fine detail.  We could possibly move to 
> 64-bits, but I'm not sure how easy that would be, or what the impact 
> might be on 32-bit platforms.
>
>     
> //----------------------------------------------------poly_subpixel_scale_e
>     // These constants determine the subpixel accuracy, to be more precise,
>     // the number of bits of the fractional part of the coordinates.
>     // The possible coordinate capacity in bits can be calculated by 
> formula:
>     // sizeof(int) * 8 - poly_subpixel_shift, i.e, for 32-bit integers and
>     // 8-bits fractional part the capacity is 24 bits.
>     enum poly_subpixel_scale_e
>     {
>         poly_subpixel_shift = 8,                      
> //----poly_subpixel_shift
>         poly_subpixel_scale = 1<<poly_subpixel_shift, 
> //----poly_subpixel_scale
>         poly_subpixel_mask  = poly_subpixel_scale-1,  
> //----poly_subpixel_mask
>     };
>
>
> One thing I will look into is whether the line simplification algorithm 
> can be extended to actually clip the lines when they go outside of the 
> image range.  At the moment, it does some work to reduce the number of 
> points outside of the image, but it always draws at least one point 
> outside at its original location.  It looks like Agg has some of the 
> pieces necessary to do this -- whether it's feasible to integrate that 
> into our existing line simplification algorithm remains to be seen.
>
> Mike
>
>
> Michael Droettboom wrote:
>   
>> Thanks for this.
>>
>> I believe both of these examples illustrate a shortcoming in Agg when 
>> the distance between two points on either end of a line is too great.
>>
>> I'll do some digging around and see what may be causing this and if any 
>> limits can be adjusted -- I may not get to this today, however.
>>
>> Mike
>>
>> João Luís Silva wrote:
>>   
>>     
>>> Jan Müller wrote:
>>>   
>>>     
>>>       
>>>> Hi,
>>>>
>>>> The simple code snippet at the end of this mail should plot a single line. 
>>>>
>>>>     
>>>>       
>>>>         
>>> I can confirm this bug on Ubuntu running matplotlib svn revision 6827. 
>>> However I think it doesn't have to do with the log-scale but with the 
>>> big variations on the x-scale and the custom xscale. I've reproduced a 
>>> similar behavior with the following script (pan and zoom to see the 
>>> buggy behavior).
>>> --------------------
>>>
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>>
>>> x = np.array([1.0,2.0,3.0,1.0E5,2.0E5])
>>> y = np.arange(len(x))
>>> plt.plot(x,y)
>>> plt.xlim(xmin=2,xmax=6)
>>> plt.show()
>>>
>>> --------------------
>>>
>>> Best Regards,
>>> João Silva
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>   
>>>     
>>>       
>>   
>>     
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Jan 28, 2009 at 3:16 PM, Drain, Theodore R
<the...@jp...> wrote:
> (nitpick mode on)
>
> Saying they can ignore it more easily seems like a bit of a stretch to me.  If you're writing a converter you MUST include the axis in the function signature since callers will be passing it in.  Whether or not you use it in the converter implementation is obviously dependent on the converter.  It's just as easy to not use the first argument in the list as it is the third.
>
> (nitpick mode off)
>
> Like James, I don't think the order is very important - but I do think it's important that the API not have a default value.  Calling code in the Axes or wherever else MUST pass that argument because some converters will need it.  The code at the upper layer should be independent of the type of converter that is being used.  If you include a default value, someone will write new Axes code that calls the converter without passing the axis which will be wrong in some cases (just probably not the case they test with).
>

I don't feel strongly about this at all, and any scenario proposed
here will work fine, but the interface

  convert(value, unit, axis=None)

to me emphasizes that the axis is optional for people writing
converters.  Eg we do this ticker.Formatter -- you get the position
passed in by the API, but most formatters don't care about it

    def __call__(self, x, pos=None):
        'Return the format for tick val x at position pos; pos=None
indicated unspecified'
        raise NotImplementedError('Derived must overide')


Yes, the signature must accept the kwarg, and the API will pass it in,
but it basically signals to the person writing a custom formatter what
the important and optional parts are.  Since you (the JPL) are
implementing the interface and are closest to it, I'll defer to your
judgement.

JDH

(nitpick mode on)

Saying they can ignore it more easily seems like a bit of a stretch to me.  If you're writing a converter you MUST include the axis in the function signature since callers will be passing it in.  Whether or not you use it in the converter implementation is obviously dependent on the converter.  It's just as easy to not use the first argument in the list as it is the third.

(nitpick mode off)

Like James, I don't think the order is very important - but I do think it's important that the API not have a default value.  Calling code in the Axes or wherever else MUST pass that argument because some converters will need it.  The code at the upper layer should be independent of the type of converter that is being used.  If you include a default value, someone will write new Axes code that calls the converter without passing the axis which will be wrong in some cases (just probably not the case they test with).

Ted

> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Wednesday, January 28, 2009 11:46 AM
> To: James Evans
> Cc: matplotlib development list; Eric Firing
> Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
>
> On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jre...@ea...>
> wrote:
> > Eric,
> >
> > I was looking at it from the perspective of most of the other API
> calls throughout matplotlib have the Axes or Axis as the first
> > argument.  Typically this is because it is what wants the work to be
> done or is being worked on.  I was just following suit.  I can
> > see where you are coming from.  I have no real strong argument for or
> against, so if I should swap them around as you had suggested,
> > then I have no problem changing it.
>
> I tend to agree with Eric -- then people writing converters who don't
> care about the axis input can ignore it more easily.
>
> JDH
>
> -----------------------------------------------------------------------
> -------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jre...@ea...> wrote:
> Eric,
>
> I was looking at it from the perspective of most of the other API calls throughout matplotlib have the Axes or Axis as the first
> argument.  Typically this is because it is what wants the work to be done or is being worked on.  I was just following suit.  I can
> see where you are coming from.  I have no real strong argument for or against, so if I should swap them around as you had suggested,
> then I have no problem changing it.

I tend to agree with Eric -- then people writing converters who don't
care about the axis input can ignore it more easily.

JDH

Eric,

I was looking at it from the perspective of most of the other API calls throughout matplotlib have the Axes or Axis as the first
argument.  Typically this is because it is what wants the work to be done or is being worked on.  I was just following suit.  I can
see where you are coming from.  I have no real strong argument for or against, so if I should swap them around as you had suggested,
then I have no problem changing it.

--James


> -----Original Message-----
> From: Eric Firing [mailto:ef...@ha...]
> Sent: Wednesday, January 28, 2009 10:48 AM
> To: James Evans
> Cc: 'matplotlib development list'
> Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
> 
> James Evans wrote:
> > All,
> >
> > I have just submitted an updated units.ConversionInterface.  For each of the static methods it now
> takes the invoking Axis instance
> > as a parameter.  I have updated the appropriate calling functions.  This allows the DateConverter to
> now guarantee that the default
> > axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime
> conversion error is now a lot more
> > difficult to invoke).  Additionally I have modified the DateConverter class to make use of any
> specified units, such that the
> > timezone is used for the units value.
> >
> 
> James,
> 
> I have not thought all this through, but a quick look at your changeset
> raises the question:
> 
> Why are you making such a complete change in the API?  In every
> instance, you are changing the method signature so that the new arg,
> "axis", is the first.  This seems particularly odd for the "convert"
> method--the new signature, convert(axis, value, unit), gives the
> arguments in what seems to be an unintuitive order.  Why not have
> something like convert(value, unit, axis=None), so that convert can be
> called without specifying an axis, and so that the argument order is
> still natural: "convert the value with unit, taking advantage of the
> axis if specified"?
> 
> Is there some compelling logic to having the "axis" argument now at the
> head of the list?
> 
> Eric
> 
> > --James Evans
> >
> > PS: I expect to be submitting a fully functioning test harness by the end of this week.
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

James Evans wrote:
> All,
> 
> I have just submitted an updated units.ConversionInterface.  For each of the static methods it now takes the invoking Axis instance
> as a parameter.  I have updated the appropriate calling functions.  This allows the DateConverter to now guarantee that the default
> axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime conversion error is now a lot more
> difficult to invoke).  Additionally I have modified the DateConverter class to make use of any specified units, such that the
> timezone is used for the units value.
> 

James,

I have not thought all this through, but a quick look at your changeset 
raises the question:

Why are you making such a complete change in the API?  In every 
instance, you are changing the method signature so that the new arg, 
"axis", is the first.  This seems particularly odd for the "convert" 
method--the new signature, convert(axis, value, unit), gives the 
arguments in what seems to be an unintuitive order.  Why not have 
something like convert(value, unit, axis=None), so that convert can be 
called without specifying an axis, and so that the argument order is 
still natural: "convert the value with unit, taking advantage of the 
axis if specified"?

Is there some compelling logic to having the "axis" argument now at the 
head of the list?

Eric

> --James Evans
> 
> PS: I expect to be submitting a fully functioning test harness by the end of this week.
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

All,

I have just submitted an updated units.ConversionInterface.  For each of the static methods it now takes the invoking Axis instance
as a parameter.  I have updated the appropriate calling functions.  This allows the DateConverter to now guarantee that the default
axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime conversion error is now a lot more
difficult to invoke).  Additionally I have modified the DateConverter class to make use of any specified units, such that the
timezone is used for the units value.

--James Evans

PS: I expect to be submitting a fully functioning test harness by the end of this week.

Ryan May wrote:
> John Hunter wrote:
>   
>> On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
>>     
>>> Hi,
>>>
>>> Do the online docs automatically update themselves from changes in SVN?  I
>>> thought there was a nightly cron.  I made some changes a few days ago (just a few
>>> typos) and they haven't shown up online yet.  The changes were to
>>> doc/users/shell.rst.  I'm assuming I should see the corresponding changes on
>>> http://matplotlib.sourceforge.net/users/shell.html.
>>>       
>> I had them in a cron and voluntarily disabled it.  I'm amenable to
>> re-enabling it.  The problem is that as examples become available in
>> svn, they automatically get pushed out to the gallery, but these may
>> not run on the latest released version.  I thought perhaps the site
>> should more closely track the latest released version, so the last few
>> times I've pushed the docs out, I did so from the branch.  So if you
>> want to see doc changes get pushed out sooner, you should patch the
>> branch and merge to the trunk.  I am in general a big fan of
>> encouraging people to use the svn snapshots as much as possible, and
>> updating the gallery and site docs nightly helps this because the new
>> features in the gallery entice them, but in the absence of nightly
>> builds and snapshots I don't think this is too helpful.
>>     
>
> Is there any way to merge changes done on the trunk onto the branch?  Or should I
> just do it manually?
>   
I could set up merging from trunk to branch, but I'd like to discourage 
that in general.  While we generally want all relevant changes merged 
from the branch to the trunk, that is not true in reverse (many things 
on the trunk are too risky to go to the branch).  So, you end up doing a 
lot of manual cherry-picking when going in that direction, making 
svnmerge less helpful anyway.

Generally, if I forget to do something on the branch, I just do an SVN 
diff of what I did to the trunk, use that to patch my working copy of 
the branch, and then commit the branch.

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Do the online docs automatically update themselves from changes in SVN?  I
>> thought there was a nightly cron.  I made some changes a few days ago (just a few
>> typos) and they haven't shown up online yet.  The changes were to
>> doc/users/shell.rst.  I'm assuming I should see the corresponding changes on
>> http://matplotlib.sourceforge.net/users/shell.html.
> 
> I had them in a cron and voluntarily disabled it.  I'm amenable to
> re-enabling it.  The problem is that as examples become available in
> svn, they automatically get pushed out to the gallery, but these may
> not run on the latest released version.  I thought perhaps the site
> should more closely track the latest released version, so the last few
> times I've pushed the docs out, I did so from the branch.  So if you
> want to see doc changes get pushed out sooner, you should patch the
> branch and merge to the trunk.  I am in general a big fan of
> encouraging people to use the svn snapshots as much as possible, and
> updating the gallery and site docs nightly helps this because the new
> features in the gallery entice them, but in the absence of nightly
> builds and snapshots I don't think this is too helpful.

Is there any way to merge changes done on the trunk onto the branch?  Or should I
just do it manually?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Do the online docs automatically update themselves from changes in SVN?  I
> thought there was a nightly cron.  I made some changes a few days ago (just a few
> typos) and they haven't shown up online yet.  The changes were to
> doc/users/shell.rst.  I'm assuming I should see the corresponding changes on
> http://matplotlib.sourceforge.net/users/shell.html.

I had them in a cron and voluntarily disabled it.  I'm amenable to
re-enabling it.  The problem is that as examples become available in
svn, they automatically get pushed out to the gallery, but these may
not run on the latest released version.  I thought perhaps the site
should more closely track the latest released version, so the last few
times I've pushed the docs out, I did so from the branch.  So if you
want to see doc changes get pushed out sooner, you should patch the
branch and merge to the trunk.  I am in general a big fan of
encouraging people to use the svn snapshots as much as possible, and
updating the gallery and site docs nightly helps this because the new
features in the gallery entice them, but in the absence of nightly
builds and snapshots I don't think this is too helpful.

JDH

Hi,

Do the online docs automatically update themselves from changes in SVN?  I
thought there was a nightly cron.  I made some changes a few days ago (just a few
typos) and they haven't shown up online yet.  The changes were to
doc/users/shell.rst.  I'm assuming I should see the corresponding changes on
http://matplotlib.sourceforge.net/users/shell.html.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma