On Sun, 29 Oct 2006 11:09:44 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Oct 29, 2006, at 12:01 PM, William Stein wrote:
>> After building, from the interpreter I did this:
>>
>> sage: import sage.modular.modsym.p1list as p
>> sage: p.test_foo(10)
>> 100
>
> Sweet. Well, maybe we should be doing that in a few places then.
> Seems very clean and natural.
Yes, definitely. Feel free to redo p1list.pyx this way if you want.
David H: And if you want to have a little more fun, you could rewrite
p1list so it only enumerates and stores elements (a,b) of P1 with
gcd(a,N) and gcd(b,N) both not 1. This is what Cremona's program
already does, and it would speed it up p1list a lot. The point
is that you're trying to compute with a list of all elements of P1,
where compute means create a computable mapping from
(Z/nZ x Z/nZ)* ---> 0,1,..., #P1-1
where the * means "omit pairs such that gcd(a,b,N)!=1".
It's actually not necessary to actually enumerate and store all the
pairs (a,b). Anyway, I mentioned this to you a long time ago, when
you were interested in working on SAGE instead of (?) mathml...
I wrote this section up for the programming guide.
\subsection{Using cdef Module-Level Functions in Other Modules}
Suppose there is a cdef function in a Pyrex file \code{A.pyx} that is
not a method of a class, but you would like to use it from another
Pyrex module. For example, the file \code{A.pyx} might contain
\begin{verbatim}
cdef int sqr_int(int x):
return x*x
\end{verbatim}
You would like to call this C-level method directly from a different Pyrex
module.
To do so, {\em it is crucial} to declare the method public instead:
\begin{verbatim}
cdef public int sqr_int(int x):
return x*x
\end{verbatim}
Then create a file \code{A.pxd} that contains
\begin{verbatim}
cdef extern int sqr_int(int x)
\end{verbatim}
Finally, to use \code{sqr_int} in another Pyrex module \code{B.pyx},
do the following:
\begin{verbatim}
cimport sage.rings.A # this is just an example absolute path
def myfunction():
print sage.rings.A.sqr_int(5)
\end{verbatim}
Any time you access one Pyrex module from another one,
it's necessary that the compiler know to link in the other Pyrex
module (\code{A.pyx} in our example). Tell it to link
in \code{A.pyx} by including \code{A.pyx}
in the corresponding entry in \code{setup.py}. That
entry should look something like this:
\begin{verbatim}
Extension('sage.modular.B',
['sage/modular/B.pyx', 'sage/rings/A.pyx'])
\end{verbatim}
Pyrex will generate a file \code{A.pxi} that also declares foo. You
can ignore that file.
{\bf NOTE:} Alternatively, you could put \code{include "path/to/A.pxi"}
in \code{B.pyx} and and directly use \code{sqr_int} in \code{B.pyx} with
no scoping:
\begin{verbatim}
def myfunction():
print sqr_int(5)
\end{verbatim}
This is not recommended because it is confusing and
unpythonic to not have the scoping information.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
