mlab.py in svn has now been changed quite a bit:
1) It uses straight numpy.
2) In many but not all cases, I tried to simplify algorithms by using
numpy capabilities. I did some testing, but beware: there may be new bugs.
3) For functions with numpy equivalents I put in deprecation warnings,
wit
On 8/12/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> mlab.py in svn has now been changed quite a bit:
>
> 1) It uses straight numpy.
> 2) In many but not all cases, I tried to simplify algorithms by using
> numpy capabilities. I did some testing, but beware: there may be new bugs.
> 3) For functio
Fernando Perez wrote:
> On 8/12/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>> mlab.py in svn has now been changed quite a bit:
> But if I may make a small comment, in my view MPL should simply not
> contain any numerics, period (beyond that needed for plotting
> functions).
For the most part,m I
Christopher Barker wrote:
[...]
>
> Does internal MPL code rely on mlab? if so, it needs to be part of some
> core lib that is stable enough to be a MPL dependency.
>
Good question. With a couple of minor exceptions (which are easily
handled), the only dependency is in axes methods that I don'
Brandon,
I could add that method very easily, but do we really need it? Is there
a compelling use case? You can always access the title directly as an
attribute of the axes instance. xlabel and ylabel are other things for
which there is a setter but not a getter. This dates from before my
