- GiNaC-list - ginac.de

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 20 Jul '06

20 Jul '06

Or: Why GiNaC builds have not been straightforward It turns out that when the configure script tests for the existence of a usable readline function, it specifies -lreadline but not -ltermcap or the "curses" library, but modules in the readline static library apparently call functions that are not resolved by the linker. Those references are resolvable with the termcap library. (Readline installation documentation seems to say that the curses library can be used as an alternative to the termcap library.) A simple test program links quite well when both -readline and -ltermcap are properly specified. And by extracting the three object modules in libtermcap.a and inserting them in libreadine.a and by using this expanded libreadline.a, I was able to get the "make", "make check", and "make install" procedures to proceed without any need for modification of Makefiles; I did specify "--prefix=..." on the configure command line. (However, I did have to restart "make" because of errors due to timing out of subprocesses when the computer was put into hibernation; but there appears to be no deleterious effect as a result, and I had to copy my modified ginsh/ginsh_parser.cc from a previous build and either Sheplyakov's patched or my patched check/timer.h and check/timer.cpp as well as ginac/indexed.cpp with the assertion at line 701 commented out, and also Sheplyakov's patched "check/exam_archive.cpp".) Note that there seems to be no problem with unsatisfied "termcap" references when using the libreadline.5.dll and libhistory.5.dll that's created in the readline build, but of course, the configure script looks for libreadline.a, not libreadline.5.dll . One must manually modify ginsh/Makefile in order to use the .dll . So it would seem that the configure script should be modified to insert a -ltermcap or -lcurses (if that's the right name) -- or both (?) -- in the linker command line to test for readline, depending on what the script has found by prior tests -- or simply leave it a -lreadline only if neither of these extra libraries is found. If the unsatisfied references would never be needed for program flow, perhaps an option could be added to the linker command line to allow unresolved references (if there is such an option), or perhaps both -ltermcap and -lcurses could be specified along with an option to simply allow multiply-defined symbols and thus perhaps avoid any logic/decision-making fuss over which library should be used. These are just suggestions as to possibilities; I'm not familiar with the details here. Surprisingly, the unmodified ginsh/Makefile does put both -lreadline and -ltermcap on the linker command line to build ginsh. So it seems that -ltermcap was probably just inadvertently omitted in the configure script to test for the readline function. And incidentally, this supposed need for termcap seems to be counter to a comment and patch by Sheplyakov Alexei to the effect that termcap is being phased out; the details of this I'm not familiar with. Also, I used none other of Sheplyakov's and my patched files in GiNaC for this test run than those I specifically mentioned above as needing to be copied from a previous build. As for design of the configure script, it seems best that it should set the readline macros in config.h based on the headers found, regardless of whether a usable readline function is found. That would tend to simplify any debugging and manual adjustments needed when such a usable readline function is not found. But of course this would depend on the likelihood of various problematical states/scenarios when a usable readline function is not found. Incidentally, quite a bit of manual intervention, especially Makefile modification, was needed in building the readline/history libraries. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Python wrapper for a GiNaC derived library
by Vladimir Kisil 20 Jul '06

20 Jul '06

