matplotlib-devel Mailing List for matplotlib (Page 498)

     The way mpl uses the basemap toolkit will not work using
setuptools.  This is also an issue that twisted runs into.  Since
matplotlib will be put in one egg folder and basemap will be stuck in
another, trying to import matplotlib.toolkits.basemap will yield an
error.  Just something to think about for down the road, but its
probably not a priority now.

- Charlie

On 12/11/05, Andrew Straw <str...@as...> wrote:
> Hi All,
>
> I've added a hopefully innocuous few lines to matplotlib's setup.py:
>
> +
> +try:
> +    from setuptools import setup # use setuptools if possible
> +except ImportError:
> +    pass
> +
>
> This will use setuptools.setup() to install matplotlib if you have
> setuptools installed on your system.  I assume that if you have
> setuptools installed, you want to use it, hence the change. However, I
> thought this may potentially cause issues for folks, so I wanted to
> announce the change here.
>
> This change should have no effect for those without setuptools.  If you
> do have setuptools, it also means that the matplotlib data files are now
> placed in the resulting .egg. I've therefore also modified
> _get_data_path() in lib/matplotlib/__init__.py to support this change.
>
> For more information on setuptools, see
> http://peak.telecommunity.com/DevCenter/setuptools
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Charlie Moad wrote:

>FYI, built a bdist_wininst and it worked fine.
>
>
I just tested it too and it works for me with a non-setuptools install,
with a setuptools install, and with a non-setuptools install in which
setuptools was later installed.  I think it should be fine.

FYI, built a bdist_wininst and it worked fine.

On 12/12/05, Charlie Moad <cw...@gm...> wrote:
>      I just committed my changes.  The simplest approach would be to
> specify the matplotlib module package_data, but the current cvs layout
> doesn't tailor to that very well.  So I mimicked distutils install
> command to determine where matplotlib is installed.  The datapath is
> then defined as $platlib/matplotlib/mpl-data.
>      Why this change?  If you take a look at
> matplotlib._get_data_path() you will see.  This method has grown to
> probably 100 lines of code to check for various cases, e.g. py2exe,
> setuptools, embedding mpl, etc.  Now that the data is installed into
> the matplotlib module you could pretty much reduce to 1 line:
> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  This now
> handles all the cases mentioned above.  I left in the initial check
> for the MATPLOTLIBDATA env key to still allow for some flexibility.
>      I have tested on posix and w/wo setuptools.  I am going to check
> windows right now, but pretty sure it should work.  Please check this
> very carefully before next release as it is a pretty major change.
> Let me know if anyone encounters a problem.
>
> Thanks,
> - Charlie
>
> On 12/7/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> >     Charlie> Would it be considered cleaner to embed the mpl data into
> >     Charlie> the matplotlib module?  This would make it easier to
> >     Charlie> clean a mpl install.  The data path could be expressed
> >     Charlie> fairly easily too, as a one-liner:
> >
> >     Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
> >     Charlie> 'matplotlib-data'])
> >
> > Yes, if you can engineer in a way that works with setup w/ and w/o a
> > --prefix arg it would be preferable, in my view.
> >
> > JDH
> >
>

     I just committed my changes.  The simplest approach would be to
specify the matplotlib module package_data, but the current cvs layout
doesn't tailor to that very well.  So I mimicked distutils install
command to determine where matplotlib is installed.  The datapath is
then defined as $platlib/matplotlib/mpl-data.
     Why this change?  If you take a look at
matplotlib._get_data_path() you will see.  This method has grown to
probably 100 lines of code to check for various cases, e.g. py2exe,
setuptools, embedding mpl, etc.  Now that the data is installed into
the matplotlib module you could pretty much reduce to 1 line:
"os.sep.join([os.path.dirname(__file__), 'mpl-data'])".  This now
handles all the cases mentioned above.  I left in the initial check
for the MATPLOTLIBDATA env key to still allow for some flexibility.
     I have tested on posix and w/wo setuptools.  I am going to check
