# bug with spy(D)?

Hi all

I have got some funny behaviour here that looks like a bug with the
spy() function. Using the latest python-matplotlib 0.87.5 package on
Ubuntu 6.10, I try:

\$ ipython -pylab
from scipy import io
spy(M)
M.shape
M.nnz

It looks great and I get the necessary number of dots on my 'spy' plot.
Then:

spy(M.todense())

This seems to plot only half of the points. At first I thought the
'todense' function must be to blame, however:

D = M.todense()
for i in range(0,231):
for j in range(0,231):
if D[i,j]:
print i,j,D[i,j]

gave me the right data, so it really looks like a bug with spy().

And FWIW spy2(M) fails with an error, whereas spy2(D) shows the same bug
as spy(D).

Is this something that has been fixed in the new 0.90 release?

Cheers
JP

gd.mm (1.51 KB)

···

--
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
http://pye.dyndns.org/

John Pye wrote:

Hi all

I have got some funny behaviour here that looks like a bug with the
spy() function. Using the latest python-matplotlib 0.87.5 package on
Ubuntu 6.10, I try:

\$ ipython -pylab
from scipy import io
spy(M)
M.shape
M.nnz

It looks great and I get the necessary number of dots on my 'spy' plot.
Then:

spy(M.todense())

This seems to plot only half of the points. At first I thought the
'todense' function must be to blame, however:

D = M.todense()
for i in range(0,231):
for j in range(0,231):
if D[i,j]:
print i,j,D[i,j]

gave me the right data, so it really looks like a bug with spy().

And FWIW spy2(M) fails with an error, whereas spy2(D) shows the same bug
as spy(D).

Is this something that has been fixed in the new 0.90 release?

The two versions of spy were merged into one, with some rewriting, in 0.90. Please give it a try and see if the problem persists.

Eric

Hi Eric

I tried the new spy function under Windows and it seemed to work OK. A
great leap forward, actually, given the problems I had been seeing.
Merging the spy functions was a good idea (does it work ok for very very
large, very sparse matrices?)

Trying it under Ubuntu was less straightforward. I built an RPM (python
setup.py bdist_rpm) then converted it to deb package then installed it.
It complained about my old ~/.matplotlib/matplotlibrc file so I moved it
out of the way. Then I fired up again and it was OK.

In my new Ubuntu install of matplotlib, sans matplotlibrc, I would like
to switch GUIs to GTKAgg but there doesn't seem to be a
/etc/matplotlibrc file from which to base my configuration. Is this a
fault of my rpm-to-deb process, or something that failed during build?
Is it still possible to run the GTKAgg GUI? Has the config system changed?

Finally, can I suggest that the website be updated with some information
on-line -- had to go to the tarball. I think generally the matplotlib
community would benefit from more frequently updated website. While I'm
at it, maybe I could suggest a matplotlib wiki that gets a bit more
prominance on the homepage and that is *separate* from the scipy one,
since the scipy wiki gives completely mixed messages about what plotting
engine is preferred (chaco.wx and VTK and so on) -- it can't be helping
the matplotlib cause.
http://matplotlib.sourceforge.net/whats_new.html (bit out of date)

Cheers
JP

Eric Firing wrote:

···

> John Pye wrote:

>> Hi all
>>
>> I have got some funny behaviour here that looks like a bug with the
>> spy() function. Using the latest python-matplotlib 0.87.5 package on
>> Ubuntu 6.10, I try:
>>
>> \$ ipython -pylab
>> from scipy import io
>> spy(M)
>> M.shape
>> M.nnz
>>
>> It looks great and I get the necessary number of dots on my 'spy' plot.
>> Then:
>>
>> spy(M.todense())
>>
>> This seems to plot only half of the points. At first I thought the
>> 'todense' function must be to blame, however:
>>
>> D = M.todense()
>> for i in range(0,231):
>> for j in range(0,231):
>> if D[i,j]:
>> print i,j,D[i,j]
>>
>> gave me the right data, so it really looks like a bug with spy().
>>
>> And FWIW spy2(M) fails with an error, whereas spy2(D) shows the same bug
>> as spy(D).
>>
>> Is this something that has been fixed in the new 0.90 release?

>
> The two versions of spy were merged into one, with some rewriting, in
> 0.90. Please give it a try and see if the problem persists.
>
> Eric

John Pye wrote:

Hi Eric

I tried the new spy function under Windows and it seemed to work OK. A
great leap forward, actually, given the problems I had been seeing.
Merging the spy functions was a good idea (does it work ok for very very
large, very sparse matrices?)

I don't know any reason it would not, but I have not tried it.

Trying it under Ubuntu was less straightforward. I built an RPM (python
setup.py bdist_rpm) then converted it to deb package then installed it.
It complained about my old ~/.matplotlib/matplotlibrc file so I moved it
out of the way. Then I fired up again and it was OK.

That sounds like the hard way. I find it easy to build and install directly from source--from svn in my case, but from a tarball should be the same. I install it in /usr/local instead of /usr/ so as to keep the distinction between things installed as packages and custom installations.

In my new Ubuntu install of matplotlib, sans matplotlibrc, I would like
to switch GUIs to GTKAgg but there doesn't seem to be a
/etc/matplotlibrc file from which to base my configuration. Is this a
fault of my rpm-to-deb process, or something that failed during build?
Is it still possible to run the GTKAgg GUI? Has the config system changed?

A system-wide matplotlibrc file should get installed somewhere--try using "locate" to find it. I think a change was made since 0.90 such that yours will be in a different place than mine is now. If it turns out that it got lost in the rpm-to-deb conversion, then look at matplotlibrc.template in the source directory. With a couple of string substitutions you can manually turn that into a valid matplotlibrc file and specify your numerix (numpy, I hope) and backend. You can always put it in your ~/.matplotlib directory, and make local copies in working directories if you want different defaults for a given project.

Finally, can I suggest that the website be updated with some information
on-line -- had to go to the tarball. I think generally the matplotlib
community would benefit from more frequently updated website. While I'm
at it, maybe I could suggest a matplotlib wiki that gets a bit more
prominance on the homepage and that is *separate* from the scipy one,
since the scipy wiki gives completely mixed messages about what plotting
engine is preferred (chaco.wx and VTK and so on) -- it can't be helping
the matplotlib cause.
http://matplotlib.sourceforge.net/whats_new.html (bit out of date)

Thanks for the good suggestions. I agree that there could be improvements--it is just a question of who can find the time and motivation to make them, amid competing pressures.

Eric

···

Cheers
JP