matplotlib-users Mailing List for matplotlib

Christopher Barker wrote:
> giovanni ruggiero wrote:
>> Hi All,
>> I had problens to use the function quiver with the matplotlib 82-5. Eric 
>> advice me to upgrade the mpl. I have tried to upgrade the matplotlib but 
>> i have to upgrade almost all my libs. The case is that i can not upgrade 
>> these dependences without affect all my configuration wich means that i 
>> need to install my system again. Am i correct? 
> 
> You should be able to have newer version of libs alongside the old ones. 
> If there are not compatible packages (rpms, debs, whatever) for the 
> newer libs, you should be able to build them by hand (./configure, make, 
> etc). Just make sure they are installed in /usr/local/...


If John's "apt-get" solution does not work--and it is my impression that 
there are many circumstances under which it will not work, even if it 
"should"--and you do not want to do a full install of something like 
ubuntu Edgy, then I think that the simplest way to have a working 
up-to-date mpl is to install *only* mpl from svn or from the tarball. 
As far as I know, current mpl depends on current numpy *if* you use 
numpy as your numerix choice; but if you use Numeric or numarray then 
none of the libraries used by mpl has to be very new, so you should not 
have to build anything other than mpl from source.  As Chris says, 
putting it in /usr/local is a good idea: "python setup.py build; sudo 
python setup.py install --prefix=/usr/local" should do it.  f the build 
fails, it will almost certainly be because a header file is missing, in 
which case you can install the corresponding dev package from your 
*present* version of ubuntu or whatever.  This is likely to be an 
iterative process because several -dev packages will be needed.

The nice thing about doing it this way is that updating to any 
subsequent mpl release or svn version is fast and easy, so you can take 
advantage of improvements without waiting for a packager to make a 
binary package for your particular distribution version.

Can anyone either confirm that my advice works in practice, or if not, 
say where it goes wrong?  This question of how to have up-to-date mpl on 
a not-so-up-to-date linux installation keeps coming up.

Longer term I would encourage everyone to find a way ASAP to update 
whatever is necessary to have an up-to-date numpy rather than using old 
Numeric or numarray, so the advice in my first paragraph is intended as 
a stopgap.  The same basic method can in fact be used to install the 
latest numpy release.  (Does anyone know of a reason this would not work 
for an older linux distribution version?)  It is critical that mpl be 
built *after* installing whatever numerical package is going to be used, 
however.

Eric

Robert Cimrman wrote:
> Eric Firing wrote:
>> One more miscellaneous thought: perhaps spy and spy2 should be 
>> consolidated into a single function with a kwarg to select the marker 
>> version or the image version?  Their purpose is identical (isn't it?), 
>> and it would reduce namespace clutter.
> 
> one more thing here: usually (e.g. in Matlab) the y axis is reversed, so
> that one sees the sparsity pattern in the same position as one would see
> on paper when writing down the corresponding system of linear equations.
> (I use my own spy, with ax.set_ylim( ax.get_ylim()[::-1] ) for this
> purpose.)
> 
> just my 2 cents, in case of the consolidation.

Good, I was thinking exactly the same thing, so I will take care of that.

Eric

Eric Firing wrote:
> One more miscellaneous thought: perhaps spy and spy2 should be 
> consolidated into a single function with a kwarg to select the marker 
> version or the image version?  Their purpose is identical (isn't it?), 
> and it would reduce namespace clutter.

one more thing here: usually (e.g. in Matlab) the y axis is reversed, so
that one sees the sparsity pattern in the same position as one would see
on paper when writing down the corresponding system of linear equations.
(I use my own spy, with ax.set_ylim( ax.get_ylim()[::-1] ) for this
purpose.)

just my 2 cents, in case of the consolidation,
r.

Eric Firing wrote:
> Robert Cimrman wrote:
>> John Hunter wrote:
>>>>>>>> "Robert" == Robert Cimrman <cim...@nt...> writes:
>>>     Robert> BTW would you consider changing the definition of spy(2)
>>>     Robert> as shown below, so that one could specify what 'to be a
>>>     Robert> zero' means?
>>>
>>> I added these enhancement, and a couple more, and an
>>> examples/spy_demos.py.
>>>
>>> On reflection, it might be better to allow the user to simply pass a
>>> sparsity function rather than a precision
>>>
>>> def not_zero(Z):
>>>     return Z!=0.
>>>
>>> class not_near_zero:
>>>     def __init__(self, precision):
>>>         self.precision = precision
>>>     def __call__(self, Z):
>>>         return absolute(asarray(Z))>self.precision
>>>
>>> def spy(Z, element=not_zero):
>>>     mask = element(Z)
>>>
>>> Then you could do:
>>>
>>> spy(Z, issparse=not_near_zero(1e-6))
>>>
>>>
>>>
>>> The precision implementation you suggested is in svn, but if there is
>>> any consensus that either of these approaches is better, speak up.
>> I was thinking about passing directly a function (or an expression?)
>> too. But I would not remove the precision argument, since it's usage is
>> simpler, and is usually all one needs. The best would be to have both
>> possibilities :) (function, if present, taking precedence?)
> 
> I agree--and in fact my uninformed view is that even the precision 
> option is taking spy beyond the realm of showing true sparcity.  If this 
> is genuinely useful to people, then fine.  But if it (mainly the 
> function option) is something that merely might be useful to someone 
> someday, then I suggest it be left out until there is a clear need.  (My 
> 2 cents-worth, or less.)

Well, the precision argument is useful mainly because of unsafe
comparison of floating point values (what is exactly zero?), so it can
be used, in fact, to show the true sparsity, and I for one would use it :)

> Curiosity questions about implementation:
> 
> 1) What is the "tocoo" method, and what objects have it?

a scipy sparse matrix method, to make spy compatible with the sparse
matrix module.

> 2) Is there a reason why one shouldn't simply default precision to 0 and 
> use the condition "absolute(asarray(Z)) <= precision"?

just a little (full matrix case) and not so little (sparse matrix case)
performance penalty.

> One more miscellaneous thought: perhaps spy and spy2 should be 
> consolidated into a single function with a kwarg to select the marker 
> version or the image version?  Their purpose is identical (isn't it?), 
> and it would reduce namespace clutter.

that would be good!

r.

I found one more solution which makes use of the sansmath.py style, available at
http://www.tug.org/tex-archive/macros/latex/contrib/misc/sansmath.sty.

To use it with matplotlib I updated the 'sans-serif' member of the font_info
dict:

       'sans-serif': ('cmss', '\usepackage{sansmath}'),

and to the end of sansmath.py I added

\sansmath

to activate sans math mode upon loading. Then, choosing 'sans-serif' as first
sansserif font in .matplotlibrc you get nice serif free math text.

It should be easy to add this to the matplotlib distro.

Christian

Christian Kristukat <ckkart@...> writes:

> 
> Darren Dale <dd55 <at> ...> writes:
> > We tried supporting sans-serif ticklabels with usetex a while back, and it 
> > turned out to be a headache. I'll have a look at cmbright, but no promises.
> 
> Thanks. Btw., I didn't know about cmbright before looking at this problem. It
> seems to be part of most tex distributions, e.g. tetex, miktex.

I kept on experimenting and now ps output works, too. However it was necessary to
install the type1 version of the cmbright fonts, which are unfortunately not part
of tetex. They are available here:
http://hannes.boehm.org/LaTeX/
I don't know if it is possible to have them outside the regular tetex tree and 
make tex use them so that they could be shipped with matplotlib.
Or is that solution not acceptable at all?

Regards, Christian