matplotlib-devel Mailing List for matplotlib

On Sat, Jul 19, 2008 at 01:25:51AM +0200, Gael Varoquaux wrote:
> Am I wrong, or does matploib not build with current numpy svn?

OK, Fernando told me that matplotlib builds fine with latest numpy on his
box so Ienquired a bit more. The problem is that the build of matplotlib
tries to include a header file that is generated automatically during the
build of numpy (__multiarray_api.h). If you install numpy using "python
setup.py install", this header file is inlcuded in the install. However I
used "python setupegg.py develop" to install numpy. As a result the
header file does not get put in the include directory. I guess this is
thus a bug in the setupegg.py of numpy, but my knowledge of setuptools is
way to low to be able to fix that.

Cheers,

Gaël

Hi,

Am I wrong, or does matploib not build with current numpy svn?

Here is the error message I am getting:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC
-I/home/varoquau/dev/numpy/trunk/numpy/core/include
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
-I/usr/include/python2.5 -c src/ft2font.cpp -o
build/temp.linux-i686-2.5/src/ft2font.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
In file included from
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/arrayobject.h:14,
                 from src/ft2font.cpp:6:
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:17:25:
error: numpyconfig.h: No such file or directory
/home/varoquau/dev/numpy/trunk/numpy/core/include/numpy/ndarrayobject.h:1829:30:
error: __multiarray_api.h: No such file or directory
src/ft2font.cpp: In member function ‘Py::Object
FT2Image::py_as_array(const Py::Tuple&)’:
src/ft2font.cpp:273: error: ‘PyArray_Type’ was not declared in this scope
src/ft2font.cpp:273: error: ‘PyArray_New’ was not declared in this scope
src/ft2font.cpp: In function ‘void initft2font()’:
src/ft2font.cpp:1877: error: ‘import_array’ was not declared in this
scope
error: command 'gcc' failed with exit status 1

If you look at the numpy/core/include/numpy/ndarrayobject.h file, it says
clearly at the top of the file "do not include this file directly".

Gaël

On Fri, Jul 18, 2008 at 4:17 PM, Andrew Straw <str...@as...> wrote:

