/usr/share/doc/pari-gp2c/gp2c.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>An introduction to gp2c
</TITLE>

<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.10">
<STYLE type="text/css">
.li-itemize{margin:1ex 0ex;}
.li-enumerate{margin:1ex 0ex;}
.dd-description{margin:0ex 0ex 1ex 4ex;}
.dt-description{margin:0ex;}
.toc{list-style:none;}
.thefootnotes{text-align:left;margin:0ex;}
.dt-thefootnotes{margin:0em;}
.dd-thefootnotes{margin:0em 0em 0em 2em;}
.footnoterule{margin:1em auto 1em 0px;width:50%;}
.caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
.title{margin:2ex auto;text-align:center}
.center{text-align:center;margin-left:auto;margin-right:auto;}
.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
DIV TABLE{margin-left:inherit;margin-right:inherit;}
PRE{text-align:left;margin-left:0ex;margin-right:auto;}
BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
TD P{margin:0px;}
.boxed{border:1px solid black}
.textboxed{border:1px solid black}
.vbar{border:none;width:2px;background-color:black;}
.hbar{border:none;height:2px;width:100%;background-color:black;}
.hfill{border:none;height:1px;width:200%;background-color:black;}
.vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
.vdcell{white-space:nowrap;padding:0px;width:auto; border:2px solid green;}
.display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
.dcell{white-space:nowrap;padding:0px;width:auto; border:none;}
.dcenter{margin:0ex auto;}
.vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
.minipage{text-align:left; margin-left:0em; margin-right:auto;}
.marginpar{border:solid thin black; width:20%; text-align:left;}
.marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
.marginparright{float:right; margin-left:1ex; margin-right:0ex;}
.theorem{text-align:left;margin:1ex auto 1ex 0ex;}
.part{margin:2ex auto;text-align:center}
</STYLE>
</HEAD>
<BODY >
<!--HEVEA command line is: /usr/bin/hevea -fix ./gp2c.tex -->
<!--CUT DEF section 1 --><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">An introduction to <TT>gp2c</TT></H1><H3 CLASS="titlerest">By Bill Allombert and Ariel Pacetti</H3></TD></TR>
</TABLE><!--TOC section Contents-->
<H2 CLASS="section"><!--SEC ANCHOR -->Contents</H2><!--SEC END --><UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc1">1  What is <TT>gp2c</TT>?</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc2">1.1  Installing <TT>gp2c</TT></A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc3">2  A <TT>gp2c</TT> tutorial</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc4">2.1  How can I compile and run my scripts?</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc5">2.2  How can I compile directly with <TT>gp2c</TT>?</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc6">2.3  Using <TT>gp2c</TT> to find errors in GP scripts</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc7">2.4  Using compiled functions in a new program</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc8">2.5  Hand-editing the C file generated by <TT>gp2c</TT></A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc9">3  Advanced use of <TT>gp2c</TT></A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc10">3.1  <TT>gp2c</TT> types</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc11">3.2  Type declaration</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc12">3.3  Effect of types declaration on default values</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc13">3.4  Type casting</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc14">3.5  Example of optimisation</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc15">3.6  Types and member functions</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc16">4  Common problems</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc17">4.1  Meta-commands.</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc18">4.2  Unsupported functions.</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc19">4.3  Memory handling and global variables.</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc20">4.4  GP lists</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc21">4.5  The <I>install</I> command</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc22">5  Command-line options of <TT>gp2c</TT></A>
</LI></UL><!--TOC section What is <TT>gp2c</TT>?-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc1">1</A>  What is <TT>gp2c</TT>?</H2><!--SEC END --><P>The <TT>gp2c</TT> compiler is a package for translating GP routines into the C
programming language, so that they can be compiled and used with the
<A HREF="http://pari.math.u-bordeaux.fr">PARI</A> system or the GP calculator.</P><P>The main advantage of doing this is to speed up computations and
to include your own routines within the preexisting GP ones. It may also
find bugs in GP scripts.</P><P>This package (including the latest versions) can be obtained at the
URL:<BR>
<A HREF="http://pari.math.u-bordeaux.fr/download.html#gp2c"><TT>http://pari.math.u-bordeaux.fr/download.html#gp2c</TT></A></P><!--TOC subsection Installing <TT>gp2c</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc2">1.1</A>  Installing <TT>gp2c</TT></H3><!--SEC END --><P>After downloading the file <TT>gp2c-</TT><TT><EM>x.y.z</EM></TT><TT>pl</TT><TT><EM>t</EM></TT><TT>.tar.gz</TT> (where
<EM>x,y,z</EM> and <EM>t</EM> depend on the version), you first have to unzip the
file with the command:</P><P><B>gunzip gp2c-</B><B><EM>x.y.z</EM></B><B>pl</B><B><EM>t</EM></B><B>.tar.gz</B></P><P>This will create the new file <TT>gp2c-</TT><TT><EM>x.y.z</EM></TT><TT>pl</TT><TT><EM>t</EM></TT><TT>.tar</TT>.
Next you have to extract the files with the <B>tar</B> program:</P><P><B>tar -xvf gp2c-</B><B><EM>x.y.z</EM></B><B>pl</B><B><EM>t</EM></B><B>.tar</B></P><P>Note: You can do both steps at once with GNU <B>tar</B> by using the command:</P><P><B>tar -zxvf gp2c-</B><B><EM>x.y.z</EM></B><B>pl</B><B><EM>t</EM></B><B>.tar.gz</B></P><P>This creates a directory <TT>gp2c-</TT><TT><EM>x.y.z</EM></TT><TT>pl</TT><TT><EM>t</EM></TT>, which contains the
main <TT>gp2c</TT> files. Now you have to install the program.</P><P>You need the file <TT>pari.cfg</TT>. This file can be found in the PARI object
directory and is installed in $prefix/lib/pari/.</P><P>Copy or link this file in the <TT>gp2c</TT> directory, be sure to call it
<TT>pari.cfg</TT>.</P><P><B>ln -s .../lib/pari/pari.cfg pari.cfg</B></P><P>Run <B>./configure</B>, which will search for the PARI version and some
other configuration tools of the system. To install the program, type
<B>make</B>, and the program will be compiled. You can then run <B>make check</B> to verify that everything has gone fine (a bunch of OK&#X2019;s should show up).
All of this is completely standard, and you are now ready to use <TT>gp2c</TT>.</P><P>You can use <TT>gp2c</TT> directly from this directory or you can install it by
running <B>make install</B> as root. If you do not install it, you can run it
from the <TT>gp2c</TT> directory by typing <B>./gp2c</B></P><!--TOC section A <TT>gp2c</TT> tutorial-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc3">2</A>  A <TT>gp2c</TT> tutorial</H2><!--SEC END --><!--TOC subsection How can I compile and run my scripts?-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc4">2.1</A>  How can I compile and run my scripts?</H3><!--SEC END --><P><A NAME="compile_and_run"></A></P><P>The simplest way to use <TT>gp2c</TT> is to call <TT>gp2c-run</TT>. If you want to
know what happens in detail, see next section.</P><P>To make the examples easier to follow, please move to the <TT>gp2c</TT> directory
and link the root of your PARI source there:</P><P><B>ln -s .../pari .</B></P><P>As an example, we will take the file <TT>pari/examples/squfof.gp</TT>, which is a
simple implementation of the well-known SQUFOF factoring method of D. Shanks.</P><P>We just run the command:</P><P><B>./gp2c-run pari/examples/squfof.gp</B></P><P>After a little processing we get a GP session. But this session is special,
because it contains the compiled <I>squfof</I> function. Hence we can do the
following:</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? squfof(3097180303181)
[419]
i = 596
Qfb(133225, 1719841, -261451, 0.E-28)
%1 = 1691693
</PRE><P>Let&#X2019;s try a bigger example:
</P><PRE CLASS="verbatim">? squfof(122294051504814979)
[20137]
  ***   the PARI stack overflows !
  current stack size: 4.0 Mbytes
  [hint] you can increase GP stack with allocatemem()
? allocatemem()
  ***   Warning: doubling stack size; new stack = 8.0 MBytes.
? squfof(122294051504814979)
[20137]
[20137, 3445]
i = 46474
Qfb(321233929, 131349818, -367273962, 0.E-28)
%2 = 73823023
</PRE><P>We need a large stack because by default <TT>gp2c</TT> does not generate code to
handle the stack (the so-called <FONT COLOR=purple>gerepile</FONT> code). To instruct <TT>gp2c</TT>
to add <TT>gerepile</TT> code automatically, we must use the <B>-g</B> option.
So quit this GP session and launch a new one with -g. Oh well, before that type</P><P><B>ls pari/examples/squfof.gp*</B>
</P><PRE CLASS="verbatim">pari/examples/squfof.gp    pari/examples/squfof.gp.run
pari/examples/squfof.gp.c  pari/examples/squfof.gp.so
pari/examples/squfof.gp.o
</PRE><P>These are the files generated by <TT>gp2c-run</TT>:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
pari/examples/squfof.gp.c is the C file generated by <TT>gp2c</TT>.
</LI><LI CLASS="li-itemize">pari/examples/squfof.gp.o is the object file generated by the C compiler.
</LI><LI CLASS="li-itemize">pari/examples/squfof.gp.so is the shared library generated by the linker.
</LI><LI CLASS="li-itemize">pari/examples/squfof.gp.run is a file that contains the commands needed
to load the compiled functions inside GP.
</LI></UL><P>
It is the shared library which is used by GP.</P><P>Now let&#X2019;s continue:</P><P><B>./gp2c-run -g pari/examples/squfof.gp</B>
</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? squfof(122294051504814979)
[20137]
[20137, 3445]
i = 46474
Qfb(321233929, 131349818, -367273962, 0.E-28)
%1 = 73823023
</PRE><P>This time it works with no difficulty using the default stack. We would like
to know how much faster the compiled code runs, so we need to load the non
compiled <I>squfof</I> file in GP:</P><PRE CLASS="verbatim">? \r pari/examples/squfof.gp
  ***   unexpected character: squfof(n)=if(isprime(n),retur
                                       ^--------------------
</PRE><P>Why?? Because <I>squfof</I> already exists as an installed function and GP
refuses to overwrite it. To solve this problem, we will add a suffix to the
name of the compiled function under GP. Quit the session and type:</P><P><B>./gp2c-run -g -s_c pari/examples/squfof.gp</B></P><P>Now the function squfof is named squfof_c instead, so we can do
</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? \r pari/examples/squfof.gp
? #
   timer = 1 (on)
? squfof(122294051504814979)
[20137]
[20137, 3445]
i = 46474
Qfb(321233929, 131349818, -367273962, 0.E-28)
time = 5,810 ms.
%1 = 73823023
? squfof_c(122294051504814979)
[20137]
[20137, 3445]
i = 46474
Qfb(321233929, 131349818, -367273962, 0.E-28)
time = 560 ms.
%2 = 73823023
</PRE><P>So the compiled version is more than ten times faster than the noncompiled one.
However for more complex examples, compiled code usually runs only
three times faster on average.</P><P>An extra trick: once you have run <TT>gp2c-run</TT> on your script, it is
compiled and you can use the compiled version outside <TT>gp2c-run</TT> in any GP
session by loading the file with extension <TT>.gp.run</TT>. For example quit the
<TT>gp2c-run</TT> session and start <TT>gp</TT> and do</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? \r pari/examples/squfof.gp.run
</PRE><P>Now you have access to the compiled function <I>squfof_c</I> as well.</P><!--TOC subsection How can I compile directly with <TT>gp2c</TT>?-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc5">2.2</A>  How can I compile directly with <TT>gp2c</TT>?</H3><!--SEC END --><P><A NAME="compile_directly"></A></P><P>Now we want to compile directly with <TT>gp2c</TT> to understand what happens.
We should run the command</P><P><B>./gp2c pari/examples/squfof.gp </B><CODE><B>&gt;</B></CODE><B> squfof.gp.c</B></P><P>This creates a file squfof.gp.c in the <TT>gp2c</TT> directory. Now read this
file with your favorite editor.</P><P>The first line is highly system-dependent, but should be similar to:</P><PRE CLASS="verbatim">/*-*- compile-command: "/usr/bin/gcc -c -o pari/examples/squfof.gp.o
  -O3 -Wall -I/usr/local/include pari/examples/squfof.gp.c
  &amp;&amp; /usr/bin/gcc -o pari/examples/squfof.gp.so
  -shared   pari/examples/squfof.gp.o"; -*-*/
</PRE><P>
This is the command needed to compile this C file to an object file with the
C compiler and then to make a shared library with the linker. If you use
<TT>emacs</TT>, typing &#X2019;M-x compile&#X2019; will know about this command, so you will
just need to type <TT>Return</TT> to compile.</P><P>The second line is
</P><PRE CLASS="verbatim">#include &lt;pari/pari.h&gt;
</PRE><P>This includes the PARI header files. It is important that the header files come
from the same PARI version as GP, else it will create problems.</P><P>The next lines are
</P><PRE CLASS="verbatim">/*
GP;install("squfof","D0,G,p","squfof","./pari/examples/squfof.gp.so");
GP;install("init_squfof","v","init_squfof","./pari/.../squfof.gp.so");
*/
</PRE><P>The characters "GP;" denote a command that should be read by GP at start-up.
Here, the <I>install()</I> commands above must be given to GP to let it know
about functions defined by the library. <TT>gp2c-run</TT> copy such commands
to the file <TT>./pari/examples/squfof.gp.run</TT>.</P><P>Please read the entry about the <I>install()</I> command in the PARI manual.</P><P>The <I>init_squfof</I> function is an initialization function that is created
automatically by <TT>gp2c</TT> to hold codes that is outside any function. Since
in our case there are none, this is a dummy function. In other cases, it is
essential. The next lines are</P><PRE CLASS="verbatim">GEN squfof(GEN n, long prec);
void init_squfof(void);
/*End of prototype*/
</PRE><P>This is the C prototypes of your functions. The rest of the file is
the C code proper.</P><P>For teaching purpose, let&#X2019;s run the command</P><P><B>./gp2c -s_c pari/examples/squfof.gp </B><CODE><B>&gt;</B></CODE><B> squfof2.gp.c</B></P><P>and look at the difference between squfof.gp.c and squfof2.gp.c:</P><P><B>diff -u squfof.gp.c squfof2.gp.c</B>
</P><PRE CLASS="verbatim">--- squfof.gp.c Tue Feb 26 13:44:42 2002
+++ squfof2.gp.c        Tue Feb 26 13:44:49 2002
@@ -1,8 +1,8 @@
 /*-*- compile-command: "/usr/bin/gcc -c -o pari/examples/squfof.gp.o
  -DMEMSTEP=1048576 -g -Wall -Wno-implicit  -I/usr/local/include
  pari/examples/squfof.gp.c &amp;&amp; /usr/bin/ld -o pari/examples/squfof.gp.so
  -shared   pari/examples/squfof.gp.o"; -*-*/
 #include &lt;pari/pari.h&gt;
 /*
-GP;install("squfof","D0,G,p","squfof","./pari/examples/squfof.gp.so");
-GP;install("init_squfof","v","init_squfof","./pari/.../squfof.gp.so");
+GP;install("squfof","D0,G,p","squfof_c","./pari/...les/squfof.gp.so");
+GP;install("init_squfof","v","init_squfof_c","./par.../squfof.gp.so");
 */
 GEN squfof(GEN n, long prec);
 void init_squfof(void);
</PRE><P>
If you are not familiar with the <TT>diff</TT> utility, the above means that only
the two lines starting with <I>GP;install</I> have changed. In fact <I>squfof</I> is
still named <I>squfof</I> in the C file, but the install command tells GP to
rename it <I>squfof_c</I> in the GP session.</P><!--TOC subsection Using <TT>gp2c</TT> to find errors in GP scripts-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">2.3</A>  Using <TT>gp2c</TT> to find errors in GP scripts</H3><!--SEC END --><P><A NAME="find_errors"></A></P><P>The <TT>gp2c</TT> compiler can also be used to find errors in GP programs. For
that we should use the -W option like in</P><P><B>./gp2c -W pari/examples/squfof.gp </B><CODE><B>&gt;</B></CODE><B> squfof.gp.c</B>
</P><PRE CLASS="verbatim">Warning:pari/examples/squfof.gp:7:variable undeclared
p
Warning:pari/examples/squfof.gp:11:variable undeclared
dd
Warning:pari/examples/squfof.gp:11:variable undeclared
d
Warning:pari/examples/squfof.gp:11:variable undeclared
b
...
Warning:pari/examples/squfof.gp:45:variable undeclared
b1
</PRE><P>This option lists variables that are used but not declared. It is important
to declare all your variables with <I>local()</I>, or with <I>global()</I>.
For <TT>gp2c</TT>, undeclared variables are taken to be &#X201C;formal variables&#X201D; for
polynomials. For example if you write a function to build a second degree
polynomial like
</P><DIV CLASS="center">
<CODE>pol(a,b,c)=a*x^2+b*x+c</CODE>
</DIV><P>
you must not declare &#X2019;x&#X2019; here, since it stands for the formal variable <I>x</I>.</P><!--TOC subsection Using compiled functions in a new program-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc7">2.4</A>  Using compiled functions in a new program</H3><!--SEC END --><P><A NAME="compiled_in_new_program"></A></P><P>One you have successfully compiled and tested your functions you may want to
reuse them in another GP program.</P><P>The best way is to copy the install commands of the functions you use at the
start of the new program so that reading it will automatically load the
compiled functions.</P><P>As an example, we write a simple program <TT>fact.gp</TT> that reads
</P><PRE CLASS="verbatim">install("squfof","D0,G,p","squfof","./pari/examples/squfof.gp.so");
fact_mersenne(p)=squfof(2^p-1)
</PRE><P>
and run GP:
</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? \rfact
? fact_mersenne(67)
i = 2418
Qfb(10825778209, 4021505768, -13258245519, 0.E-28)
%1 = 193707721
</PRE><P>So all goes well. But what is even better is that <TT>gp2c</TT> understands the
<I>install</I> command and will be able to compile this new program.</P><P>Also this particular example will fail because as stated above, PARI/GP already
has a <FONT COLOR=purple>squfof</FONT> function, and the linker will pick the wrong one, which is
unfortunate.</P><P>So use the -p option to <TT>gp2c-run</TT> to change <I>squfof</I> to
<I>my_squfof</I>.</P><P><B> ./gp2c-run -pmy_ -g pari/examples/squfof.gp</B></P><P>This option prefixes my_ to every GP name in the program so as to
avoid name clashes. Change <TT>fact.gp</TT> to
</P><PRE CLASS="verbatim">install("my_squfof","D0,G,p","squfof","./pari/examples/squfof.gp.so");
fact_mersenne(p)=squfof(2^p-1)
</PRE><P>
and run</P><P><B>./gp2c-run -g fact.gp</B>
</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? fact_mersenne(67)
i = 2418
Qfb(10825778209, 4021505768, -13258245519, 0.E-28)
%1 = 193707721
</PRE><P>Nice isn&#X2019;t it?</P><P>But it gets even better: instead of writing the <I>install</I> command directly
in your script you can just load the <TT>squfof.gp.run</TT> using
<CODE>\r</CODE>: just change <TT>fact.gp</TT> to
</P><PRE CLASS="verbatim">\r ./pari/examples/squfof.gp.run
fact_mersenne(p)=squfof(2^p-1)
</PRE><!--TOC subsection Hand-editing the C file generated by <TT>gp2c</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc8">2.5</A>  Hand-editing the C file generated by <TT>gp2c</TT></H3><!--SEC END --><P>If you have some experience in PARI programming, you may want to manually
edit the C file generated by <TT>gp2c</TT>, for example to improve memory handling.
Here some tips:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
If you preserve the <I>install()</I> at the start of the file, you can use
the command <B>gp2c-run </B><B><I>file</I></B><B>.c</B> to recompile your file and start a
new GP session with your functions added, just as you use <B>gp2c-run</B> with
GP scripts.</LI><LI CLASS="li-itemize">More generally, <B>gp2c-run</B> automatically passes any line in the C
file starting with &#X2019;GP;&#X2019; to GP at start-up.</LI><LI CLASS="li-itemize">As explained in Section <A HREF="#compile_directly">2.2</A>, under <B>emacs</B> you
can type &#X2019;M-x compile&#X2019; to recompile the shared library.
</LI></UL><!--TOC section Advanced use of <TT>gp2c</TT>-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc9">3</A>  Advanced use of <TT>gp2c</TT></H2><!--SEC END --><P><A NAME="advanced"></A>
</P><!--TOC subsection <TT>gp2c</TT> types-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc10">3.1</A>  <TT>gp2c</TT> types</H3><!--SEC END --><P>Internally <TT>gp2c</TT> assign types to objects. The most common types
are given below:</P><TABLE BORDER=1 CELLSPACING=0 CELLPADDING=1><TR><TD ALIGN=left NOWRAP>name</TD><TD ALIGN=left NOWRAP>description</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>void</I></TD><TD ALIGN=left NOWRAP>like in C</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>bool</I></TD><TD ALIGN=left NOWRAP>boolean, true (1) or false (0)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>negbool</I></TD><TD ALIGN=left NOWRAP>antiboolean, true (0) or false (1)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>small</I></TD><TD ALIGN=left NOWRAP>C integer <FONT COLOR=purple>long</FONT></TD></TR>
<TR><TD ALIGN=left NOWRAP><I>int</I></TD><TD ALIGN=left NOWRAP>multiprecision integer</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>real</I></TD><TD ALIGN=left NOWRAP>multiprecision floating point</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>mp</I></TD><TD ALIGN=left NOWRAP>multiprecision number</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>var</I></TD><TD ALIGN=left NOWRAP>variable</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>pol</I></TD><TD ALIGN=left NOWRAP>polynomial</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>vecsmall</I></TD><TD ALIGN=left NOWRAP>vector of C long (<FONT COLOR=purple>t_VECSMALL</FONT>)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>vec</I></TD><TD ALIGN=left NOWRAP>vector and matrices (excluding <I>vecsmall</I>)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>list</I></TD><TD ALIGN=left NOWRAP>GP lists</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>str</I></TD><TD ALIGN=left NOWRAP>characters string as a <FONT COLOR=purple>char *</FONT></TD></TR>
<TR><TD ALIGN=left NOWRAP><I>genstr</I></TD><TD ALIGN=left NOWRAP>characters string as a <FONT COLOR=purple>GEN</FONT> (<FONT COLOR=purple>t_STR</FONT>)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>gen</I></TD><TD ALIGN=left NOWRAP>generic PARI object (<FONT COLOR=purple>GEN</FONT>)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>lg</I></TD><TD ALIGN=left NOWRAP>length of object (returned by <I>length</I>)</TD></TR>
<TR><TD ALIGN=left NOWRAP><I>typ</I></TD><TD ALIGN=left NOWRAP>type of object (returned by <I>type</I>)</TD></TR>
</TABLE><BLOCKQUOTE CLASS="table"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<TABLE CLASS="display dcenter"><TR VALIGN="middle"><TD CLASS="dcell">
<IMG SRC="gp2c001.png">
</TD></TR>
</TABLE>
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Table 1: Types preorder</TD></TR>
</TABLE></DIV><A NAME="preorder"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></BLOCKQUOTE><P>Types are preordered as in Table <A HREF="#preorder">1</A>. The complete preorder
known by <TT>gp2c</TT> can be accessed by running <B>gp2c -t</B>.</P><P>Variables are typed. A variable can only take values having a type equal or
lower than its type. By default, variables are of type <I>gen</I>.</P><!--TOC subsection Type declaration-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc11">3.2</A>  Type declaration</H3><!--SEC END --><P>To declare a variable as belonging to type <I>type</I>, use:
</P><BLOCKQUOTE CLASS="quote">
<I>function</I>(x<I>:type</I>,y<I>:type</I>=2)<BR>
local(x<I>:type</I>, y<I>:type</I>=2)<BR>
global(x<I>:type</I>, y<I>:type</I>=2)<BR>
for(i<I>:type</I>=...
</BLOCKQUOTE><P>To declare several variables of the same type <I>type</I> at once, use:
</P><BLOCKQUOTE CLASS="quote">
local(x, y=2)<I>:type</I><BR>
global(x, y=2)<I>:type</I>
</BLOCKQUOTE><P>You can even mix the two ways:
</P><BLOCKQUOTE CLASS="quote">
local(x, y:<I>type2</I>=2)<I>:type1</I>
</BLOCKQUOTE><P>
will declare <I>x</I> to be of type <I>type1</I> and <I>y</I> of type <I>type2</I>.</P><!--TOC subsection Effect of types declaration on default values-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc12">3.3</A>  Effect of types declaration on default values</H3><!--SEC END --><P>Under GP, all GP variables start with a default value, which is <I>0</I> for a
local variable and <I>&#X2019;v</I> for a global variable <I>v</I>.</P><P>The <TT>gp2c</TT> compiler follows this rule for variables declared without a type.
However, when a variable is declared with a type, <TT>gp2c</TT> will not assign it a
default value. This means that the declaration <I>local(g)</I> is equivalent to
<I>local(g:gen=0)</I>, but not to <I>local(g:gen)</I>, <I>global(g)</I> is equivalent
to <I>global(g:gen=&#X2019;g)</I>, but not to <I>global(g:gen)</I>, and <I>f(g)=...</I> is
equivalent to <I>f(g:gen=0)=...</I>, but not to <I>f(g:gen)=...</I>.</P><P>This rule was chosen for several reasons:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
The default value (<I>0</I> or <I>&#X2019;v</I>) might not be an object suitable for
the type in question. For example, <I>local(v:vec)</I> declares <I>v</I> as being
of type <I>vec</I>. It would make no sense to initialize <I>v</I> to <I>0</I> since
<I>0</I> does not belong to type <I>vec</I>. Similarly <I>global(N:int)</I> declares
<I>N</I> as being of type <I>int</I>. It would make no sense to initialize <I>N</I>
to <I>&#X2019;N</I> since <I>&#X2019;N</I> does not belong to type <I>int</I>.</LI><LI CLASS="li-itemize">This allows defining GP functions with mandatory arguments.
This way, GP will issue an error if a mandatory argument is missing.
Without this rule, there is no way to tell apart <I>0</I> from a missing argument.</LI><LI CLASS="li-itemize">This allows telling <TT>gp2c</TT> not to generate useless default values.
</LI></UL><!--TOC subsection Type casting-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc13">3.4</A>  Type casting</H3><!--SEC END --><P>Sometimes, we know a more precise type than the one the transtyping algorithm
can derive. For example if <I>x</I> is a real number, its logarithm might be
complex. However, if we are sure <I>x</I> is positive, the logarithm will be
real.</P><P>To force an expression to belong to type <I>type</I>, use
the syntax:<BR>
<I>expr</I><I>:type</I><BR>
<TT>gp2c</TT> will check types consistency and output warnings if necessary.
For example<BR>
<I>f(x:int)=local(r:real); r=log(x^2+1)</I><BR>
<TT>gp2c</TT> will complain that the logarithm might not be real. Since <I>x^2+1</I>
is always positive, we can write:<BR>
<I>f(x:int)=local(r:real); r=log(x^2+1):real</I></P><!--TOC subsection Example of optimisation-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc14">3.5</A>  Example of optimisation</H3><!--SEC END --><P>Declaring the types of variables allow <TT>gp2c</TT> to perform some optimisations.
For example, the following piece of GP code</P><PRE CLASS="verbatim">
rho(n)=
{
  local(x,y);

  x=2; y=5;
  while(gcd(y-x,n)==1,
    x=(x^2+1)%n;
    y=(y^2+1)%n; y=(y^2+1)%n
   );
  gcd(n,y-x)
}
</PRE><P>generates the following output:</P><PRE CLASS="verbatim">GEN
rho(GEN n)
{
  GEN x = gen_0, y = gen_0;
  x = gen_2;
  y = stoi(5);
  while (gcmp1(ggcd(gsub(y, x), n)))
  {
    x = gmod(gaddgs(gsqr(x), 1), n);
    y = gmod(gaddgs(gsqr(y), 1), n);
    y = gmod(gaddgs(gsqr(y), 1), n);
  }
  return ggcd(n, gsub(y, x));
}
</PRE><P>The functions <FONT COLOR=purple>gsqr</FONT>, <FONT COLOR=purple>gaddgs</FONT>, <FONT COLOR=purple>gmod</FONT>, <FONT COLOR=purple>ggcd</FONT> are generic
PARI functions that handle <I>gen</I> objects. Since we only want to factor
integers with this method, we can declare <I>n</I>, <I>x</I>   <I>y</I> of type
<I>int</I>:</P><P><TT>rho(n</TT><TT><I>:int</I></TT><TT>)=<BR>
</TT><CODE><TT>{</TT></CODE><TT><BR>
</TT><CODE><TT>  local</TT></CODE><TT>(x</TT><TT><I>:int</I></TT><TT>,y</TT><TT><I>:int</I></TT><TT>);</TT>
</P><PRE CLASS="verbatim">  x=2; y=5;
  while(gcd(y-x,n)==1,
    x=(x^2+1)%n;
    y=(y^2+1)%n; y=(y^2+1)%n
   );
  gcd(n,y-x)
}
</PRE><P>The new C code output by <TT>gp2c</TT> is:</P><PRE CLASS="verbatim">GEN
rho(GEN n)        /* int */
{
  GEN x, y;       /* int */
  if (typ(n) != t_INT)
    pari_err(typeer, "rho");
  x = gen_2;
  y = stoi(5);
  while (gcmp1(gcdii(subii(y, x), n)))
  {
    x = modii(addis(sqri(x), 1), n);
    y = modii(addis(sqri(y), 1), n);
    y = modii(addis(sqri(y), 1), n);
  }
  return gcdii(n, subii(y, x));
}
</PRE><P>Now, the code now uses the more specific functions <FONT COLOR=purple>sqri</FONT>, <FONT COLOR=purple>addis</FONT>,
<FONT COLOR=purple>modii</FONT> and <FONT COLOR=purple>gcdii</FONT>.</P><P>The most efficient way to use typing is to declare some variables of type
<I>small</I>. This way, these variables will be implemented by C <FONT COLOR=purple>long</FONT>
variables, which are faster than PARI integers and do not require garbage
collecting. However, you will not be protected from integer overflow. For
that reason, <TT>gp2c</TT> will automatically declare some loop indices of type
<I>small</I> when the range cannot cause overflow. Sometimes <TT>gp2c</TT> can be too
conservative but you can force a loop index to be <I>small</I> with the syntax
<I>for(i:small=a,b,...)</I>.</P><!--TOC subsection Types and member functions-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc15">3.6</A>  Types and member functions</H3><!--SEC END --><P>For use with members functions, <TT>gp2c</TT> provides the following types:</P><DL CLASS="description"><DT CLASS="dt-description">
<B>nf</B></DT><DD CLASS="dd-description"> for ordinary number fields, i.e., a result given by the GP function <I>nfinit</I>.
</DD><DT CLASS="dt-description"><B>bnf</B></DT><DD CLASS="dd-description"> for big number fields, i.e., a result given by the GP function <I>bnfinit</I> which includes class and unit group data.
</DD><DT CLASS="dt-description"><B>bnr</B></DT><DD CLASS="dd-description"> for ray class groups, i.e., a result given by the GP function <I>bnrinit</I>.
</DD><DT CLASS="dt-description"><B>ell</B></DT><DD CLASS="dd-description"> for elliptic curves, i.e., a result given by the GP function <I>ellinit</I>.
</DD><DT CLASS="dt-description"><B>gal</B></DT><DD CLASS="dd-description"> for galois extensions, i.e., a result given by the GP function <I>galoisinit</I>.
</DD><DT CLASS="dt-description"><B>prid</B></DT><DD CLASS="dd-description"> for prime ideals, i.e., a component of the result given by the GP function <I>idealprimedec</I>.
</DD></DL><P>Members functions on typed objects are much more efficient.</P><!--TOC section Common problems-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc16">4</A>  Common problems</H2><!--SEC END --><!--TOC subsection Meta-commands.-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc17">4.1</A>  Meta-commands.</H3><!--SEC END --><P>Meta-commands (commands starting with a <CODE>\</CODE>) other than <CODE>\r</CODE> are
currently ignored by <TT>gp2c</TT>, though a warning will be issued, because it
is not clear what they should do in a compiled program. Instead you probably
want to run the meta-command in the GP session itself.</P><P>The meta-command <CODE>\r</CODE><I>include</I> is replaced with the content of the
file <I>include</I> (or <I>include</I>.gp) when <TT>gp2c</TT> reads the file.
If you would prefer <TT>gp2c</TT> to link <I>include</I>.so to the program instead,
see Section <A HREF="#compiled_in_new_program">2.4</A>.</P><!--TOC subsection Unsupported functions.-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc18">4.2</A>  Unsupported functions.</H3><!--SEC END --><P><A NAME="unsupported_funcs"></A></P><P>The functions <I>forell</I> and <I>forsubgroup</I> are currently not implemented as an
iterator but as a procedure with callbacks, which limits what you can do inside the
loop.</P><P>Some functions are passed to GP by <TT>gp2c-run</TT> at start-up (using the
<FONT COLOR=purple>GP;</FONT> syntax) instead of being translated in C: <I>install</I> and
<I>addhelp</I>. In practice, they can be considered as supported.</P><P>Some functions are built-in in GP, and so are not available to libpari
programs. So if you use them <TT>gp2c</TT> generate a program that needs to run under
GP, or with <TT>gp2c-run</TT>. Since the C prototype for those functions are not
available, the C compiler will output a warning. This serves as a reminder of
the problem. They are all the plotting functions and <I>allocatemem, default,
extern, input, quit, read, system, whatnow</I>.</P><P>Some GP functions are not available for C programs, so the compiler cannot
handle them. If you use them you will get the infamous "unhandled letter in
prototype" error. Sorry for the inconvenience. These are
<I>plot, ploth, plotrecth</I>.</P><P>Also the functions <I>read, eval, kill</I> may compile fine but have a
surprising behaviour in some case, because they may modify the state of the GP
interpreter, not of the compiled program. Please see
Section <A HREF="#global_variables">4.3</A> for details. For example
<CODE>f(n)=eval("n^2")</CODE> is very different from <CODE>f(n)=n^2</CODE>.</P><P>The <I>forstep</I> function is supported when the step is a number. If
it is a vector, you must add a tag <I>:vec</I> to make GP know about it like in</P><PRE CLASS="verbatim">f(x)=
{
  local(v);
  v=[2,4,6,6,6,6,6,2,4,6,6]
  forstep(y=7,x,v:vec,print(y))
}
</PRE><P>This is not needed if the step is a vector or a variable of type vec,
but is needed if the step is only an expression which evaluates to a vector.</P><P>There is little that can be done about these problems without changing PARI/GP
itself.</P><!--TOC subsection Memory handling and global variables.-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc19">4.3</A>  Memory handling and global variables.</H3><!--SEC END --><P><A NAME="global_variables"></A></P><P>While a lot of work has been done to ensure that <TT>gp2c</TT> handles global
variables properly, the use of global variables is still a lot of trouble, so
try to avoid them if you do not understand the implications on memory handling.</P><P>First, there is a common practice to use undeclared variables as formal
variables, for example we assume <I>x=&#X2019;x</I> and write <I>a*x+b</I> instead of
<I>a*&#X2019;x+b</I>. So <TT>gp2c</TT> will not raise an undeclared variable to the rank of
global variable unless you declare it with the <I>global()</I> command, or you
use it at toplevel (i.e. outside any function). See also
Section <A HREF="#find_errors">2.3</A></P><P>Second, global variables seen by a compiled function are C variables, not GP
variables. There is no connection between the two. You may well have two
variables with the same name and a different content. Currently GP knows only
how to install functions, not variables, so you need to write compiled
functions in order to access global variables under GP.</P><P>Basically, global variables are allocated in the main stack which is destroyed
each time GP prints a new prompt. This means you must put all your commands on
the same line. Also global variables must be initialized using the
<I>init_</I><CODE>&lt;filename&gt;</CODE> function before being used, and are only supported
with the -g flag.</P><P>So you end up doing
<B>gp2c-run -g global.gp</B>
</P><PRE CLASS="verbatim">parisize = 4000000, primelimit = 500000
? init_global();myfunction(args);
</PRE><P>Note that nothing prevents you from calling <I>init_global</I> in the GP
program. In that case, you can omit the parentheses (i.e, write
<I>init_global</I>, not <I>init_global()</I>) so that you can still run your
noncompiled program.</P><P>Another way to handle global variables is to use the <I>clone</I> function which
copies a PARI object to the heap, hence avoids its destruction when GP
prints a new prompt. You can use <I>unclone</I> to free a clone. Please read the
PARI/GP manual for more information about <I>clone</I>.</P><P>A good use of <I>clone</I> is for initializing constant variables:
for example in <TT>test/gp/initfunc.gp</TT>, the vector <I>T</I> is initialized by
</P><PRE CLASS="verbatim">T=clone([4,3,2,2,1,1,1,1,0,0,0,0,0,0,0,0])
</PRE><P>You must still run the <I>init_</I><CODE>&lt;filename&gt;</CODE> after starting GP, but after
that you can use <I>T</I> safely.</P><P>GP itself currently does not know about <I>clone</I> and <I>unclone</I>, but you
can use dummy functions
</P><PRE CLASS="verbatim">clone(x)=x
unclone(x)=while(0,)
</PRE><P>when running uncompiled.</P><!--TOC subsection GP lists-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc20">4.4</A>  GP lists</H3><!--SEC END --><P>GP lists are not fully supported by <TT>gp2c</TT>. A partial support is available
with the <I>list</I> type. You must tell <TT>gp2c</TT> that a variable will contain a
list by using <I>L:list</I> inside a declaration, where <I>L</I> is the name of the
variable as explained in Section <A HREF="#advanced">3</A>.</P><P>Currently, assigning to a list element (<I>L[2]=x</I>) will not work and lists
will not be freed unless you explicitly use <I>listkill</I>.</P><P>Note: The PARI user&#X2019;s manual states that lists are useless in library mode.</P><!--TOC subsection The <I>install</I> command-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc21">4.5</A>  The <I>install</I> command</H3><!--SEC END --><P>The <I>install</I> command is interpreted as a <TT>gp2c</TT> directive. This allows
using installed function in compiled programs, see
Section <A HREF="#compiled_in_new_program">2.4</A>.</P><P>However this has some side-effects:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
If present, the <I>lib</I> argument must be a string, not an expression that
evaluate to a string.
</LI><LI CLASS="li-itemize">The <I>install</I> command is not compiled, instead it is added to the list
of functions to install.
</LI></UL><!--TOC section Command-line options of <TT>gp2c</TT>-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc22">5</A>  Command-line options of <TT>gp2c</TT></H2><!--SEC END --><P>Here is a brief description of the main options of <TT>gp2c</TT>, which can be
seen with <TT>./gp2c -h</TT>.</P><P>In Section <A HREF="#compile_and_run">2.1</A> we saw how to use the <TT>-g</TT> option.
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
-g tells <TT>gp2c</TT> to generate <FONT COLOR=purple>gerepile</FONT> calls to clean up the
PARI stack and reduce memory usage. You will probably need this option,
although the C code will be easier to read or hand-edit without it.</LI><LI CLASS="li-itemize">-o<I>file</I> tells <TT>gp2c</TT> to write the generated C file
to the file <I>file</I> instead of the standard output.</LI><LI CLASS="li-itemize">-iN allows you to change the indentation of the generated C
file. So if you want 4 spaces, just use the <TT>-i4</TT> option with
<TT>gp2c</TT>. The default is 2.</LI><LI CLASS="li-itemize">-W is useful for debugging the .gp file, in the sense
that it detects if some local variable is undeclared. For
example, if the file <TT>algorithm.gp</TT> has a routine like<PRE CLASS="verbatim">radical(x)=F=factor(x)[,1];prod(i=1,length(F),F[i])
</PRE><P>The variable &#X2019;F&#X2019; is undeclared in this routine, so when running
<TT>gp2c</TT> with the <TT>-W</TT> option it prints</P></LI><LI CLASS="li-itemize">-C adds code to perform range checking for GP constructs like
<I>x[a]</I> and <I>x[a,b]</I>. This also checks whether <I>x</I> has the
correct type. By default <TT>gp2c</TT> does not perform such check, which can
lead to a runtime crash with invalid code. This option causes a small
runtime penalty and a large C code readability penalty.<P><B>Warning:algorithm.gp:1:variable undeclared F</B></P><P>At present, an undeclared variable is taken to be a "formal variable" for
polynomials by <TT>gp2c</TT>, so do not declare it if that is what you intend.
For example in <CODE>pol(a,b,c)=a*x^2+b*x+c</CODE> you must not declare <I>x</I> since
it stands for the formal variable <I>&#X2019;x</I>.</P></LI><LI CLASS="li-itemize">-p<I>prefix</I> A problem with C is that it is subject to name clashes,
i.e., if a GP variable in your routine has the same name as a C symbol
in the pari library, the compiler will report strange errors. So this option
changes ALL user variables and user routine names by adding a prefix
<I>prefix</I> to them. For example the GP routine <I>add(x,y)</I> with <B>-pmy_</B> will become the C function <FONT COLOR=purple>my_add(x,y)</FONT>.<P>Try this option each time the compiler fails to compile <TT>gp2c</TT> output to
see if there is a name conflict. If this is the case, change the name
in your GP script.
It may be difficult to find conflicting names if your compiler is not verbose
enough and if you are not familiar with the PARI code and C in general.</P><P>Example of conflicting names are <FONT COLOR=purple>top</FONT>,<FONT COLOR=purple>bot</FONT>,<FONT COLOR=purple>prec</FONT>,<FONT COLOR=purple>un</FONT>,
but there are thousands of others and they may be system-dependent.</P></LI><LI CLASS="li-itemize">-s<I>suffix</I>: Add <I>suffix</I> to the names of the installed
functions under GP. This is to avoid clashes with the original GP script. For
example, if you want to compare timings you may want to use the option
<B>-s_c</B> This does not affect the C code, only the <I>install</I> commands.</LI><LI CLASS="li-itemize">-S: Assume strict prototypes for functions. This means that you
have declared all the local variables with <I>local</I> and not as parameters.
Also, when a parameter is not mandatory, a default value must be assigned to
it in the declaration, like for &#X2019;flag&#X2019; in
<PRE CLASS="verbatim">test(data,flag=0)={CODE}
</PRE>This does not affect the C code, only the <I>install</I> commands.</LI><LI CLASS="li-itemize">-h gives the help.</LI><LI CLASS="li-itemize">-v gives the <TT>gp2c</TT> version.</LI><LI CLASS="li-itemize">-l prints a list of all the GP functions known by the
compiler. So if a routine contains a GP routine not on this list, <TT>gp2c</TT>
will show an error when trying to translate it. For example the routine
<I>forvec</I> is not yet implemented, so you should not use it.<P>Reasons why a GP function may not be known by the compiler are:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">The function is not part of the PARI library. See
Section <A HREF="#unsupported_funcs">4.2</A></LI><LI CLASS="li-itemize">You use the old PARI 1.39 function names instead of the new ones.
<TT>gp2c</TT> currently does not know about the &#X2019;compat&#X2019; default. Use
<I>whatnow</I> under GP to get the current name. For example, <I>mod()</I> is now
<I>Mod()</I>.</LI><LI CLASS="li-itemize">You use a GP function that does not exists in the GP version <TT>gp2c</TT>
was compiled against. Please recompile <TT>gp2c</TT> against this GP version.<P>Normally no functions are added between two stable releases of GP with the same
minor version number (say 2.1.1 and 2.1.2) so there is no need to recompile
<TT>gp2c</TT> when you upgrade. But if you use the developement versions, you
need to recompile. Also some new developement versions may break old
versions of <TT>gp2c</TT>, so upgrade gp2c at the same time.</P><P>However, if you want to compile scripts which do not use the new functions,
you do not need to recompile. Note that you may use the GP environment
variables to tell <TT>gp2c-run</TT> which GP to use.</P></LI><LI CLASS="li-itemize">-t Output the table of types known to the compiler, see
Section <A HREF="#advanced">3</A>.</LI></UL></LI></UL><!--CUT END -->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
</EM><A HREF="http://hevea.inria.fr/index.html"><EM>H</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>V</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>A</EM></A><EM>.</EM></BLOCKQUOTE></BODY>
</HTML>
pari-gp2c 0.0.8-1 / usr / share / doc / pari-gp2c / gp2c.html