windows right now, but pretty sure it should work.  Please check this
very carefully before next release as it is a pretty major change.=20
Let me know if anyone encounters a problem.

Thanks,
- Charlie

On 12/7/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Would it be considered cleaner to embed the mpl data into
>     Charlie> the matplotlib module?  This would make it easier to
>     Charlie> clean a mpl install.  The data path could be expressed
>     Charlie> fairly easily too, as a one-liner:
>
>     Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
>     Charlie> 'matplotlib-data'])
>
> Yes, if you can engineer in a way that works with setup w/ and w/o a
> --prefix arg it would be preferable, in my view.
>
> JDH
>

Hi All,

I've added a hopefully innocuous few lines to matplotlib's setup.py:

+
+try:
+    from setuptools import setup # use setuptools if possible
+except ImportError:
+    pass
+

This will use setuptools.setup() to install matplotlib if you have
setuptools installed on your system.  I assume that if you have
setuptools installed, you want to use it, hence the change. However, I
thought this may potentially cause issues for folks, so I wanted to
announce the change here.

This change should have no effect for those without setuptools.  If you
do have setuptools, it also means that the matplotlib data files are now
placed in the resulting .egg. I've therefore also modified
_get_data_path() in lib/matplotlib/__init__.py to support this change.

For more information on setuptools, see
http://peak.telecommunity.com/DevCenter/setuptools

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> I've made a small alteration to my code for AFM mathtext
    Nicholas> to show digits and brackets () in the roman rather than
    Nicholas> the italic font, as is normal in mathtext.  The patch is
    Nicholas> attached.

Thanks Nicholas, changes in CVS.
JDH

>>>>> "Rob" == Rob McMullen <rob...@gm...> writes:

    Rob> Here's a small addition to the htdocs to include references
    Rob> to the new EMF backend.

Thanks Rob, I committed these to CVS and they'll show up on the web
next time I do a release and update the web site.

JDH

>>>>> "Philip" == Philip Austin <pa...@eo...> writes:

    Philip> Matlab has a useful contributed function called suptitle.m
    Philip> that puts a central title above a set of subplots:

    Philip> http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3233&objectType=file

    Philip> I'm planning to do a port for matplotlib, but wanted to
    Philip> check first to see if it's a solved problem -- best, Phil

I believe this is equivalent to something like 

fig.text(0.5, 0.9, 'some text')

where fig is a Figure instance.  See

  http://matplotlib.sf.net/matplotlib.figure.html#Figure-text

Exposing subtitle as a pylab function which wraps this functionality
is fine by me.

JDH




    Philip> -------------------------------------------------------
    Philip> This SF.net email is sponsored by: Splunk Inc. Do you grep
    Philip> through log files for problems?  Stop!  Download the new
    Philip> AJAX search engine that makes searching your log files as
    Philip> easy as surfing the web.  DOWNLOAD SPLUNK!
    Philip> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
    Philip> _______________________________________________
    Philip> Matplotlib-devel mailing list
    Philip> Mat...@li...
    Philip> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Matlab has a useful contributed function called suptitle.m that
puts a central title above a set of subplots:

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3233&objectType=file

I'm planning to do a port for matplotlib, but wanted to check first to see if
it's a solved problem -- best, Phil Austin

Here's a small addition to the htdocs to include references to the new
EMF backend.

Rob

Travis,

I was wrong--the problem (causing slow contour_demo with scipy) is that 
scipy is using min and max in ma.py where it should be using amin and 
amax.  A diff against svn is attached.

Eric

Travis,

I think the big problem is in numerix, not scipy.  The builtin min and 
scipy amin are getting confused, so that min is being called when amin 
should be; almost all the extra time is in calls to min and max.

I can't sort it out right now, but I may be able to get to it this 
evening--but maybe someone will beat me to it!

Once that numerix problem is fixed, I expect the timing difference 
between scipy and Numeric for the mpl demos will be small, and can be 
checked at leisure.

Eric