Dear All, Recently Daniel Seidel produced a Python wrapper for my "cycle" library announced here on Wed Dec 28 11:16:33 CET 2005. The wrapper is based on the pyGiNaC (http://sourceforge.net/projects/pyginac/) and is an example how a derived GiNaC libraries may be used in the interactive mode. The wrapper can be found here: http://www.maths.leeds.ac.uk/~kisilv/pycycle.html If you are curious what cycles are, then an easy-reading (I hope ;-) overview is here (http://arxiv.org/abs/math.GM/0607387) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 1

well, here's the latest story on recursive grep
by Richard Haney 19 Jul '06

19 Jul '06

Effective recursive search with grep seems to be an important skill when trying to debug CLN and GiNaC. I tried a bit more searching on the Internet and tried a few more combinations with my existing versions of grep. Many of the alternative work-arounds posted on the Internet do not work very well. But I finally found a usage scheme that seems to work fairly well for recursive grep. I have four versions of grep on my computer and only cygwin grep seems to work reasonably well, provided one __guesses__ at the right combination of arguments. Here's what I've learned -- so you won't have to do such a horrendous amount of guessing. Here's a generic example of the usage of cygwin grep that works: grep -r --include="*.cc" --include="*.cpp" "Illegal number syntax" * Here's the command & output in a cygwin bash shell in working directory /cygdrive/c/gnu/cln-1.1.11/src: $ grep -r --include="*.cc" --include="*.cpp" "Illegal number syntax" * base/input/cl_read_err_bad.cc: fprint(std::cerr, "Illegal number syntax: \""); base/input/cl_read_err_bad.cc--debug.cpp: fprint(std::cerr, "Illegal numbe r syntax: \""); base/input/cl_read_err_bad.cc--original_now_in_effect.cpp: fprint(std::cerr , "Illegal number syntax: \""); (Note that I labeled backup copies with a .cpp extension because "CLN make" in this area sweeps up any existing file with extension .cc for inclusion in the library.) Using the option "--directories=recurse" in place of "-r" produces the same output. But note that while "grep -r "Illegal number syntax" *" searches _all_ files in the hierarchy and produces the output: base/input/cl_read_err_bad.cc: fprint(std::cerr, "Illegal number syntax: \""); base/input/cl_read_err_bad.cc--debug.cpp: fprint(std::cerr, "Illegal numbe r syntax: \""); base/input/cl_read_err_bad.cc--original_now_in_effect.cpp: fprint(std::cerr , "Illegal number syntax: \""); Binary file cl_read_err_bad.o matches Binary file cl_read_err_bad.o--comment out for debugging.oxx matches , the more specific command "grep -r "Illegal number syntax" *.cc" fails to produce the desired output, but instead we get: grep: *.cc: No such file or directory And, therefore to be expected, "grep -r "Illegal number syntax" *.cc *.cpp" fails in the same way: grep: *.cc: No such file or directory grep: *.cpp: No such file or directory Of my four versions of grep, only cygwin grep has the "--include=..." option. MinGW's msys grep does not have that option, and moreover, MinGW's msys grep has the same problem that cygwin grep has with the similar command: "c:/msys/1.0.8/bin/grep.exe" -r "Illegal number syntax" *.cc Version information: Executing the cygwin grep command "grep -V" produces the output "grep (GNU grep) 2.5" along with (gnu) copyright and (non-) warranty information. This grep was packaged in a cygwin setup.exe file that yielded an intermediate-expansion file (among many) with name "release\grep\grep-2.5-1.tar.bz2" along with a parallel intermediate-expansion file of "release\cygwin\cygwin-1.3.20-1.tar.bz2". Happy debugging! Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: ginac parsing from string issue (hopefully nailed!)
by Richard B. Kreckel 18 Jul '06

18 Jul '06

Francesco Biscani wrote: >I hope this can somehow be useful. I don't think I should open a bug against >gcc, since apparently in gcc-4.1.2pre the problem seems to be solved. > > Since things seem to point to aliasing problems in the bison-generated files, I became suspicious to my previous statement about gcc-4.1.2pre fixing the problem. Turns out, that statement was wrong. Gcc4.1.2pre is the current compiler in Debian/testing. Using that compiler and a fresh GiNaC 1.4 from CVS with one of the containter patches, I've just built a library where parsing is still broken. It appears like the GiNaC library in Debian/testing was compiled with an older compiler and not rebuilt since the compiler was upgraded, since there, parsing works as expected. Sorry -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 18 Jul '06

18 Jul '06

Building ginac has been a horrendous, labyrinthine exercise, and I finally have a successful build and "make check". It was not the "breeze" that Sheplyakov Alexei seems to think it is. Sheplyakov Alexei wrote: > I've attached two patches. [...] > Second one is for GiNaC 1.3 ("backport" from 1.4 branch) -- it contains > *all* changes which make GiNaC compile on MinGW. I created a fresh, alternate build hierarchy and ran patch.exe using Sheplyakov's "ginac_1.3_mingw32.diff". I had to do several fresh starts of ginac from .tar.bz2 to find out a workable use of the patch. I have no cygwin patch program, but the one I found is from my mingw "msys" basic file utilities "bin". However, it seems that this patch.exe does not know how to handle relative pathnames. It tried to modify the root directory's "Makefile.am" instead of "check/Makefile.am". I also found that modifying "configure.ac", "acinclude.m4", and "Makefile.am" with the patch resulted in a need apparently for autoconf and perl, and, And moreover, the patch for "ginsh/ginsh_parser.yy" resulted in a need for yacc. And among other concerns, I did not have ready access to the Internet at the time to search for these extra resources, and I was reluctant to go rummaging around on my disc drive for old versions. Since it appears that the patches for the root directory's "configure.ac" and "acinclude.m4" are only concerned with extra checking for resources for ginsh, I figured I could safely skip those patches because I was already able to build "ginsh.exe" in a previous attempt. But it looked like the patch for "check/Makefile.am" might be crucial; so I used the context information in that patch to manually modify "check/Makefile" rather than to patch "check/Makefile.am". Also, the patch for "ginsh/ginsh_parser.yy" seemed to be concerned only with the issues I had dealt with when I earlier modified "ginsh/ginsh_parser.cc". So I used my earlier-modified "ginsh/ginsh_parser.cc" rather than to patch and use "ginsh/ginsh_parser.yy". So that eliminated any need for yacc. There are a few other facts that might be useful to note here. This time, in an effort to discover the "breezy" approach to building ginac as Sheplyakov suggests, I did not bother to do the "commenting out" of my make.exe for the run of configure. Evidently, configure adjusted the Makefiles slightly and accordingly from what they would have been otherwise, and no problem seemed to arise from this fact. I discovered that symbolic links (to readline headers) in a "readline" subdirectory of my standard system "include" directory was sufficient for configure to find the headers, and I discovered that even with this "readline" "commented out", configure/gcc/g++ was able to find the headers with environment variable CPLUS_INCLUDE_PATH set in my .bash_profile, in this case, as follows: export CPLUS_INCLUDE_PATH=C:/gnu/readline-5.1/gcc342/include (At the moment I am partial to the idea of keeping installations as part of the original build hierarchy by, for example, adding a subdirectory "gcc342" as the root of an installation, based in this case, on gcc 3.4.2. And so, for example, I would like to be able to tell configure by use of an environment variable where to find my relevant libraries, rather than to "dump" all my libraries into a common directory.) But I could not get configure/gcc/g++ to find my libraries by use of export LIBRARY_PATH=".:/cygdrive/c/gnu/cln-1.1.11/gcc342/lib:/cygdrive/c/gnu/readline-5.1/gcc342/shlib:/cygdrive/c/gnu/readline-5.1/gcc342/lib:" in accordance with the gcc manual. This is supposed to be a colon-delimited list of directories much like PATH; so use of "C:" to start a pathname (as gcc seems to prefer) would conflict with the use of the colon as delimiter. I tried all sorts of combinations of quotes in order to use "C:", but nothing seems to work here. So configure steadfastly "refused" to find my readline binary libraries -- even when I "dumped" all the readline headers and binaries into my main development hierarchy. So I had to manually modify ginsh/Makefile as I had done before to point to my "libreadline.5.dll". (I suppose I may not have restarted cygwin bash; cygwin bash seems to "remember" where files are found (or not found), and restarting cygwin bash sometimes seems necessary to refresh its memory.) Moreover, even though configure found my readline headers, it refused to adjust config.h accordingly; I had to use my previously modified config.h here as well. I am also wondering about "manual" installation of CLN (& GiNaC). It seems that cln-config did not get copied to the "bin" directory in the installation hierarchy; so I copied it manually, using Windows Explorer "copy-and-paste" as I have done for some other installations; that seemed to satisfy configure. And it is a puzzle to me why configure looks for "cln-config"; when I modify Makefiles, simply listing -lcln (with appropriate "-L" options) or its full pathname seems sufficient; so why should "cln-config" be of any concern to configure? But I somehow get the impression that there my be important, mysterious things going on with a "make install" (and the build process in general) that may be escaping my attention. Can anyone provide some general comments on when it is safe to do a manual "copy-and-paste" installation? Incidentally, manually modifying files (such as cln-config or ginac-config) can trigger all sorts of frightful rebuilds when running make. Such manual modification is tempting in order to avoid the rather time-consuming and seemingly inflexible rerun of configure that the instructions suggest for changing the "--prefix=..." information. But the "--prefix=..." information resulting from configure seems to be peppered throughout the build hierarchy; so that idea of modifying each such relevant file (and perhaps restoring its time-stamp) seems horrendous. I am still a bit confused as to what in entirety it going on with installations, especially those that have been built using libtool; and I'm still also a bit confused as to what libtool does in its entirety. Does the build process really have to be so complicated and obscure? Those ginac Makefiles are really horrendous to try to trace through. As before, the relevant system specs are: OS: Windows XP gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 15 Jul '06

15 Jul '06

Here is another error, this time dealing with archiving, along with some additional, important, but non-critical issues. In response to "Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701", Chris Dams wrote: > I would say that you can quite safely just delete this assertion. Thanks for the post. I commented out the assertion at line 701 in indexed.cpp and rebuilt the library and ran "make checks". Here are the relevant parts of the relevant output files: output from the "make check-TESTS" part of "make check" output: <begin quote> [...] examining miscellaneous other things........ passed Error: something went wrong. (one failure) please check exams.out against exams.ref for more details. happy debugging! ./exams.ref exams.out differ: char 707, line 30 FAIL: run_exams [...] ====================================== 1 of 3 tests failed Please report to <ginac-list(a)ginac.de> ====================================== <end quote> relevant part of "exams.out" (from line 29 to end): <begin quote> ----------archiving system: archiving/unarchiving 42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x+(2.4275000000000002132)*eps~y~*0+(gamma~mu*gamma.mu)*x.(1+2*y)~(-mu)*(I*f.x.y.2+d.x.y.2)*T.x+delta.(delta.x.($7)*[[-1,0,0],[0,Euler,0],[0,0,atan(y^(-1)*x==-15/17*I)]])~(ONE*{x,-11*y,(acos(6-10*I))+(-(26/3725-48/3725*I)*sqrt(65+120*I))*(-3+5*I+x)+((17364/13875625-652/13875625*I)*sqrt(65+120*I))*(-3+5*I+x)^2+Order((-3+5*I+x)^3)}*g~2~(log(cos((128.0)*y^(-1)*x^(-1)))))+((abs(y))+(D[0](abs)(y))*(-y+x)+(1/2*D[0,0](abs)(y))*(-y+x)^2+(1/6*D[0,0,0](abs)(y))*(-y+x)^3+Order((-y+x)^4)) erroneously returned 42*y^sin(Catalan*y)*ONE*eps.(1/2*y).0.(FAIL)*x ----------structure template: (no output) ----------hash maps: (no output) ----------miscellaneous other things: (no output) <end quote> Could it be that the failure here is due to GiNaC's use of CLN's io functions and specifically is a result of a bug indicated in CLN's "test_I_io" failure as described in my previous post "[GiNaC-list] Results of GiNaC (& CLN) builds" at http://www.ginac.de/pipermail/ginac-list/2006-July/000857.html ? Additional issues: 1. Note that "cd .libs && rm -f libginac.la && ln -s ../libginac.la libginac.la" does not result in a new link file when rebuilding the library. (Output: "ln: `libginac.la': File exists".) I had to manually delete the link file (using Windows Explorer), whose full name is "libginac.la.lnk" and which seems to be the same thing as a "Windows shortcut". Only execution of "dir lib*" in Windows' "command prompt" shell reveals the complete name; "ls lib*" in cygwin bash only reveals the name "libginac.la" with an arrow ("->") to the referenced file. Nor does Windows Explorer reveal the full name even though I have "display filename extensions" turned on. (This comment applies similarly to the symbolic link "libcln.la.lnk" in the CLN build.) 2. The Makefile for building libginac.a does not seem to have the correct dependency information for the dependency of libginac.a on "indexed.cpp". I had to resort to manually deleting all known occurrences of "indexed.o", "indexed.lo", "indexed.Plo", "libginac.a", "libginac.la", "libginac.la.lnk", and "libginac.lai" in order to get the new version of indexed.cpp implemented in "libginac.a". (Conceivably, this may have something to do with "rm -f libginac.la" not being effective, as described in note 1 above. On a seemingly related note, it also seems that the Makefiles are confused about whether executables have an .exe extention. For example, the "clean" target in the "cln-1.1.11\tests" Makefile has command a line "$(RM) *.s *.o *.a exam tests main a.out core"; however, the Makefile in "ginac-1.3.4\ginsh" _does_ seem to account for the .exe extension in target "clean-binPROGRAMS". It has often seemed though that executables get automatically remade (in CLN and/or GiNaC) even though nothing has changed when rerunning make. I surmise that this may be due to incorrect specification of dependencies as to the .exe extensions. 3. There is some doubt in my mind whether symbolic links in cygwin bash work properly. I seem to recall trying to use a symbolic link a few years ago and found that I had to resort to simply copying the target file to replace the link. But I have not played with symbolic links in "standard" unix, so I don't know whether I was simply trying to use them incorrectly. 4. Now that a satisfactory build of libginac.a seems to be within view, I'd like to get a "shared" (.dll) version of both "libcln.a" and "libginac.a", but even though I think I am following directions for getting shared libraries, I don't seem to be getting them. A typical make output (for both CLN and GiNaC) that may have something to do with this is "libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries". Note that "cygwin" is only relevant by virtue of my using cygwin bash (& cygwin "sed", "ln", "mkdir', "rm", and perhaps some other minor tools that have escaped my attention). All of my essential build tools (except sed, etc.) -- i.e., gcc 3.4.2 and associated tools and runtime libraries -- are "mingw" tools or what is supplied with the CLN/GiNaC packages. The "mingw" tools bin appears earlier in PATH than does the cygwin bin. I surmise that, except where I specify otherwise more specifically, all of the runtime library paths are determined by gcc (or g++) relative to the location of the gcc/g++ bin. As before, the relevant system specs are: OS: Windows XP gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Richard Haney P.S.: Thanks to Sheplyakov Alexei for his posts. I have looked at them and will look at them some more, but they are not in a form that I can readily make use of. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: ginac parsing from string issue (hopefully nailed!)
by Francesco Biscani 13 Jul '06

13 Jul '06

On Tuesday 11 July 2006 20:36, you wrote: > Please have a look at the ginac-list mailing list archives: The problem > has been traced to be in an interaction with the bison-generated file > with gcc 4.1.x. Hi Richy, I've followed the list's suggestion but unfortunately upgrading from bison-2.2 to bison-2.3 (and recompiling gcc+cln+ginac) did not solve the issue for me. However, one post in the list mentioned that turning off optimizations made the issue disappear. So I made a bisect search for the faulty gcc optimization starting from -O1 (where the problem was not present) to -O2, recompiling ginac each time. According to this, the optimization that causes the problem is "-fstrict-aliasing". Then I recompiled ginac with -O1 plus all the additional optimizations of -O2 (according to gcc man page) _excluding_ "-fstrict-aliasing". Now the test program runs properly :) I hope this can somehow be useful. I don't think I should open a bug against gcc, since apparently in gcc-4.1.2pre the problem seems to be solved. Suggestions are welcome... Thanks for all the help guys, now I can go back to coding :) Regards, Francesco -- Dr. Francesco Biscani Dipartimento di Astronomia Università di Padova biscani(a)pd.astro.it