> Yes, good idea. (In fact I wonder why numpy doesn't have minmax.)

I've often wondered this myself...

Cheers,

f

Eric Firing wrote:
> John Hunter wrote:
>> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <str...@as...>
>> wrote:
>>
>>> If you're happy with that extra cost, I'll modify
>>> axes.delete_masked_points() so that hexbin and scatter are automatically
>>> filtered in this way. Given the speed complaints we sometimes get, I was
>>> hesitant to add another pass through the data.
> 
> masks.extend([~np.isfinite(x) for x in args])
> 
> may be the quickest and most general way to do it.  I believe
> ~np.isfinite is both more general and significantly faster than np.isnan.

Clever, but it won't work as-is. np.isfinite('b') returns a
NotImplementedType, and a default argument to scatter is c='b', which
gets passed to this function. Anyhow, I implemented your idea with a
check for NotImplementedType and some unit tests in r5791.

> A kwarg could be used to enable or disable this checking.

Yes, but since we're grabbing *args, that would mean parsing **kwargs --
so I just implemented it without the option of disabling it. I'm happy
to add this if desired.

>> Happy is the wrong word -- we certainly should make these things as
>> efficient as reasonable so if your optimization worked it would be
>> preferable   numpy passes are rarely the bottleneck but they are good
>> to be aware of.  We could provide some helper function in nxutils to
>> do more stuff in a single pass for common use cases (eg a minmax
>> function to get both the min and the max...)

Yes, good idea. (In fact I wonder why numpy doesn't have minmax.) And
apologies for suggesting that you might be "happy" with a (minor)
slowdown -- not the best choice of words.

-Andrew

John Hunter wrote:
> On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <str...@as...> wrote:
> 
>> If you're happy with that extra cost, I'll modify
>> axes.delete_masked_points() so that hexbin and scatter are automatically
>> filtered in this way. Given the speed complaints we sometimes get, I was
>> hesitant to add another pass through the data.

masks.extend([~np.isfinite(x) for x in args])

may be the quickest and most general way to do it.  I believe 
~np.isfinite is both more general and significantly faster than np.isnan.

A kwarg could be used to enable or disable this checking.

Eric


> 
> Happy is the wrong word -- we certainly should make these things as
> efficient as reasonable so if your optimization worked it would be
> preferable   numpy passes are rarely the bottleneck but they are good
> to be aware of.  We could provide some helper function in nxutils to
> do more stuff in a single pass for common use cases (eg a minmax
> function to get both the min and the max...)
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Jul 18, 2008 at 4:42 PM, Andrew Straw <str...@as...> wrote:

> If you're happy with that extra cost, I'll modify
> axes.delete_masked_points() so that hexbin and scatter are automatically
> filtered in this way. Given the speed complaints we sometimes get, I was
> hesitant to add another pass through the data.

Happy is the wrong word -- we certainly should make these things as
efficient as reasonable so if your optimization worked it would be
preferable   numpy passes are rarely the bottleneck but they are good
to be aware of.  We could provide some helper function in nxutils to
do more stuff in a single pass for common use cases (eg a minmax
function to get both the min and the max...)

John Hunter wrote:
> On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <str...@as...> wrote:
>   
>> I just spent a little time getting hexbin to discard nans without
>> failing in mysterious ways.
>>
>> I'm sending 2 patches: one will detect nans and raise a suitable
>> exception. The other will automatically drop the nans and continue with
>> hexbin. The 2nd seems a little nicer in functionality, but the code is a
>> little more convoluted and hence more brittle, and so I'm torn as to
>> which I'd prefer. (The problem with just detecting nans from the
>> beginning is that it would cause an extra pass through the data in all
>> cases.)
>>     
>
> I think the nans should be dropped with no raise or warning, which is
> consistent with our handling elsewhere. I don't think your approach,
> which if I am reading this correctly assumes that is x or y has nans
> then the min or max will be nan, is correct.  Eg,
>
>   In [51]: x = np.random.rand(10)
>
>   In [52]: x[4] = np.nan
>
>   In [53]: x.min()
>   Out[53]: 0.37072898459621617
>
>   In [54]: x.max()
>   Out[54]: 0.79367039009185769
>
>
> I think min and max in the presence of nans is undefined.
True -- that slipped past me, since in my use case the nans were always
coming out for both min and max...
>   But you can
> just pay for the extra pass
>
> mask = np.isnan(x) & np.isnan(y)
> if mask.any():
>      # mask where
If you're happy with that extra cost, I'll modify
axes.delete_masked_points() so that hexbin and scatter are automatically
filtered in this way. Given the speed complaints we sometimes get, I was
hesitant to add another pass through the data.

-Andrew

On Fri, Jul 18, 2008 at 2:49 PM, Andrew Straw <str...@as...> wrote:
> I just spent a little time getting hexbin to discard nans without
> failing in mysterious ways.
>
> I'm sending 2 patches: one will detect nans and raise a suitable
> exception. The other will automatically drop the nans and continue with
> hexbin. The 2nd seems a little nicer in functionality, but the code is a
> little more convoluted and hence more brittle, and so I'm torn as to
> which I'd prefer. (The problem with just detecting nans from the
> beginning is that it would cause an extra pass through the data in all
> cases.)

I think the nans should be dropped with no raise or warning, which is
consistent with our handling elsewhere. I don't think your approach,
which if I am reading this correctly assumes that is x or y has nans
then the min or max will be nan, is correct.  Eg,

  In [51]: x = np.random.rand(10)

  In [52]: x[4] = np.nan

  In [53]: x.min()
  Out[53]: 0.37072898459621617

  In [54]: x.max()
  Out[54]: 0.79367039009185769


I think min and max in the presence of nans is undefined.  But you can
just pay for the extra pass

mask = np.isnan(x) & np.isnan(y)
if mask.any():
     # mask where

JDH

On Fri, Jul 18, 2008 at 07:57:25PM +0200, Gael Varoquaux wrote:
> OK, now what is the way forward. We need to provide the advanced-user for
> a good control on the backend. We need to provide a way that simply works
> without changing anything. The same code should run in "ipython -pylab",
> idle, or SPE. I think this means we need to add an rc entry. We could
> have two entries for backends:

> backend: auto or any of the current existing
> backend-default: any of the current existing

> If backend is set to auto, pyplot would check if an event loop is running
> and select the appriopriate backend. If no eventloop is running, it would
> use the backend specified in backend-default.