Travis Oliphant wrote:
> Eric Firing wrote:
> 
>> John,
>>
>> Something must not have gotten rebuilt when it should have; removing 
>> build and doing a complete rebuilt (with and without VERBOSE) solved 
>> the problem. So, --scipy is now working with svn version of scipy and 
>> cvs version of matplotlib--at least for the few demos I have tested so 
>> far.
>>
>> Speed is disappointing, though; contour_demo on my machine takes twice 
>> as long with scipy as with Numeric.
> 
> 
> We'll start looking at speed issues more closely soon.    There are 
> several optimizations planned already, but it would be nice to get some 
> real-world experience as to what is actually slow and what isn't.  Some 
> thing will always be slower, but I'd like to get rid of any obvious, and 
> unnecesary slow-downs.
> 
> Good benchmark data is very helpful for this exercise.  So, if you could 
> determine exactly what operations are slower in contour demo that would 
> be very helpful.
> One issue is that backward-compatibility is achieved by going throw 
> another layer of function calls.   This will always introduce something 
> of a slow-down.    I will continue to work to make things as fast as 
> they can be.   There were a lot of new features added and there has been 
> very-little time spent on optimization. 
> -Travis.
> 
> 
> 

I've made a small alteration to my code for AFM mathtext to show digits
and brackets () in the roman rather than the italic font, as is normal
in mathtext.  The patch is attached.

Nicholas

Alright, I'll give it a shot and let you know.

On 12/7/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Would it be considered cleaner to embed the mpl data into
>     Charlie> the matplotlib module?  This would make it easier to
>     Charlie> clean a mpl install.  The data path could be expressed
>     Charlie> fairly easily too, as a one-liner:
>
>     Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
>     Charlie> 'matplotlib-data'])
>
> Yes, if you can engineer in a way that works with setup w/ and w/o a
> --prefix arg it would be preferable, in my view.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Would it be considered cleaner to embed the mpl data into
    Charlie> the matplotlib module?  This would make it easier to
    Charlie> clean a mpl install.  The data path could be expressed
    Charlie> fairly easily too, as a one-liner:

    Charlie> os.sep.join([os.path.split(matplotlib.__file__)[0],
    Charlie> 'matplotlib-data'])

Yes, if you can engineer in a way that works with setup w/ and w/o a
--prefix arg it would be preferable, in my view.

JDH

Would it be considered cleaner to embed the mpl data into the
matplotlib module?  This would make it easier to clean a mpl install.=20
The data path could be expressed fairly easily too, as a one-liner:

os.sep.join([os.path.split(matplotlib.__file__)[0], 'matplotlib-data'])

Just a thought.....

- Charlie

John,

Something must not have gotten rebuilt when it should have; removing 
build and doing a complete rebuilt (with and without VERBOSE) solved the 
problem. So, --scipy is now working with svn version of scipy and cvs 
version of matplotlib--at least for the few demos I have tested so far.

Speed is disappointing, though; contour_demo on my machine takes twice 
as long with scipy as with Numeric.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, I found and fixed more missing bits of scipy support;
>     Eric> changes are in cvs.  With the svn version of scipy, though,
>     Eric> I have not yet been able to make everything work.  I am
>     Eric> getting segfaults.  It might be a simple typo somewhere.
> 
> You might try rm -rf build and then turn VERBOSE on in setup.py and
> rebuilding.  That might give you a good clue where the segfault is
> happening.  Do you see the crash in Agg and PS?
> 
> JDH

John,

examples/simple_plot.py worked with scipy, but contour_demo and 
image_demo segfaulted after some delay with no other indication as to 
where the problem is--no plots came up, so presumably the crash is in agg.