4 6

Three "make check-TESTS" failures under Windows XP (with mingw tools)
by Richard Haney 12 Jul '06

12 Jul '06

It occurs to me that a more specific title is especially important since there seems to be no keyword search capability for the archives. With this post the above title should provide additional, more-specific linkage to the following post under the title "[GiNaC-list] Results of GiNaC (& CLN) builds": http://www.ginac.de/pipermail/ginac-list/2006-July/000857.html Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [GiNaC-list] Re: math-polyglot (fwd)
by Chris Dams 12 Jul '06

12 Jul '06

Dear Vladimir and Jens, @Jens: Yes, I saw it as well. In fact, I already sent correctly packaged solutions. I also noticed that I completely overlooked the convex-hull problem. It does not seem to be so difficult to write a function for that, so if I feel like it I may do that. On Wed, 12 Jul 2006, Vladimir V Kisil wrote: > Daniel Seidel is now working on adding drawing facilities to GiNaC > (through the Asymptote package) as a part of his summer project. There > is a hope that the working code will be obtained by the end summer. In > this case both the parabola and the saddke may be easily drawing. That sounds like a very good idea. I'm afraid though that they will want to produce their DVD a bit earlier. Well, when these plotting routines are ready, I suppose I can always ask whether it can still be included. > Meanwhile my GiNaC library "cycle" which was announced here about seven > months ago can draw circles, parabolas and hyperbolas. I just had a look at it. I suppose I could draw a polynomial from an object of type cycle with k=1, l=(0,1/2) and a metric of diag(1,0). Is that right? It strikes me as not really what I would like to show someone as a way of drawing a function. > PS Are we allowed to add (or at least suggest) few examples of things > where GiNaC is good (and other CAS are not), otherwise it looks like a > misrepresentation. Not sure. Didn't ask. I agree that the problem set looks a bit random and really not very interesting. Best wishes, Chris