> This should work fairly nicely. The only think I am worried about is
> people changing the backend using matlplotlib.use, while rc['backend'] is
> still at auto, and then importing pyplot, which would change again the
> backend. Any suggestion for how to address that? Maybe matploib.use could
> put a flag somewhere, saying that it has been explicitely called.
> Internallythe plyplot magic to choose the backend would not set this
> flag.

I talk to Fernando about this, and he came up with a suggestion I like
quite a lot. The idea would be to give an "backend_fallback" boolean in
the rc parameters. When loading an interactive backend, if this boolean
is set to true (by default), the backend-loading code would check that
the proposed interactive backend is complatible with the current running
mainloop, and if not walk the different backends to find a suitable one,
without shooting a warning at the user, because the user should not have
to know about this.

I think this is a good way of satisfying both the requirement for
seemless operation in different event loops and the requirement for
advanced users that can control completely how things happen using the rc
parameter switch. Moreover, if there is not risk of conflict, the
rc-specified choice would be kept.

What do you think? Where should I insert this code?

Cheers,

Gaël

On Fri, Jul 18, 2008 at 3:00 PM, Andrew Straw <str...@as...> wrote:
> It appears the current svn trunk has a problem in that gtk.main() in
> backend_gtk.py line 71 never returns, even after all windows have been
> closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the
> window. This does not happen with WXAgg or TkAgg.

Arg, while trying to debug another problem I commented out a relevant
line and forgot to uncomment.  Should be fixed in 5790.  Thanks for
the report.

JDH

John Hunter wrote:
> 
> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.

It's at the top of my list ATM.  I've let this afternoon get away from 
me, but I have literally *nothing* to do tomorrow and Sunday, so expect 
a patch this weekend.  (Let's hope I haven't jinxed myself here.)

Ryan

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

It appears the current svn trunk has a problem in that gtk.main() in
backend_gtk.py line 71 never returns, even after all windows have been
closed. To reproduce, run "python simple_plot.py -dGTKAgg" and close the
window. This does not happen with WXAgg or TkAgg.

-Andrew

I just spent a little time getting hexbin to discard nans without
failing in mysterious ways.

I'm sending 2 patches: one will detect nans and raise a suitable
exception. The other will automatically drop the nans and continue with
hexbin. The 2nd seems a little nicer in functionality, but the code is a
little more convoluted and hence more brittle, and so I'm torn as to
which I'd prefer. (The problem with just detecting nans from the
beginning is that it would cause an extra pass through the data in all
cases.)

Anyhow, I've attached them both here for discussion. I'm happy to check
one of these in myself or feel free to do it.

-Andrew

On Fri, Jul 18, 2008 at 09:17:02PM +0200, David M. Kaplan wrote:
> For ginput, there are a number of ways that an impartial list could be
> returned and this is often a desired outcome (for example, I often
> decide after the fact that I want fewer points than I initially
> thought).

Can't you use ginput(0) for these cases?  

It doesn't work on Mac with no middle mouse button to terminate the 
sequence, but that is a separate issue.

>  Perhaps as a compromise we could set the default timeout to
> -1 so the user needs to actually choose a timeout (presumably indicating
> he/she accepts the consequences).  But allowing the user to manually
> decide to select fewer points using the second mouse button has proved
> quite useful to me and the user would still need to test in this case.
> We could warn if not enough points are returned, but an error seems too
> much to me. 

The cases I'm thinking about (e.g., select fit range) have a specific 
number of points.  Other cases (e.g., select shape outline) have an
indefinite number of points.  I can't think of case off hand where
I would want e.g., six or fewer points.

That said, I can always wrap the function in my own interface for my
scripts.

	- Paul

John Hunter wrote:
> On Thu, Jul 17, 2008 at 10:35 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Has anyone ever noticed weirdness with translucent polygons on win32
>> (using GTKAgg)?  I had the occasion to actually do something on windows
>> and noticed that, having drawn some polygons with alpha < 1, if I
>> resized the window or panned, the alpha channel seemed to disappear and
>> leave solid-colored polygons.
> 
> gtkagg on win32 is a very unusual combination -- one I used a lot in
> the day myself but it seems noone else did.  It is really hard to
> understand how something like this can happen from the way the code is
> written, but yes, if you can get any insight into it, we'd certainly
> like to understand and fix it.  I have at least one fairly significant
> piece of code that requires gtkagg on windows....
> 
> For starters, just posting the output of a script run with
> --verbose-helpful so we can get some version info for the archives
> will be useful.