Unfortunately, I can't spend any more time on this until this evening, 
at the earliest.  Sorry to leave it hanging.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, I found and fixed more missing bits of scipy support;
>     Eric> changes are in cvs.  With the svn version of scipy, though,
>     Eric> I have not yet been able to make everything work.  I am
>     Eric> getting segfaults.  It might be a simple typo somewhere.
> 
> You might try rm -rf build and then turn VERBOSE on in setup.py and
> rebuilding.  That might give you a good clue where the segfault is
> happening.  Do you see the crash in Agg and PS?
> 
> JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, I found and fixed more missing bits of scipy support;
    Eric> changes are in cvs.  With the svn version of scipy, though,
    Eric> I have not yet been able to make everything work.  I am
    Eric> getting segfaults.  It might be a simple typo somewhere.

You might try rm -rf build and then turn VERBOSE on in setup.py and
rebuilding.  That might give you a good clue where the segfault is
happening.  Do you see the crash in Agg and PS?

JDH

John,

I found and fixed more missing bits of scipy support; changes are in 
cvs.  With the svn version of scipy, though, I have not yet been able to 
make everything work.  I am getting segfaults.  It might be a simple 
typo somewhere.

Eric

On Dec 2, 2005, at 3:43 PM, Eric Firing wrote:
> I don't understand the rationale for defining these functions, and in  
> particular the "resize" function that is causing problems.  It looks  
> to me like all three numeric packages include both resize functions  
> and resize methods, with the latter differing in that they work in  
> place and require contiguous arrays.  What your patch is doing is  
> removing access to the resize function, so there is no way to resize a  
> noncontiguous array.

I didn't realize such a function existed, and
was mostly following Travis' "list of necessary
changes" (in his book, Section 2.6.1). Of course
given that the right function exists from a top-
level import, that would be preferred over the
customization that I was doing.

I apologize if I gave the impression that the
patch was meant to be complete/correct/ideal.
It was mostly intended as a preliminary query
to see if there was any interest in pursuing
the specific backend numeric library approach,
since I had seen the discussion on a unified
build (which I didn't understand well enough
to implement.)

John Hunter wrote:
> A number of the symbols in numerix.mlab that Daishi originally defined
> were from various scipy (non-core) proper modules and I could not find
> these in the core.  Will scipy core not be providing the equivalent of
> MLab.py?

I did originally attempt to build vs. just
scipy_core, but failed for the same reason.
I was impatient to get things working for
my own purposes (scratching my own itch
and all that), so didn't put much effort
into pursuing this aspect further - but I
should have mentioned it in the original
message; sorry about that.

I'm happy to see that the patch was useful
enough to incorporate into the tree and
improved upon.

Eric Firing wrote:
> Here is another anomaly that I needed to work around:
>
> >>> bb = scipy.array([1.1,2,2,3.3])
> >>> 1.1 in bb
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: The truth value of an array with more than one element is  
> ambiguous. Use a.any() or a.all()
> >>> import numarray
> >>> nn = numarray.array([1.1,2.2,3.3])
> >>> 1.1 in nn
> True
>
> x in A behaves completely differently if A is a scipy ndarray than if  
> it is a numarray array.  This seems to me like a bug in scipy; the  
> num* behavior is certainly easier to use, in that it preserves the  
> list-like behavior when used in a list-like context.

I hit this also. Another behavioral difference
that pops up is:

---
In [3]: if scipy.arange(10) == None:
    ...:     pass
    ...:
------------------------------------------------------------------------ 
---
exceptions.ValueError                                Traceback (most  
recent call last)

/usr/local/python/python_2005-11-10/<ipython console>

ValueError: The truth value of an array with more than one element is  
ambiguous. Use a.any() or a.all()
In [4]:
---

versus:

---
In [7]: if Numeric.arange(10) == None:
    ...:     pass
    ...:
In [8]:
---

This was the reason for, e.g., this part of the patch:

Index: lib/matplotlib/contour.py
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/lib/matplotlib/contour.py,v
retrieving revision 1.16
diff -r1.16 contour.py
---
659c661
<         if linewidths == None:
---
 >         if linewidths is None:
---

(In this case I believe the new scipy approach
is less ambiguous and therefore better - the
intended semantics AFAICT in contour.py is for
'is', not '==' anyways.).

Thanks,
d

Eric Firing wrote:

I replied privately to Eric by mistake.

