matplotlib-devel Mailing List for matplotlib (Page 3)

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

>>>>> "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,
It looks like you are referring to bugs in the Colormap.__call__ method 
that were introduced when I added support for masked values 
out-of-bounds values. I have committed a change that fixes the bugs I 
could find there (as tested with examples/image_masked.py), so that the 
colormap call produces exactly the same output with scipy as with 
Numeric or numarray--the same rgba values. Unfortunately, although that 
demo now runs with all three, it produces different plots. It appears 
that somewhere else in the code--I'm pretty sure it is not within 
colors.py--the floating point rgba values are getting rounded or, more 
likely, truncated, when using scipy.
Eric
John Hunter wrote:
> I just committed some changes to fix the scipy core patch. The
> problem was that Daishi apparently had the full scipy installed, so
> many of the imports that worked in his tests did not work for scipy
> core.
> 
> Most things seem to be working, but there is a problem in the
> colormapping code in colors.py. The index into the LUT, which should
> be an integer array, is coming out as a float array for scipy core.
> I'm not sure why. Perry wrote this section of the code so he has a
> better understanding of it than I do (around line 240 in colors.py),
> this line is failing
> 
> #print 'types', typecode(self._lut), typecode(xa), xa.shape
> rgba = take(self._lut, xa)
> 
> There may be other problems, but this is the only one I know of
> currently. 
> 
> 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? There are a few of these functions used in matplotlib, and I
> just redefined them manually for now in numerix.mlab. Eg, mean, std,
> hanning, and a few more. Others, like cov, I buried the import into
> the function that needs them, eg in matplotlib.mlab in the
> detrend_linear function. If these aren't going to be in the core,
> what do people suggest we do for numerix.mlab.
> 
> If anyone has any suggestions for help on the colormap LUT problem
> referenced above, that would be great.
> 
> Thanks,
> JDH
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> 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=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I just committed some changes to fix the scipy core patch. The
problem was that Daishi apparently had the full scipy installed, so
many of the imports that worked in his tests did not work for scipy
core.
Most things seem to be working, but there is a problem in the
colormapping code in colors.py. The index into the LUT, which should
be an integer array, is coming out as a float array for scipy core.
I'm not sure why. Perry wrote this section of the code so he has a
better understanding of it than I do (around line 240 in colors.py),
this line is failing
 #print 'types', typecode(self._lut), typecode(xa), xa.shape
 rgba = take(self._lut, xa)