Well what was real enough yesterday, today I can't reproduce.  Maybe it 
was just some windows weirdness.  I'll let you know if I see it again 
(but I'm not sure that I'll have any reason to be doing much on windows 
in the near future.)  Sorry for the noise.

Ryan

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

Hi,

On Fri, 2008-07-18 at 09:24 -0500, John Hunter wrote:
> On Fri, Jul 18, 2008 at 4:27 AM, David M. Kaplan <Dav...@ir...> wrote:

> I'm not a huge fan of mixins.  We use them occassionally, eg for
> FigureCanvasGtkAgg and their are some good uses for them, but they can
> quickly lead to overly complex code so should be avoided  where
> possible.  I find the "deeper hierarchy" approach more appealing here,
> but am not sure if it is viable.  For example
> 
>   class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg)
> 

Actually the case of GTKAgg is an interesting one.  I have
FigureCanvasGTK inherit the mixin, but this doesn't cascade to GTKAgg
because it gets overloaded with the non-user-interface versions from
FigureCanvasAgg leading calls to ginput to produce an error.  Adding the
mixin to the end of GTKAgg's inheritance list didn't work because it
seems that python decides that Agg has already overwritten the same
mixin included by GTK and ignores the mixin inheritance at the end of
the list (this surprised me, but it appears to work that way).  One
could always force it to use the right ones by adding functions that
point to the mixin versions, but this seems less elegant than
inheritance.

In this and similar cases, is the order of inheritance important?
Changing it to (FigureCanvasAgg, FigureCanvasGTK) should fix the
problem.  

> inherits from an interactive and a non-interactive backend, which is a
> good example of how quickly multiple mixin inheritance can get tricky.
>  I think perhaps it is best to create no new classes, put the base
> methods in the FigureCanvasBase, make the default behavior
> non-interactive, and then overrride them for the GUI backends.  Any
> problems with this?
> 

Well, yeah.  I think this would mean a lot of the same code in many
backends.  I also like the idea of a deeper hierarchy with a
FigureCanvasUserInterface class that inherits FigureCanvasBase but adds
functional start/stop_loop_events because it would allow for a simple
cbook test for a working user interface:
isinstance(mycanvas,FigureCanvasUserInterface)

A deeper hierarchy won't help the inheritance problem for GTKAgg though.

> Finally, the term "interactive" is a bit confusing and overloaded
> here, since "is_interactive" in mpl means someone is working from the
> interactive shell and we want to update the figure on every command
> (if draw_if_interactive).  For clarity, I think we should refer to
> this as a "user interface" backend or something like that,.  I know in
> parts of the backend code we have the designation of interactive
> backends, but these variables should probably be renamed to avoid
> further confusion, since the other use of interactive is already
> enshrined in the frontend api and rc file.
> 

I agree.

> JDH
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,

On Fri, 2008-07-18 at 11:52 -0400, Paul Kienzle wrote:
> If exceptions aren't used, then non-interactive backends should
> return []
> 

I think I have changed my mind on this one - an error seems more
appropriate.  The real-world use cases for this are (1) someone doesn't
realize they are in a non-user-interface backend and runs ginput and (2)
someone is running in the background a script that contains interactive
elements.  In both cases, using these functions is almost certainly an
error on the users side and it is impossible to decide what the user
would like to have returned in this case.  If the user really wants
potentially non-interactive run of the code, he could use try, except to
deal with that.

> The current code has another problem in that timeouts will return
> a partial list.  This could be handle by raising RuntimeError in
> ginput:
> 
>   class BlockingInput:
>     ...
>     def __call__(...):
>         ...
>         if n > 0 and len(self.clicks) < n:
>             raise RuntimeError("Timeout when selecting inputs")
>         return self.clicks
> 
> If you want to get fancy and return the partial list of clicks, 
> this can be done with our own exception class:
> 
>   --blocking_input.py--
>   class InputError(Exception):
>     def __init__(self, message, points):
>         self.message = message
>         self.points = points
>   class BlockingInput:
>     ...
>     def __call__(...):
>         ...
>         if n > 0 and len(self.clicks) < n:
>             raise InputError("Not enough inputs",self.clicks)
>         return self.clicks
> 
> Importing an extra symbol to catch the error would be ugly.  I 
> suggest hiding it in the functions that need it instead:
> 
>   --pyplot.py--
>   def ginput(*args, **kwargs):
>     ...
>   ginput.InputError = matplotlib.blocking_input.InputError
> 
> This allows the pylab user to write:
> 
>   try:
>     x = ginput(3,timeout=2)
>   except ginput.InputError,e:
>     print "ginput only returned %d inputs"%(len(e.points))
> 
> - Paul
> 