> John, Travis,
> 
> Now I find a genuine difference between scipy and num* that is causing a 
> problem:  for a masked array, say "A", A.mask is a property in scipy but 
> a function in num*.  I can work around it, but it seems like an anomaly 
> in scipy.  What it means is that in matplotlib we can't use A.mask or 
> A.mask(), but must instead use the ma.getmask() function.

Paul is the author of masked arrays.  He implemented the new behavior. 
I think mask as a property/attribute is right.

> 
> 
> Here is another anomaly that I needed to work around:
> 
>  >>> bb = scipy.array([1.1,2,2,3.3])
>  >>> 1.1 in bb
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ValueError: The truth value of an array with more than one element is 
> ambiguous. Use a.any() or a.all()
>  >>> import numarray
>  >>> nn = numarray.array([1.1,2.2,3.3])
>  >>> 1.1 in nn
> True

This is a bug in scipy core that has been fixed for several weeks.  It 
came about as an unintentional side-effect of raising an error for 
truth-testing of arrays.

Notice:


 >>> 1.1 in scipy.array([1.1,2.2,3.3])
True

-Travis

John, Travis,

Now I find a genuine difference between scipy and num* that is causing a 
problem:  for a masked array, say "A", A.mask is a property in scipy but 
a function in num*.  I can work around it, but it seems like an anomaly 
in scipy.  What it means is that in matplotlib we can't use A.mask or 
A.mask(), but must instead use the ma.getmask() function.


Here is another anomaly that I needed to work around:

 >>> bb = scipy.array([1.1,2,2,3.3])
 >>> 1.1 in bb
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()
 >>> import numarray
 >>> nn = numarray.array([1.1,2.2,3.3])
 >>> 1.1 in nn
True

x in A behaves completely differently if A is a scipy ndarray than if it 
is a numarray array.  This seems to me like a bug in scipy; the num* 
behavior is certainly easier to use, in that it preserves the list-like 
behavior when used in a list-like context.

In any case, I have committed changes to make contour work; but 
examples/masked_demo.py still doesn't work with scipy.  It generates no 
exception, but the plot is completely wrong.  I can't spend any more 
time on this right now.

Eric

John,

I committed fixes to several files; looks OK now, at least for 
examples/image_masked.py.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, It looks like you are referring to bugs in the
>     Eric> Colormap.__call__ method that were introduced when I added
>     Eric> support for masked values out-of-bounds values.  I have
>     Eric> committed a change that fixes the bugs I could find there
>     Eric> (as tested with examples/image_masked.py), so that the
>     Eric> colormap call produces exactly the same output with scipy as
>     Eric> with Numeric or numarray--the same rgba values.
>     Eric> Unfortunately, although that demo now runs with all three,
>     Eric> it produces different plots.  It appears that somewhere else
>     Eric> in the code--I'm pretty sure it is not within colors.py--the
>     Eric> floating point rgba values are getting rounded or, more
>     Eric> likely, truncated, when using scipy.
> 
> Hey Eric,
> 
> Thanks for taking a look at this.  The only other logical place for a
> problem to reside is in colors.normalize, since the pipleline is
> 
>   rgba = cmap(normalize(X))
> 
> The relevant bit of code is here -- if you or anyone else sees an
> obvious candidate that might cause this truncation, let me know....  
> 
> 
> class normalize:
>     def __init__(self, vmin=None, vmax=None, clip = True):
>         """
>         Normalize a given value to the 0-1 range
> 
>         If vmin or vmax is not given, they are taken from the input's
>         minimum and maximum value respectively.  If clip is True and
>         the given value falls outside the range, the returned value
>         will be 0 or 1, whichever is closer. Returns 0 if vmin==vmax.
>         Works with scalars or arrays, including masked arrays.  If clip
>         is True, masked values on input will be set to 1 on output; if
>         clip is False, the mask will be propagated to the output.
>         """
>         self.vmin = vmin
>         self.vmax = vmax
>         self.clip = clip
> 
>     def __call__(self, value):
> 
>         if isinstance(value, (int, float)):
>             vtype = 'scalar'
>             val = ma.array([value])
>         else:
>             vtype = 'array'
>             val = ma.asarray(value)
> 
>         self.autoscale(val)
>         vmin, vmax = self.vmin, self.vmax
>         if vmin > vmax:
>             raise ValueError("minvalue must be less than or equal to maxvalue")
>         elif vmin==vmax:
>             return 0.*value
>         else:
>             if self.clip:
>                 val = clip(val.filled(vmax), vmin, vmax)
>             result = (1.0/(vmax-vmin))*(val-vmin)
>         if vtype == 'scalar':
>             result = result[0]
>         return result
> 
>     def autoscale(self, A):
>         if not self.scaled():
>             if self.vmin is None: self.vmin = ma.minimum(A)
>             if self.vmax is None: self.vmax = ma.maximum(A)
> 
>     def scaled(self):
>         'return true if vmin and vmax set'
>         return (self.vmin is not None and self.vmax is not None)
> 
> 
> JDH