There may be other problems, but this is the only one I know of
currently. 
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? There are a few of these functions used in matplotlib, and I
just redefined them manually for now in numerix.mlab. Eg, mean, std,
hanning, and a few more. Others, like cov, I buried the import into
the function that needs them, eg in matplotlib.mlab in the
detrend_linear function. If these aren't going to be in the core,
what do people suggest we do for numerix.mlab.
If anyone has any suggestions for help on the colormap LUT problem
referenced above, that would be great.
Thanks,
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I just updated from cvs (Dec 3, 2:56 EST) and got the
 Darren> following errors when I tried to build:
 Darren> /usr/lib64/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py:13155:
 Darren> UserWarning: wxPython/wxWidgets release number mismatch
 Darren> warnings.warn("wxPython/wxWidgets release number
 Darren> mismatch") Traceback (most recent call last): File
 Darren> "setup.py", line 257, in ? template =
 Darren> file('matplotlibrc.template').read() IOError: [Errno 2] No
 Darren> such file or directory: 'matplotlibrc.template'
Try again -- I forgot to commit this. I decided to use a rc template
file that would insert the numerix and backend found at build time.
JDH

I just updated from cvs (Dec 3, 2:56 EST) and got the following errors when I 
tried to build:
/usr/lib64/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py:13155: 
UserWarning: wxPython/wxWidgets release number mismatch
 warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
 File "setup.py", line 257, in ?
 template = file('matplotlibrc.template').read()
IOError: [Errno 2] No such file or directory: 'matplotlibrc.template'
The wxWidgets error is probably an issue with my system. Did someone forget to 
add matplotlibrc.template during a recent commit?
Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> I suggest backing out the patch, removing the changes to
 Eric> "resize", and putting the modified version back.
I've been working on this in my local tree and need just a few more
modifications before committing. I already made this change, as well
as making all three packages supported. There are additional issues
to fix, eg the scipy.fftpack import is broken if only scipy core is
installed and not the full scipy, and Robert has been helping me a bit
with these.
JDH

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 suggest backing out the patch, removing the changes to "resize", and 
putting the modified version back.
Eric
da...@eg... wrote:
> On Nov 30, 2005, at 2:24 PM, John Hunter wrote:
> 
>>>>>>> "John" == John Hunter <jdh...@ac...> writes:
>>
>>
>> John> I just committed Daishi's patch to CVS, with Fernando's
>> John> modification to catch the new scipy versus old scipy.
>>
>> Seems there is a problem with "resize"
> 
> 
> 
> Hi John,
> 
> Sorry the patch is causing problems.
> I'm not exactly sure how the resize
> problem is coming up, however - all
> I did for those things is:
> 
> --- numerix/__init__.py:
> if (which[0] == 'numarray' or
> which[0] == 'numeric'):
> def typecode(a):
> return a.typecode()
> def iscontiguous(a):
> return a.iscontiguous()
> def byteswapped(a):
> return a.byteswapped()
> def itemsize(a):
> return a.itemsize()
> def resize(a, shape):
> return a.resize(shape)
> ---
> 
> and then replace what used to be
> a.resize(shape) calls to resize(a, shape).
> 
> So aside from the extra function call
> overhead I don't see how the semantics
> would have changed (perhaps I missed
> some substitutions? I did a simple grep
> on the source tree to find occurrences
> and edited manually, so I may have just
> oops-ed a couple of them).
> 
> I'm also happy to fix the numarray&(numeric|scipy)
> thing, although it would basically just be a
> cut&paste job in setupext.py. (I'm in the middle
> of some other things right now so it may be
> a week or so before I get to this, however).
> 
> d
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> 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=7637&alloc_id=16865&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 12/1/05, Charlie Moad <cw...@gm...> wrote:
> It would help if you were more specific. Are you referring to
> animation or static images? I can generate a million point scatter
> plot in under a minute, and I would consider this pretty good for a
> general purpose plotting package.
Hi matplotlib'ers!
while the end result in matplotlib is starting to "get there", the speed is
not yet where it has to be to be useful IMO. I hereby post a little challen=
ge
for the matplotlib developers;
get the actual plotting time (from the first plot command until show is don=
e)
on the below dataset down to less than a second,(including the quiver
command in the plot.py file).
download the 3 files here (ca 600kb in total)
http://www.ii.uib.no/~avle/slow1/
execfile('plot.py') to plot the dataset (works for me with cvs as of today)=
.
 the first part of the file is just some convenience funcs for loading
the data. the plotting happen near the end.
this is a moderately sized grid, 433x560 cells (those of you into
oceanography may recognize the area). what I observe on my pentium
2.54ghz linux box:
-after "data ok" on screen, it takes ca15s to render. pygist uses < 0.5s
-zoom operations take ca 5s. pygist is "instant".
-you don't want to wait for an additional quiver layer. it must take
minutes to finish. pygist is instant. with quiver, also zooming is
equally slow, the ui freeze for ages.
-often one wants to add contours from other fields on top of this, in
pygist this adds no
 visible delay, matplotlib easily doubles the rendering time.
typical usage for me is to load many such datasets, and do a lot of
zoom in/out/pan to various features, modify colors/levels, add
velocity vectors etc. currently this is quite
painful in matplotlib, as one zoom operation on realistic datasets
easily takes 10 seconds on a multi ghz machine. pygist is very fast,
even on a 400mhz laptop, memory usage is also a lot lower.
so, I think matplotlib is a great effort, and shows a lot of promise, but
for realistic use, it is (at least for me) still far too slow!
Helge

No problem -- I'm pleased to contribute. I'll check out mpl from CVS
and test it out, and I'll submit a patch for the release notes and
htdocs.
Rob
On 11/30/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Rob" =3D=3D Rob McMullen <rob...@gm...> writes:
>
> Rob> Oh, and I didn't say so in the patch itself, but I'm happy to
> Rob> donate the patch to matplotlib under the default matplotlib
> Rob> license.
>
> Great Rob -- thanks. This was the first I've heard of EMF but I read
> through your web page and it looks interesting. I don't have time
> right now to install the prereqs and test, but you may want to grab
> the latest CVS mpl and make sure everything is working for you.
>
> You may also want to write a blurb for the release notes, and add a
> patch against the matplotlib CVS htdocs and or users guide to explain
> EMF and provide pointers to your web site on the mpl site.
>
> Checking in matplotlib/backends/backend_emf.py;
> /cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_emf.py,v =
<-- backend_emf.py
> initial revision: 1.1
> done
>
> Thanks again,
> JDH
>

On Nov 30, 2005, at 2:24 PM, John Hunter wrote:
>>>>>> "John" == John Hunter <jdh...@ac...> writes:
>
> John> I just committed Daishi's patch to CVS, with Fernando's
> John> modification to catch the new scipy versus old scipy.
>
> Seems there is a problem with "resize"
Hi John,
Sorry the patch is causing problems.
I'm not exactly sure how the resize
problem is coming up, however - all
I did for those things is:
--- numerix/__init__.py:
if (which[0] == 'numarray' or
 which[0] == 'numeric'):
 def typecode(a):
 return a.typecode()
 def iscontiguous(a):
 return a.iscontiguous()
 def byteswapped(a):
 return a.byteswapped()
 def itemsize(a):
 return a.itemsize()
 def resize(a, shape):
 return a.resize(shape)
---
and then replace what used to be
a.resize(shape) calls to resize(a, shape).
So aside from the extra function call
overhead I don't see how the semantics
would have changed (perhaps I missed
some substitutions? I did a simple grep
on the source tree to find occurrences
and edited manually, so I may have just
oops-ed a couple of them).
I'm also happy to fix the numarray&(numeric|scipy)
thing, although it would basically just be a
cut&paste job in setupext.py. (I'm in the middle
of some other things right now so it may be
a week or so before I get to this, however).
d