1 0

Re: math-polyglot (fwd)
by Chris Dams 12 Jul '06

12 Jul '06

Dear all, For the international conference on mathematical software (http://www.icms2006.unican.es/) I was invited to show how some problems (http://fe.math.kobe-u.ac.jp/nobuki/DVD1/cdrom/icms2006/math-polyglot/toc.ht…) could be solved using GiNaC. Below you find the mail that I sent as an answer. If somebody here can think of better solutions to the problems, please post a message. Best wishes, Chris ---------- Forwarded message ---------- Dear Nobuki, Below are solutions to the problems, insofar GiNaC addresses them. Best wishes, Chris 1+2: Type into ginsh: 1+2; Answer: 3 integral(sqrt(1-x^2)): Symbolic integration is rather limited in GiNaC. It can only integrate polynomials. Fourier transform of exp(-x^2): same. Subgroups of S_5: GiNaC does not have functions to handle this kind of group theory problem. 4*arctan(1): Type into ginsh: 4*atan(1); Answer: Pi Drawing a parabola: GiNaC does not have graphics capabilities. It would be possible to do the numerics in GiNaC and let the plotting handle by some other library/utility. Drawing a saddle: same Define a function and load it: //////////////////////////// // Header file "myfun.h": // //////////////////////////// #include<ginac/ginac.h> GiNaC::ex myfun(const GiNaC::ex &x, const GiNaC::ex &y); //////////////////////////////////// // Implementation file "myfun.C": // //////////////////////////////////// #include "myfun.h" using namespace GiNaC; ex myfun(const ex &x, const ex &y) { return x+y; } /////////////////////// // Main file: test.C // /////////////////////// #include <iostream> #include <ginac/ginac.h> #include "myfun.h" using namespace std; using namespace GiNaC; int main() { cout << myfun(1,2) << endl; return 0; } Compiling myfun: g++ -O2 `ginac-config --cppflags` -c myfun.C Compiling main: g++ -O2 `ginac-config --cppflags` -c test.C Linking the two: g++ `ginac-config --libs` -o test test.o myfun.o Running: ./test Output: 3 Syllogistic: GiNaC does not have functions for logic. We can, however, write a function to test all posibilities in the thruthtable. Program: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; symbol True("True"); symbol False("False"); // Declare that implies is a GiNaC-function of two parameters. DECLARE_FUNCTION_2P(implies); // Automatic evaluation of implies in case that sufficiently many of the // paramters are given as "True" and "False" in order to know the result; // If not enough parameters are given, return the expression implies(x, y). ex implies_eval(const ex &x, const ex &y) { if (x==False) return True; if (x==True) if (y==False) return False; else if (y==True) return True; // The .hold() indicates that this result should not be further evaluated. return implies(x, y).hold(); } // Declare that the just-defined function is used for the evaluation of // the function implies. REGISTER_FUNCTION(implies, eval_func(implies_eval)); // Check if the expression x evaluates to True for any combination of // True/False substitued for the subexpressions given in l. bool check_truth(const ex &x, const lst &l) { // Get the size of l. int num_expr = l.nops(); // The number of possibilities to check. unsigned possibs = 1 << num_expr; // Loop over the possibilities to assign true and false to num_expr // subexpressions. for (unsigned i=0; i<possibs; ++i) { exmap m; // To store by what the subexpressions are going to be replaced. for (int j=0; j<num_expr; ++j) m[l.op(j)] = i&(1<<j) ? True : False; // Evaluate the expression for this particular posibility. ex result = x.subs(m); if (result != True) return false; // This is a C++ boolean, not ours. } return true; // This is a C++ boolean, not ours. } int main() { symbol P("P"); symbol Q("Q"); symbol R("R"); ex syllogistic = implies(implies(P,Q), implies(implies(Q,R), implies (P, R))); bool holds = check_truth(syllogistic, lst(P,Q,R)); if (holds) cout << syllogistic << " holds." << endl; else cout << syllogistic << " does not hold." << endl; return 0; } Output: implies(implies(P,Q),implies(implies(Q,R),implies(P,R))) holds. Powers of a matrix: In ginsh: > evalm( [[0,1],[1,1]] ^ 1 ); [[0,1],[1,1]] > evalm( [[0,1],[1,1]] ^ 2 ); [[1,1],[1,2]] > evalm( [[0,1],[1,1]] ^ 3 ); [[1,2],[2,3]] > evalm( [[0,1],[1,1]] ^ 4 ); [[2,3],[3,5]] > evalm( [[0,1],[1,1]] ^ 5 ); [[3,5],[5,8]] > evalm( [[0,1],[1,1]]^1 * [[1],[1]] ); [[1],[2]] > evalm( [[0,1],[1,1]]^2 * [[1],[1]] ); [[2],[3]] > evalm( [[0,1],[1,1]]^3 * [[1],[1]] ); [[3],[5]] > evalm( [[0,1],[1,1]]^4 * [[1],[1]] ); [[5],[8]] > evalm( [[0,1],[1,1]]^5 * [[1],[1]] ); [[8],[13]] Kernel of an integral matrix: Program: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { matrix m(2, 4); m = 1, 1, 1, 1, 0, 2, 4, 5; symbol x1("x1"), x2("x2"), x3("x3"), x4("x4"); matrix unknowns(4,1); unknowns = x1, x2, x3, x4; matrix rhs(2,1); rhs = 0, 0; cout << m.solve(unknowns, rhs) << endl; return 0; } Output: [[x3+3/2*x4],[-2*x3-5/2*x4],[x3],[x4]] Draw a graph of the Lorentz equation: Not sure what advantage GiNaC could bring here. No need for arbitrary precision arithmetic and GiNaC does not have plotting facilities. Elimination of variables: GiNaC does not have functions to solve systems of non-linear equations. Factorization of polynomials: GiNaC only has squarefree factorization and this problem cannot be solved that way.

2 1