John,

The problem is that a bunch of scipy support is missing.  I think I have 
most of it fixed; I will do a little more, commit, and send another 
message in a few minutes.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, It looks like you are referring to bugs in the
>     Eric> Colormap.__call__ method that were introduced when I added
>     Eric> support for masked values out-of-bounds values.  I have
>     Eric> committed a change that fixes the bugs I could find there
>     Eric> (as tested with examples/image_masked.py), so that the
>     Eric> colormap call produces exactly the same output with scipy as
>     Eric> with Numeric or numarray--the same rgba values.
>     Eric> Unfortunately, although that demo now runs with all three,
>     Eric> it produces different plots.  It appears that somewhere else
>     Eric> in the code--I'm pretty sure it is not within colors.py--the
>     Eric> floating point rgba values are getting rounded or, more
>     Eric> likely, truncated, when using scipy.
> 
> Hey Eric,
> 
> Thanks for taking a look at this.  The only other logical place for a
> problem to reside is in colors.normalize, since the pipleline is
> 
>   rgba = cmap(normalize(X))

> 
> The relevant bit of code is here -- if you or anyone else sees an
> obvious candidate that might cause this truncation, let me know....  
> 
> 
> class normalize:
>     def __init__(self, vmin=None, vmax=None, clip = True):
>         """
>         Normalize a given value to the 0-1 range
> 
>         If vmin or vmax is not given, they are taken from the input's
>         minimum and maximum value respectively.  If clip is True and
>         the given value falls outside the range, the returned value
>         will be 0 or 1, whichever is closer. Returns 0 if vmin==vmax.
>         Works with scalars or arrays, including masked arrays.  If clip
>         is True, masked values on input will be set to 1 on output; if
>         clip is False, the mask will be propagated to the output.
>         """
>         self.vmin = vmin
>         self.vmax = vmax
>         self.clip = clip
> 
>     def __call__(self, value):
> 
>         if isinstance(value, (int, float)):
>             vtype = 'scalar'
>             val = ma.array([value])
>         else:
>             vtype = 'array'
>             val = ma.asarray(value)
> 
>         self.autoscale(val)
>         vmin, vmax = self.vmin, self.vmax
>         if vmin > vmax:
>             raise ValueError("minvalue must be less than or equal to maxvalue")
>         elif vmin==vmax:
>             return 0.*value
>         else:
>             if self.clip:
>                 val = clip(val.filled(vmax), vmin, vmax)
>             result = (1.0/(vmax-vmin))*(val-vmin)
>         if vtype == 'scalar':
>             result = result[0]
>         return result
> 
>     def autoscale(self, A):
>         if not self.scaled():
>             if self.vmin is None: self.vmin = ma.minimum(A)
>             if self.vmax is None: self.vmax = ma.maximum(A)
> 
>     def scaled(self):
>         'return true if vmin and vmax set'
>         return (self.vmin is not None and self.vmax is not None)
> 
> 
> JDH