For ginput, there are a number of ways that an impartial list could be
returned and this is often a desired outcome (for example, I often
decide after the fact that I want fewer points than I initially
thought).  Perhaps as a compromise we could set the default timeout to
-1 so the user needs to actually choose a timeout (presumably indicating
he/she accepts the consequences).  But allowing the user to manually
decide to select fewer points using the second mouse button has proved
quite useful to me and the user would still need to test in this case.
We could warn if not enough points are returned, but an error seems too
much to me. 

Cheers,
David

-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Hi,

My bad - I forgot strings are iterable.  This should now be fixed.

Cheers,
David


On Fri, 2008-07-18 at 09:41 -0500, John Hunter wrote:
> On Fri, Jul 18, 2008 at 3:50 AM, David M. Kaplan <Dav...@ir...> wrote:
> 
> >> I would probably write a cbook method is_sequence_of_strings and just
> >> call that since it will be more readable and reusable...
> >>
> >
> > Method added to cbook.
> 
> This method will return true on a string, which is probably not what you want
> 
>   In [46]: is_sequence_of_strings('jdh was here')
>   Out[46]: True
> 
> My original example included an additional check on is_string_like(obj).
> 
> If you want to optionally support a string as a sequence of strings, I
> think we might need a kwarg to make this explicit.
> 
> JDH
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

John Hunter wrote:
> On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <js...@fa...> wrote:
>
>   
>> What do you think?  If it's OK I say we use the natgrid package in
>> matplotlib, since it's more bulletproof than the scikits package (it passes
>> Robert's degenerate triangulation test, and has been pounded on by user of
>> NCAR graphics since the 1980's).
>>     
>
> Great work!  I just contacted Jonathan with a similar query for
> Triangle, but am fully expecting a "no way" so very nice work on
> natgrid.  The licensing terms look fine to me.  Just drop the license
> in our licenses directory with some suitable name and fire away.  Also
> make sure the license is included in the module docstring so we comply
> with the "redistribution in binary form" clause.  In the unlikely
> event that Jonathan also comes back to us with a new license, we can
> decide then which is the better implementation.
>
> JDH
>   
John:  Well, I hit one snag.  One file in natgrid has this comment in it.

/*
 *  The code in this file is based on code written and
 *  copyrighted (C) by Dave Watson.  Dr. Watson retains the
 *  copyright to his original code.  Augmentations and changes
 *  to Dr. Watson's code are copyrighted (C) by UCAR, 1997.
 */

The NCAR folks have not been able to contact the fellow, and suspect he 
may have passed on.  I can't verify this though.  Do you see this as a 
problem?

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Fri, Jul 18, 2008 at 12:52 PM, Jeff Whitaker <js...@fa...> wrote:

> What do you think?  If it's OK I say we use the natgrid package in
> matplotlib, since it's more bulletproof than the scikits package (it passes
> Robert's degenerate triangulation test, and has been pounded on by user of
> NCAR graphics since the 1980's).

Great work!  I just contacted Jonathan with a similar query for
Triangle, but am fully expecting a "no way" so very nice work on
natgrid.  The licensing terms look fine to me.  Just drop the license
in our licenses directory with some suitable name and fire away.  Also
make sure the license is included in the module docstring so we comply
with the "redistribution in binary form" clause.  In the unlikely
event that Jonathan also comes back to us with a new license, we can
decide then which is the better implementation.

JDH

On Fri, Jul 18, 2008 at 10:14:00AM -0500, John Hunter wrote:
> Basically, you want to support users who are using ipython -wthread
> but not -pylab who later import pylab with a misconfigured rc.

That's ine way of putting it. You are considering the ipython, the way it
is currently implemented is the only entry point to interactiv use of
matplotlib. I think the is about to change significantly with the
introduction of GUI frontends to ipython, that are not inheritely bound
to pylab, like 'ipython -pylab' is. In fact Enthought has very short
terms plans to make an IDE.

