[SciPy-dev] pynotes

[Arnd Baecker]

Hi,

thank you very much for the feedback.

On Fri, 19 Nov 2004, Prabhu Ramachandran wrote:

> >>>>> "AB" == Arnd Baecker <arnd.baecker at web.de> writes:
>
>     AB> Hi, following Prabhu's comments I made a few changes to
>     AB> pynotes.  It can now deal with ufuncs and some builtin
>     AB> functions.  Also the path component including the python
>     AB> version is stripped.  The current version can be obtained from
>     AB>   http://www.physik.tu-dresden.de/~baecker/tmp/pynotes/
>     AB> There also is a small test script, test2.py, which outputs the
>     AB> path to a given object for several examples (The output for my
>     AB> machine is in test2.out).
>
> Downloaded this and tried, but I get errors.
>
> $ python pynotes.py
> Uuups, no scipy with linalg.flapack.zgesv installed ?
> Note that this is not that reliable, IMHO
> Uuups, no scipy with linalg.clapack.cgetri installed ?
> Note that this is not that reliable, IMHO


Interesting, but not completely unexpected as the
"Note" indicates ;-).

Let me explain what I am trying to do there:
For certain types of objects, namely ufuncs and fortran funcs,
it is (AFAIK) not possible to get their path via
<object>.__file__ or
inspect.getsourcefile(scipy.linalg.flapack.zgesv).
Therefore I just check the type of the object
to be a ufunc or fortran func and put
notes for objects in ~/.pynotes/Ufuncs/<objname>.txt,
or ~/.pynotes/Fortranfuncs/<objname>.txt, respectively.

So this is based on the comparison
  type(obj)==FORTRANTYPE
and FORTRANTYPE is obtained before by
  FORTRANTYPE=type(scipy.linalg.flapack.zgesv)

Your result shows that this is not the best
approach to get the type of the routines in flapack.

Is there a better way to get the type of routines
in flapack (and clapack)?
((Note that the types of the routines in lapack and clapack which
seem to be different:
In [6]: type(scipy.linalg.flapack.zgesv)==type(scipy.linalg.clapack.zgetri)
Out[6]: False
))

Just out of curiosity: Prabhu, what does
In [1]: import scipy
In [2]: scipy.linalg.flapack.<TAB>
give on your machine?

> Traceback (most recent call last):
>   File "pynotes.py", line 503, in ?
>     addnote(Numeric)
> TypeError: addnote() takes exactly 2 arguments (1 given)

Stupid me - I made quite a few changes to
the way how addnote etc. are called, but did not
change the example at the end of pynotes.
I updated that version now.


In any case, the "real" test is to run
  python test2.py
as this tests out several objects.
(It will only output the resulting path, but
that's the only crucial point).

>     AB> - are there modules/objects where the approach fails?
>     AB>     (I would be very surprised if not ;-) - I am pretty
>     AB>      certain that one could overcome such problems
>
> Time will surely tell. :)
>
>     AB> - would this approach be useful for scipy,
>     AB>     in particular for user-contributed documentation,
>     AB>     code-snippets etc.?
>
> I think this is quite cool and might work out if all of us agree to
> use it more and integrate it into IPython.  Having said that, we
> should note that often, good ideas fail for some reason or another...

For this to happen (not the failing ;-) I think the following
steps are relevant:
  - we should discuss how additional information will
    be made available for scipy
    One way might be the pynotes approach, but
    maybe there is something better/more suitable.
    In particular I would be interested
    in the plans for the scipy livedocs -
    the edit link is already there!
  - more testing of pynotes
    on other systems (Windows,Mac,Redhat,Suse,Fedora....),
    The output of python test2.py mailed to me (offlist)
    + system detail should provide quite a bit of insight
  - Integration into IPython will be the easiest part ;-)
  - Once everything is in place and working
    a bit of "advertising" might be needed, both
    on the scipy homepage and scipy-user.
    (To motivate people a weekly and monthly high-score
    list of contributions to the documentation
    might help ;-) - but that's really the last step ...


Best, Arnd