matplotlib-devel Mailing List for matplotlib

On Friday 16 November 2007 04:23:41 pm Rob Hetland wrote:
> __version__ = '3.0.0b1'
>
>
> So, no version, rather __version__.
This is fixed in svn.
< traits-2: no version report (that I can find)
traits-2: version.version
traits-3: version.__version__
traits-4: stay tuned :)
Darren

On Friday 16 November 2007 01:46:25 pm Rob Hetland wrote:
> On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> > Hi Rob,
> >
> > On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> >> Some recent changes (in the last few days) have caused my build to
> >> break. Three things:
> >>
> >> First of all, the line in setupext.py: if version.version.endswith
> >> ('mpl'):
> >> fails. I can comment this block out, and set the return of
> >> check_provide_traits(): to True, and things seem to work well.
> >
> > I'm surprised by that failure, but need some more information to
> > fix it. What
> > is the type and value of version.version on your machine? What
> > specifically
> > did you block out to make it work?
>
> The exact error is:
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
> configobj: matplotlib will provide
> Traceback (most recent call last):
> File "setup.py", line 234, in <module>
> if check_provide_traits(): build_traits(ext_modules, packages)
> File "/Users/rob/src/python/matplotlib/matplotlib/setupext.py",
> line 468, in check_provide_traits
> if version.version.endswith('mpl'):
> AttributeError: 'module' object has no attribute 'version'
>
> The problem is that my enthough.traits.version has no version attribute:
> >>> from enthought.traits import version
> >>> version.version
>
> ------------------------------------------------------------------------
> ---
> AttributeError Traceback (most recent call
> last)
>
> /Users/rob/<ipython console> in <module>()
>
> AttributeError: 'module' object has no attribute 'version'
Ok, it looks like I haven't covered all the possible variations in the traits 
API yet. What version of traits are you using? Would you send me a copy of 
your version.py file off list?
Thanks,
Darren

On Nov 16, 2007, at 6:10 PM, Darren Dale wrote:
> Hi Rob,
>
> On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
>> Some recent changes (in the last few days) have caused my build to
>> break. Three things:
>>
>> First of all, the line in setupext.py: if version.version.endswith
>> ('mpl'):
>> fails. I can comment this block out, and set the return of
>> check_provide_traits(): to True, and things seem to work well.
>
> I'm surprised by that failure, but need some more information to 
> fix it. What
> is the type and value of version.version on your machine? What 
> specifically
> did you block out to make it work?
>
The exact error is:
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: matplotlib will provide
Traceback (most recent call last):
 File "setup.py", line 234, in <module>
 if check_provide_traits(): build_traits(ext_modules, packages)
 File "/Users/rob/src/python/matplotlib/matplotlib/setupext.py", 
line 468, in check_provide_traits
 if version.version.endswith('mpl'):
AttributeError: 'module' object has no attribute 'version'
The problem is that my enthough.traits.version has no version attribute:
 >>> from enthought.traits import version
 >>> version.version
------------------------------------------------------------------------ 
---
AttributeError Traceback (most recent call 
last)
/Users/rob/<ipython console> in <module>()
AttributeError: 'module' object has no attribute 'version'
To make it work, I changed this:
def check_provide_traits():
 if options['provide_traits'] is True:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 try:
 from enthought import traits
 try:
 from enthought.traits import version
 except:
 print_status("enthought.traits", "unknown and 
incompatible version: < 2.0")
 return False
 else:
 if version.version.endswith('mpl'):
 print_status("enthought.traits", "matplotlib will 
provide")
 return True
 else:
 print_status("enthought.traits", version.version)
 return False
 except ImportError:
 if options['provide_traits']:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 else:
 print_status("enthought.traits", "no")
 return False
To this:
def check_provide_traits():
 if options['provide_traits'] is True:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 try:
 from enthought import traits
 try:
 from enthought.traits import version
 except:
 print_status("enthought.traits", "unknown and 
incompatible version: < 2.0")
 return False
 else:
 # if version.version.endswith('mpl'):
 # print_status("enthought.traits", "matplotlib will 
provide")
 # return True
 # else:
 # print_status("enthought.traits", version.version)
 # return False
 return True
 except ImportError:
 if options['provide_traits']:
 print_status("enthought.traits", "matplotlib will provide")
 return True
 else:
 print_status("enthought.traits", "no")
 return False
I'm not sure if this is the _really_ right thing to do, but it does 
compile fine after this change, and I assume the answer (True) is the 
right one.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Darren Dale wrote:
> I think nan's and inf's are a fact of life. They sometimes pop up in my work, 
> and would prefer that matplotlib handle them properly. But I haven't 
> contributed much to the actual plotting functions and don't know much about 
> the advantages of masked arrays, so I'll defer to you.
Darren,
I would like to return to this. It may make good sense for us to use 
something like x=ma.masked_where(~npy.isfinite(x), x) at the outermost 
level of argument processing, in place of x = ma.asarray(x). It will 
add a few msec, which is OK if it is done once or a few times per plot. 
 It is not good if it happens hundreds of times per plot, though, so it 
is acceptable only if there is a clear separation between outer argument 
processing--the most public part of the API--and internal functions.
The method suggested above actually won't work with numpy.ma--only with 
 maskedarray.
I have to put this off for a while longer.
Eric

Hi Rob,
On Friday 16 November 2007 11:14:50 am Rob Hetland wrote:
> Some recent changes (in the last few days) have caused my build to
> break. Three things:
>
> First of all, the line in setupext.py: if version.version.endswith
> ('mpl'):
> fails. I can comment this block out, and set the return of
> check_provide_traits(): to True, and things seem to work well.
I'm surprised by that failure, but need some more information to fix it. What 
is the type and value of version.version on your machine? What specifically 
did you block out to make it work?
Thanks,
Darren

Some recent changes (in the last few days) have caused my build to 
break. Three things:
First of all, the line in setupext.py: if version.version.endswith 
('mpl'):
fails. I can comment this block out, and set the return of 
check_provide_traits(): to True, and things seem to work well.
Second, I get this error:
2007年11月16日 16:53:25.881 Python[6935] *** _NSAutoreleaseNoPool(): 
Object 0x18081c10 of class NSCarbonWindowContentView autoreleased 
with no pool in place - just leaking
when plotting text to the screen. I am using mathtext with the Arev 
Sans fonts.
Third, keypress events seem to be broken.
I am using Mac OS 10.4 with the TkAgg backend.
I'm sorry that I'm only posting problems and not posting more fixes, 
but I don't have enough time right now to track these things down at 
the moment, and wanted to get the word out quickly. Perhaps if there 
are still issues next week, I can check into these issues a bit more 
deeply.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Thursday 15 November 2007 08:51:11 pm Eric Firing wrote:
> Darren Dale wrote:
> > On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
> >> ds...@us... wrote:
> >>> Revision: 4325
> >>>
> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> >>> Author: dsdale
> >>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
> >>>
> >>> Log Message:
> >>> -----------
> >>> added npy.seterr(invalid='ignore') to beginning of axes.py, to silence
> >>> repeated warnings created by finding extrema of arrays containing nans
> >>> (discovered during calls to errorbar)
> >>
> >> Darren,
> >>
> >> Is this hiding a problem that will pop up farther down the line?
> >
> > I don't know, this problem was pretty well hidden to begin with. I
> > consider it a bug that numpy doesnt gracefully handle finding the extrema
> > of an array that containing nans. Why should this warrant a warning?
>
> There are major differences of opinion, or differences of application,
> as to how nans and other floating point oddities should be handled. As
> a result, numpy was designed to allow the user to specify how floating
> point exceptions should be handled. Matlab-style handling of
> nans--which I have always found enormously useful in Matlab--imposes a
> significant computational cost, and neither the style nor the cost is
> acceptable to a substantial fraction of the numpy community. Therefore
> numpy supplies nanmax and nanmin for the case where you want to ignore
> nans, and amax and amin for the case where a nan means something is
> wrong and you don't want to ignore the nan. (There are also nanargmax,
> nanargmin, and nansum.)
>
> >> I think the strategy so far has been that inputs to plotting functions
> >> should use masked arrays, not nans, and correspondingly, the plotting
> >> functions should handle masked arrays gracefully. Although nans are
> >> used at some internal stages, I don't think they are handled correctly
> >> from end to end. We could add nan checks at the early argument
> >> processing stage, but it would slow things down a bit.
> >
> > Do you mean that matplotlib does not support input that contains nans?
> > Should the average user really have to care if they are passing input
> > with nans in it? I think not. I must have misunderstood.
>
> I think that nans "do the right thing" in some places but not others;
> they have never been explicitly supported in plot function input. The
> design decision was to use masked arrays, which are more general,
> instead. I have thought about a possible alternative, in which masked
> arrays would be immediately converted to nan-filled arrays, and nans
> would be fully used and supported internally as well as in the
> interface. I never came to the conclusion that this was a good idea,
> though, because masked arrays have some advantages. Therefore I have
> been trying to improve masked array use and support in mpl and in numpy.
I reverted my change this morning.
I think nan's and inf's are a fact of life. They sometimes pop up in my work, 
and would prefer that matplotlib handle them properly. But I haven't 
contributed much to the actual plotting functions and don't know much about 
the advantages of masked arrays, so I'll defer to you.
Darren

In any case, I think it's dangerous to set numpy's global error handling 
mode permanently. Is it feasible to do this on a need-to-protect basis 
by wrapping just the cases where this is needed with:
npy_orig_err = npy.seterr(invalid='ignore')
try:
 do_potentially_risky_stuff()
finally:
 npy.seterr(npy_orig_err)
Users might have code, for example, where ignoring this error will lead 
to bad consequences (including hard-to-find bugs).
-Andrew
Eric Firing wrote:
> ds...@us... wrote:
>> Revision: 4325
>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
>> Author: dsdale
>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
>>
>> Log Message:
>> -----------
>> added npy.seterr(invalid='ignore') to beginning of axes.py, to silence 
>> repeated warnings created by finding extrema of arrays containing nans
>> (discovered during calls to errorbar)
> 
> Darren,
> 
> Is this hiding a problem that will pop up farther down the line? I 
> think the strategy so far has been that inputs to plotting functions 
> should use masked arrays, not nans, and correspondingly, the plotting 
> functions should handle masked arrays gracefully. Although nans are 
> used at some internal stages, I don't think they are handled correctly 
> from end to end. We could add nan checks at the early argument 
> processing stage, but it would slow things down a bit.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Darren Dale wrote:
> On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
>> ds...@us... wrote:
>>> Revision: 4325
>>> 
>>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
>>> Author: dsdale
>>> Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
>>>
>>> Log Message:
>>> -----------
>>> added npy.seterr(invalid='ignore') to beginning of axes.py, to silence
>>> repeated warnings created by finding extrema of arrays containing nans
>>> (discovered during calls to errorbar)
>> Darren,
>>
>> Is this hiding a problem that will pop up farther down the line?
> 
> I don't know, this problem was pretty well hidden to begin with. I consider it 
> a bug that numpy doesnt gracefully handle finding the extrema of an array 
> that containing nans. Why should this warrant a warning?
There are major differences of opinion, or differences of application, 
as to how nans and other floating point oddities should be handled. As 
a result, numpy was designed to allow the user to specify how floating 
point exceptions should be handled. Matlab-style handling of 
nans--which I have always found enormously useful in Matlab--imposes a 
significant computational cost, and neither the style nor the cost is 
acceptable to a substantial fraction of the numpy community. Therefore 
numpy supplies nanmax and nanmin for the case where you want to ignore 
nans, and amax and amin for the case where a nan means something is 
wrong and you don't want to ignore the nan. (There are also nanargmax, 
nanargmin, and nansum.)
> 
>> I think the strategy so far has been that inputs to plotting functions
>> should use masked arrays, not nans, and correspondingly, the plotting
>> functions should handle masked arrays gracefully. Although nans are 
>> used at some internal stages, I don't think they are handled correctly
>> from end to end. We could add nan checks at the early argument
>> processing stage, but it would slow things down a bit.
> 
> Do you mean that matplotlib does not support input that contains nans? Should 
> the average user really have to care if they are passing input with nans in 
> it? I think not. I must have misunderstood.
> 
I think that nans "do the right thing" in some places but not others; 
they have never been explicitly supported in plot function input. The 
design decision was to use masked arrays, which are more general, 
instead. I have thought about a possible alternative, in which masked 
arrays would be immediately converted to nan-filled arrays, and nans 
would be fully used and supported internally as well as in the 
interface. I never came to the conclusion that this was a good idea, 
though, because masked arrays have some advantages. Therefore I have 
been trying to improve masked array use and support in mpl and in numpy.
Eric
> Darren

On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote:
> ds...@us... wrote:
> > Revision: 4325
> > 
> > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev
> > Author: dsdale
> > Date: 2007年11月15日 13:23:27 -0800 (2007年11月15日)
> >
> > Log Message:
> > -----------
> > added npy.seterr(invalid='ignore') to beginning of axes.py, to silence
> > repeated warnings created by finding extrema of arrays containing nans
> > (discovered during calls to errorbar)
>
> Darren,
>
> Is this hiding a problem that will pop up farther down the line?
I don't know, this problem was pretty well hidden to begin with. I consider it 
a bug that numpy doesnt gracefully handle finding the extrema of an array 
that containing nans. Why should this warrant a warning?
> I think the strategy so far has been that inputs to plotting functions
> should use masked arrays, not nans, and correspondingly, the plotting
> functions should handle masked arrays gracefully. Although nans are 
> used at some internal stages, I don't think they are handled correctly
> from end to end. We could add nan checks at the early argument
> processing stage, but it would slow things down a bit.
Do you mean that matplotlib does not support input that contains nans? Should 
the average user really have to care if they are passing input with nans in 
it? I think not. I must have misunderstood.
Darren