>  Is this really desirable?  Certainly you would want to trap this or
>  warn or something so they don't get strange segfaults or other hard to
>  diagnose errors, but automagically switching the backend in mpl may be
>  too helpful in the way that microsoft windows is occassionally too
>  helpful.

You have a point. I agree that my approach is not the good one, and is
forcing too mcuh magic on the user. I will elaborate what might be a
better solution below.

> What about checking to see if your ipython module is in sys.modules
> when pyplot is imported, checking the backend, and then importing it,
> checking for wthread etc, issuing a severe warning with known
> misconfigurations, eg gtkagg, with instructions on how to fix is (eg
> "your matplotlibrc file is here and the backend needs to be set to
> such-and-such...")?

This is not about the wthread option. This is about embedding in a large
GUI, whether it be the IDE I was mentionning, or winpdb, or SPE, or
Mayavi. I don't think the current implementation is acceptable: you are
requiring the users to change the backend depending on the eventloop they
are running. Not only is this tedious, but it also require a fair amount
of technical knowledge and exposes details (kind of event loop) that are
irrelevent to the end user. Finally a lot of people will see the crash,
and simply conclude that matplotib, or the interactive program they are
runnning it from is buggy. We have had this come up more than once on the
enthought-dev mailing list, and I wonder how many people simply never ask.

OK, now what is the way forward. We need to provide the advanced-user for
a good control on the backend. We need to provide a way that simply works
without changing anything. The same code should run in "ipython -pylab",
idle, or SPE. I think this means we need to add an rc entry. We could
have two entries for backends:

backend: auto or any of the current existing
backend-default: any of the current existing

If backend is set to auto, pyplot would check if an event loop is running
and select the appriopriate backend. If no eventloop is running, it would
use the backend specified in backend-default.

This should work fairly nicely. The only think I am worried about is
people changing the backend using matlplotlib.use, while rc['backend'] is
still at auto, and then importing pyplot, which would change again the
backend. Any suggestion for how to address that? Maybe matploib.use could
put a flag somewhere, saying that it has been explicitely called.
Internallythe plyplot magic to choose the backend would not set this
flag.

Comments?

Gaël

Jeff Whitaker wrote:
> John Hunter wrote:
>   
>> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> wrote:
>>
>>   
>>     
>>> I'd like to see griddata functionality and Ryan May's wind barb patch in
>>> 0.98.3.
>>>     
>>>       
>> OK things seem to be moving pretty fast right now on several fronts,
>> so we may want to wait until mid next week before pushing anything
>> out.  Robert and I exchanged a few emails last night about his
>> delaunay code.  We have two choices on the dependency -- require an
>> external scikits.delaunay that the user will install, or ship it
>> *internally* in matplotlib, eg as matplotlib.delaunay (he is not too
>> keen to see us repeat the mistakes we made with enthought.traits
>> installing it ourselves externally).  I prefer the matplotlib.delaunay
>> solution since many win32, os x or naive users will not be comfortable
>> with the svn download and  source install.
>>
>> But Robert pointed out to me that one reason he has avoided pushing
>> this further, eg into scipy, is that there are known degenerate cases
>> arising from floating point precision issues that need to be worked
>> out
>>
>> He wrote:
>>
>>     My apologies, it does not segfault; it just returns an impossible
>> triangulation.
>>
>>        def test_slightly_degenerate(self):
>>            data = np.array([[-1, -1], [-1, 0], [-1, 1],
>>                [ 0, -1], [ 0, 0], [ 0, 1],
>>                [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1],
>>            ])
>>            tri = dlny.Triangulation(data[:,0], data[:,1])
>>
>>
>> I thought it possible that one of our developers may be interested in
>> working on this, and he gave the following advice:
>>
>>     Basically, Fortune's sweepline algorithm for Delaunay triangulation
>>     simply needs to be replaced with an algorithm that can be formulated
>>     using Jonathan Shewchuck's robust predicates:
>>
>>      http://www.cs.cmu.edu/~quake/robust.html
>>
>>     Divide and conquer or incremental insertion are reasonable candidates.
>> Personally, I am willing to include the code in its current imperfect
>> form in mpl with your griddata wrapper, provided that we make clear in
>> the docstring that there are known degenerate cases (eg include
>> Robert's example).  Caveat emptor: this is an oft requested piece of
>> code and I think many users would like to have something that works in
>> most cases.  But I think everyone would be well served by having a
>> bullet-proof algorithm and Robert won't have time to work on this in
>> the upcoming months, so perhaps one of us could spend some time
>> looking at following Robert's suggestion and  incorporating Jonathan
>> Shewchuck's robust predicates into the implementation.
>>   
>>     
>
> John:  I concur with your plan.  The triangulation algorithm used in the 
> natgrid package is quite bulletproof.  Unfortunately, it's GPL and I 
> haven't been able to get NCAR to change the license.  I checked 
> Shewchuk's web page and unfortunately his code comes with this license:
>
> These programs may be freely redistributed under the condition that the
> copyright notices (including the copy of this notice in the code comments
> and the copyright notice printed when the `-h' switch is selected) are
> not removed, and no compensation is received.  Private, research, and
> institutional use is free.  You may distribute modified versions of this
> code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT
> IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH
> SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND
> CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS.  Distribution of this code as
> part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT
> WITH THE AUTHOR.  (If you are not directly supplying this code to a
> customer, and you are instead telling them how they can obtain it for
> free, then you are not required to make any arrangement with me.)
>
> which is definitely not acceptable.  I'll start to research other 
> options ...
>   

John:  I just contacted NCAR again, and it seems that they have 
relicensed the software under an OSI-based license similar to the 
University of Illinois/NCSA:

Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:

    * Neither the names of NCAR's Computational and Information Systems
      Laboratory, the University Corporation for Atmospheric Research,
      nor the names of its contributors may be used to endorse or
      promote products derived from this Software without specific prior
      written permission.
    * Redistributions of source code must retain the above copyright
      notices, this list of conditions, and the disclaimer below.
    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions, and the disclaimer below in the
      documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 
IN NO EVENT SHALL THE CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR 
ANY CLAIM, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR 
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 
THE USE OR OTHER DEALINGS WITH THE SOFTWARE.

What do you think?  If it's OK I say we use the natgrid package in 
matplotlib, since it's more bulletproof than the scikits package (it 
passes Robert's degenerate triangulation test, and has been pounded on 
by user of NCAR graphics since the 1980's).

-Jeff


>   
>> So my advice is: let's fold the delaunay code into matplotlib.delaunay
>> for 0.98.3 while providing copious warnings in your griddata
>> interface, and get to work improving the algorithm for future
>> releases, making sure we send Robert patches to the scikit.delaunay
>> module if we manage to do anything useful so his implementation will
>> remain the official branch as long as he wants it to be.  If everyone
>> agrees with this plan, I'll assume you'll take the lead on importing
>> the code, and providing some examples/tests.
>>   
>>     
>
> OK.
>
> -Jeff
>   
>> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
>>
>> JDH
>>   
>>     
>
>
>   


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Fri, Jul 18, 2008 at 12:01, John Hunter <jd...@gm...> wrote:
> On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> wrote:
>
>> John:  I concur with your plan.  The triangulation algorithm used in the
>> natgrid package is quite bulletproof.  Unfortunately, it's GPL and I haven't
>> been able to get NCAR to change the license.  I checked Shewchuk's web page
>> and unfortunately his code comes with this license:
>
> Well there are two parts to his code.  His triangulation code license
> is clearly unacceptable, but we could send Fernando over to talk to
> him (since Fernando is now at Berkeley too) about considering a
> license change.  But his predicates code for orientation and incircle
> tests is in the public domain
> (http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c).
>  I think Robert was referring to incorporating these robust tests into
> his code rather than the actual triangle implementation, but perhaps
> he can clarify.

I meant that a Delaunay triangulation routine can be written using
these public domain robust predicates. The current sweepline algorithm
is not formulated to be able to use these predicates, so a different
algorithm has to be implemented rather than simply incorporating the
predicates into the current code.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco

On Fri, Jul 18, 2008 at 11:49 AM, Jeff Whitaker <js...@fa...> wrote:

> John:  I concur with your plan.  The triangulation algorithm used in the
> natgrid package is quite bulletproof.  Unfortunately, it's GPL and I haven't
> been able to get NCAR to change the license.  I checked Shewchuk's web page
> and unfortunately his code comes with this license:

Well there are two parts to his code.  His triangulation code license
is clearly unacceptable, but we could send Fernando over to talk to
him (since Fernando is now at Berkeley too) about considering a
license change.  But his predicates code for orientation and incircle
tests is in the public domain
(http://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c).
 I think Robert was referring to incorporating these robust tests into
his code rather than the actual triangle implementation, but perhaps
he can clarify.

JDH

John Hunter wrote:
> On Fri, Jul 18, 2008 at 10:11 AM, Jeff Whitaker <js...@fa...> wrote:
>
>   
>> I'd like to see griddata functionality and Ryan May's wind barb patch in
>> 0.98.3.
>>     
>
> OK things seem to be moving pretty fast right now on several fronts,
> so we may want to wait until mid next week before pushing anything
> out.  Robert and I exchanged a few emails last night about his
> delaunay code.  We have two choices on the dependency -- require an
> external scikits.delaunay that the user will install, or ship it
> *internally* in matplotlib, eg as matplotlib.delaunay (he is not too
> keen to see us repeat the mistakes we made with enthought.traits
> installing it ourselves externally).  I prefer the matplotlib.delaunay
> solution since many win32, os x or naive users will not be comfortable
> with the svn download and  source install.
>
> But Robert pointed out to me that one reason he has avoided pushing
> this further, eg into scipy, is that there are known degenerate cases
> arising from floating point precision issues that need to be worked
> out
>
> He wrote:
>
>     My apologies, it does not segfault; it just returns an impossible
> triangulation.
>
>        def test_slightly_degenerate(self):
>            data = np.array([[-1, -1], [-1, 0], [-1, 1],
>                [ 0, -1], [ 0, 0], [ 0, 1],
>                [ 1, -1 - np.finfo(np.float_).eps], [ 1, 0], [ 1, 1],
>            ])
>            tri = dlny.Triangulation(data[:,0], data[:,1])
>
>
> I thought it possible that one of our developers may be interested in
> working on this, and he gave the following advice:
>
>     Basically, Fortune's sweepline algorithm for Delaunay triangulation
>     simply needs to be replaced with an algorithm that can be formulated
>     using Jonathan Shewchuck's robust predicates:
>
>      http://www.cs.cmu.edu/~quake/robust.html
>
>     Divide and conquer or incremental insertion are reasonable candidates.
> Personally, I am willing to include the code in its current imperfect
> form in mpl with your griddata wrapper, provided that we make clear in
> the docstring that there are known degenerate cases (eg include
> Robert's example).  Caveat emptor: this is an oft requested piece of
> code and I think many users would like to have something that works in
> most cases.  But I think everyone would be well served by having a
> bullet-proof algorithm and Robert won't have time to work on this in
> the upcoming months, so perhaps one of us could spend some time
> looking at following Robert's suggestion and  incorporating Jonathan
> Shewchuck's robust predicates into the implementation.
>   

John:  I concur with your plan.  The triangulation algorithm used in the 
natgrid package is quite bulletproof.  Unfortunately, it's GPL and I 
haven't been able to get NCAR to change the license.  I checked 
Shewchuk's web page and unfortunately his code comes with this license:

These programs may be freely redistributed under the condition that the
copyright notices (including the copy of this notice in the code comments
and the copyright notice printed when the `-h' switch is selected) are
not removed, and no compensation is received.  Private, research, and
institutional use is free.  You may distribute modified versions of this
code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT
IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH
SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND
CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS.  Distribution of this code as
part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT
WITH THE AUTHOR.  (If you are not directly supplying this code to a
customer, and you are instead telling them how they can obtain it for
free, then you are not required to make any arrangement with me.)

which is definitely not acceptable.  I'll start to research other 
options ...

> So my advice is: let's fold the delaunay code into matplotlib.delaunay
> for 0.98.3 while providing copious warnings in your griddata
> interface, and get to work improving the algorithm for future
> releases, making sure we send Robert patches to the scikit.delaunay
> module if we manage to do anything useful so his implementation will
> remain the official branch as long as he wants it to be.  If everyone
> agrees with this plan, I'll assume you'll take the lead on importing
> the code, and providing some examples/tests.
>   

OK.

-Jeff
> And we can hold for Ryan's wind barbs too -- it looks like Eric is on the case.
>
> JDH
>   


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg