- GiNaC-list - ginac.de

Re: [GiNaC-list] Python wrapper for a GiNaC derived library
by Vladimir Kisil 10 Aug '06

10 Aug '06

Ondrej Certik ondrej at certik.cz write on Thu Jul 20 00:13:29 CEST 2006 > We also created swiginac (http://swiginac.berlios.de/) for those, who > are interested in using ginac from python. > just my opinion: boost-python took ages to compile on my machine and > the errors were completely unreadable. swig compiles much faster, and > also it seems easier to learn. Do others have similar experience, or > totally different? I agree that both BoostPython and pyGiNaC have some issues and may be willing to make my library wrap in swiginac as well. However the swiginac is not supporting the new tinfo system and I cannot see right now how to patch it. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

6 18

"Internal error..." report -- probably misused map.
by Warren Weckesser 10 Aug '06

10 Aug '06

Hi, I am working on a program that generates code for other libraries or programs. One of the target libraries is CVODE, a solver for differential equations (part of the SUNDIALS suite). In CVODE, numbers are represented with a typedef 'realtype', which can be chosen to be float, double, or one or two other options. To ensure consistent use of realtype, constants are wrapped in the macro RCONST. I am trying to automate this in ginac. I am using ginac version 1.3.4 (compiled with gcc 4.0.2 on Ubuntu Linux). In some of my first attempts to do this, I occasionally got an "internal error" message. The following code is a simplified version that causes the error: --- ginacwrap1.cpp -------------------------------------------- #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; DECLARE_FUNCTION_1P(RCONST) REGISTER_FUNCTION(RCONST,dummy()) ex wrap1(const ex & e) { if (is_a<numeric>(e)) return RCONST(e); else return e.map(wrap1); } int main(void) { symbol x("x"); ex p = cos(1+x); // Internal error: ... line 93 has been reached! // ex p = 2*x; // Internal error: ... line 30 has been reached! // ex p = 2+sin(2); // Works: wrap1(p) = RCONST(2)+sin(RCONST(2)) ex w = wrap1(p); cout << "wrap1(p) = " << w << endl; } --------------------------------------------------------------- This results in an "internal error": Internal error: statement in file ./real/elem/cl_R_mul.cc, line 93 has been reached!! Please send the authors of the program a description how you produced this error! If the expression p is changed to 2*x (see the comments), a similar internal error is reported. After more work, I ended up with the code shown below, which seems to do what I want (but any suggestions for a better method would be appreciated). I had to define my own print function for the RCONST function, because the default print function converted the name to lower case when csrc was used. One remaining nuisance: In csrc mode, ginac prints the expression -x as "-1.0*x". Is there a way to have it output "-x" in csrc mode? Best regards, Warren Weckesser --- ginacwrap2.cpp -------------------------------------------- #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; static void RCONST_print_csrc_double(const ex & arg, const print_context & c) { c.s << "RCONST("; arg.print(c); c.s << ")"; } DECLARE_FUNCTION_1P(RCONST) REGISTER_FUNCTION(RCONST,print_func<print_csrc_double>(RCONST_print_csrc_double)) ex wrap2(const ex& e) { if (is_a<numeric>(e)) return RCONST(e); if (is_a<symbol>(e)) return e; if (is_a<add>(e)) { ex s = 0; for (size_t k = 0; k < e.nops(); ++k) s = s + wrap2(e.op(k)); return s; } if (is_a<mul>(e)) { ex p = 1; for (size_t k = 0; k < e.nops(); ++k) p = p * wrap2(e.op(k)); return p; } return e.map(wrap2); } int main(void) { symbol x("x"); cout << csrc; ex p = -exp(-x)+x*x; cout << "p = " << p << endl; ex w = wrap2(p); cout << "wrap2(p) = " << w << endl; } ----------------------------------------------------------------

2 2

GiNaC is not a package manager (Was.. ...
by Richard Haney 08 Aug '06

08 Aug '06

Alexei, --- "Sheplyakov Alexei" <varg(a)theor.jinr.ru> wrote: > On Sun, Aug 06, 2006 at 04:20:11PM -0700, Richard Haney wrote: >> It seems to me that an extremely good idea is to make a general >> practice of keeping separate software packages in separate file >> hierarchies, > >This is in fact very bad idea... I was hoping to stimulate a discussion of the pros and cons. Could you give some reasons? I suppose there are probably both good and bad reasons for the idea, and it seems that knowing the various reasons ahead of time could save having to deal with a lot of needless problems later. As packages are installed and built, a certain amount of commitment is built up over time, and thus, it can become costly to undo bad decisions. But it's not completely clear to me what all the potential problems might be one way or the other. I've indicated some considerations as to why I think the idea is a good one. >> and moreover it seems to be more complication for the user than >> should be necessary. > > You made this complication yourself (by choosing weird installation > paths). I was trying to suggest an approximate solution using _existing_ facilities in the GiNaC as distributed, as a lead-in to the next variation proposed, which seems a better, simpler approach, but would seem to require a modification of GiNaC distribution: >> It seems one possibility would be a command such as >> ./configure CLN="C:/gnu/cln-1.1.11/gcc342" >> READLINE="C:/gnu/readline-5.1/gcc342" >> TERMCAP="C:/gnu/termcap-1.3.1/gcc342" > >GiNaC configure script provides --with-cln-prefix option So it seems that perhaps this following command should work (without having to have the relevant libraries installed in a central, PATH-and/or-gcc-dependent repository): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" CPPFLAGS="-IC:/gnu/readline-5.1/gcc342/include [-IC:/gnu/termcap-1.3.1/gcc342/include]" LDFLAGS="-LC:/gnu/readline-5.1/gcc342/lib [-LC:/gnu/termcap-1.3.1/gcc342/lib]" I've put the termcap references in brackets [] because it's not clear to me whether the bracketed parts are needed (in the next distributed version of GiNaC, at least). Would this work? It would probably take me at least a half day to test this. Does anyone see any problem with it? But note that there is some redundancy here in the command line. A preferred command line might be (omitting the termcap reference as well): ./configure --with-cln-prefix="C:/gnu/cln-1.1.11/gcc342" --with-readline-prefix="-IC:/gnu/readline-5.1/gcc342" This, of course, would require that the GiNaC distribution be modified accordingly and that the installation structure for readline be the standard one with the root directory the one specified. >> Another improvement that seems a good idea is in general to place a >> single value -- such as, for example, the configure script's option >> value of "--prefix" -- in one standard location that all Makefiles >> would refer to, > > You might want to read autoconf manual, specifically the chapter about > CONFIG_SITE variable. I was thinking in terms of simple changes to the GiNaC distribution so that a new user wouldn't have to read the autoconf manual. One possibility would be to have an include file -- say, in the root build directory (i.e., with "configure") -- that each of the Makefiles would include to function as a part of each such Makefile. >> I would like to hear what others think of the general idea and various >> practices in managing software packages to be as mutually independent >> as possible, except where dependence is really needed. > > Long time ago package managers was written to solve these problems. If > your OS lacks such a package manager, GiNaC is not going to provide one. Well, I suppose a package manager might be one approach or part of a more general approach, but I wasn't thinking that special package management software would be necessarily a part of such a general approach. A human operator needs to make allocation planning and priority decisions at least. So some degree of manual operation seems necessary. I would hope for an appropriate management scheme/philosophy and simplified procedures. Allowing for or providing some additional support for flexibility here -- according to what the user prefers -- seems perhaps a good idea. > think porting dpkg/APT to win32 would be better approach. I looked on the Internet and didn't find anything informative that I could examine to get an idea of what's involved in your suggestion. So at the moment porting dpkg/APT seems out of my reach as far as anything I could do. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

some flexibility problems with configure
by Richard Haney 07 Aug '06

07 Aug '06

Since running the GiNaC's configure script typically takes a considerable amount of time, it seems that there is a need for more flexibility (as well as robustness and, of course, speed) in the build/install process, and it seems that it is particularly important that the INSTALL documentation should be especially clear on a number of things in this regard. A few years ago when I built CLN and GiNaC, I had a rather slow computer. It took me at least two weeks of several hours per day running my computer to do the builds. I also encountered a number of "real bugs" and "false bugs" (e.g., the -- as of at least now -- misleading problem with configure's "checking whether make sets ${MAKE}"). After running configure and then make for many days and then discovering that changing some files could clobber my Makefiles, I became especially concerned about the possibility that some of the extremely time-consuming builds of object files could be inadvertently destroyed because of evident, but unclear, "Rube Goldberg" mechanisms in Makefiles and the experimental adjustments I might try making. I eventually figured out that I needed to keep backup copies of every single version of Makefile modifications. And I finally figured out that I should run something like "make -k &> make_-k_out.txt" to preserve a record and to make the best progress without having to constantly check (over a period of several hours each day) whether the make process has crashed on some bug. (The output file "make_-k_out.txt" then gets its name changed manually to something like "make_-k_out--2006-08-05, 1..24 pm.txt" so it won't be clobbered by a re-use of the command line.) It seems some advice in this regard in the INSTALL file would be a good idea. Well, I now have a significantly faster computer and I suppose that there have also been some improvements in the intrinsic robustness, speed, and flexibility of GiNaC builds. But the earlier concerns of mine seem still to be present, especially for a new user of GiNaC and its build process. It needs to be made clear what things a person can modify without causing great havoc and having to start the build processes over from scratch. Hopefully, this could be done in a clear fashion without requiring a high degree of special expertise (say of autoconf, automake, configure, make, etc.) by the user. Some Makefiles, in particular, are extremely intricate and elaborate and seem to resemble "Rube Goldberg" contraptions. If the user discovers that something in the make process is not working as expected, it seems a good idea to allow him or her to make adjustments to Makefiles and/or perhaps other files without causing irreversible havoc. (This sort of thing has seemed absolutely necessary in my build of readline, including a very inelegant hack of the script "shlib-install" -- due to a "shift" command not skipping the argument "C:/cygwin/bin/install -c -m 644" (with quotes) as one entire unit -- in order for directory "C:/gnu/readline-5.1/gcc342/bin" to be created and the DLLs installed there as evidently intended. This kind of thing makes a newbie wonder what kind of horrendous debugging hoops he will have jump through in building something like GiNaC. Similar issues with bugs in CLN and GiNaC compiler source files have recently been addressed here by Sheplyakov Alexei and seemed to be still present this year after my three-and-a-half-year hiatus from CLN and GiNaC builds.) It seems to me that an extremely good idea is to make a general practice of keeping separate software packages in separate file hierarchies, especially when one is installing packages tentatively and may want to delete or uninstall such packages later. In other words, it seems an extremely good idea to keep packages as mutually independent as possible, and when dependence is necessary, to make it very clear (by adding strategically named annotation files, for example) what that dependence is. (An exception would be several standard packages that are designed by a single group -- e.g., MinGW -- for installation in a common hierarchy.) I recall once deleting and/or uninstalling my cygwin hierarchy "C:\cygwin" and then later deciding that I wanted to re-install it. Any important files added to the hierarchy before deleting it would likely be lost without special care to search the hierarchy's directories for past adjustments and additions. (For example, I have changed the name of "bunzip2.exe" to "bunzip2.exe--DANGEROUS_DEFAULTS.exe" in "C:\cygwin\bin" and supplied a script file "bunzip2" to execute "bunzip2.exe--DANGEROUS_DEFAULTS.exe" using safer default options.) And if any files get installed in the typical default "/usr/local", those files would be a part of the "C:\cygwin" hierarchy (if using cygwin bash) and thus would risk being lost should cygwin be uninstalled (and/or updated). So for these reasons I have preferred to keep software packages and their "installations" in their own hierarchies. (So for example my preferred root installation directory for GiNaC is "C:\gnu\ginac-1.3.4\gcc342" -- that's "/cygdrive/c/gnu/ginac-1.3.4/gcc342" or "C:/gnu/ginac-1.3.4/gcc342" in a cygwin bash context, especially where "\" has a special meaning.) A major motivation is the desire to initially install packages only tentatively. I want to be careful about loading my disk unnecessarily with large numbers of packages that consume vast amounts of disk space. (For example, I have resisted installing the Microsoft's "free" C++ Visual Studio Express because the -- presumably much compressed -- installer consumes about 135 MB of storage and I am concerned the actual installation could consume, say, a gigabyte of storage.) I recently installed Dev-C++ because of comments I found on "Wikipedia" comparing IDEs and especially because I wanted to have a "safe" installation of the highly portable wxWidgets and because the Dev-C++ package incorporates all the essentials of MinGW gcc 3.4.2, the latest stable version of gcc (at the time). So now with my build of CLN and GiNaC I have somewhat compromised my general plan of package-installation independence and placed copies of various libraries -- for example, "libtermcap.a", "libreadline.a", "libhistory.a", "libgw32c.a", and now "libcln.a" and "libginac.a" -- in my "C:\Dev-Cpp\lib" directory and various DLLs and "cln-config" in "C:\Dev-Cpp\bin". ("Filename" annotations added to these directories include, for example, empty files "cln-config--from 'C.._gnu_cln-1.1.11_gcc342_bin'.txt", "libreadline.5.dll from readline-5.1 build--see 'C.._gnu'.txt", and "libginac.a from 'C.._gnu_ginac-1.3.4_gcc342_lib'.txt". When a directory is displayed in alphabetical order, such an annotation file appears next to the associated "installed" file for quick reminder of the "installed" file's origin.) One possibility that may perhaps work when building GiNaC for example is to use the rather long command ./configure CPPFLAGS="-IC:/gnu/cln-1.1.11/gcc342/include -IC:/gnu/readline-5.1/gcc342/include -IC:/gnu/termcap-1.3.1/gcc342/include" LDFLAGS="-LC:/gnu/cln-1.1.11/gcc342/lib -LC:/gnu/readline-5.1/gcc342/lib -LC:/gnu/termcap-1.3.1/gcc342/lib" but this does not satisfy GiNaC configure's need to find "cln-config" (in "C:/gnu/cln-1.1.11/gcc342/bin") and moreover it seems to be more complication for the user than should be necessary. It is not clear to me whether this would work for GiNaC builds with appropriate prepackaging adjustments vis-a-vis GiNaC configure's current need to find "cln-config" -- even if cygwin bash would allow arbitrarily long command lines. But it seems that some relatively simple adjustment to GiNaC's packaging could allow for such simple, flexible, package-independence processing by the user. (See also the autoconf-list archived message: "Re: nonstandard library directories" (Bob Proulx, Thu, 29 Jun 2006 21:38:15 -0600): http://lists.gnu.org/archive/html/autoconf/2006-06/msg00122.html ) It seems one possibility would be a command such as ./configure CLN="C:/gnu/cln-1.1.11/gcc342" READLINE="C:/gnu/readline-5.1/gcc342" TERMCAP="C:/gnu/termcap-1.3.1/gcc342" This would of course require adjusting the GiNaC distribution appropriately. (Generally, I'm thinking that there should be some easy, simple way of pointing to the various original package installation directories.) The advantage of this approach is that it allows the various library build/installation packages to be storage-wise independent of any centralized hierarchy such as "C:\Dev-Cpp", "C:\cygwin", or MinGW's "C:\msys", and thus would allow for easier systems-packages management. Another improvement that seems a good idea is in general to place a single value -- such as, for example, the configure script's option value of "--prefix" -- in one standard location that all Makefiles would refer to, so that the user could simply modify that one value for all Makefiles, in contrast to the present practice of repetitively placing a given such value in every Makefile. There are other files -- for example, script file "config.status" -- that also refer to the "--prefix" value and would also need to be modified to refer to the one, central, GiNaC-build information file for this information. Of course, such a facility should also be described sufficiently in the INSTALL file. (While "make install prefix=/path/to/wherever" may be a good work-around for the "--prefix" value, there are many other values which are repetitively placed throughout the Makefiles and which may need to be modified; or perhaps they too could be treated similarly to the "prefix=" example. But it is important to include that information in the INSTALL file.) The idea, of course, is to improve the ease and flexibility of the build process, especially when bugs are encountered and especially in view of the fact that configure is a rather time-consuming script to run and that building the library object files and building the libraries after the object files are built are also time-consuming, and even some of the tests are a bit time-consuming as well. I would like to hear what others think of the general idea and various practices in managing software packages to be as mutually independent as possible, except where dependence is really needed. This is particularly important in regard to GiNaC builds and installations -- as well as other software package builds and installations. I would also like to hear how this idea could or should be implemented for GiNaC, especially along the lines suggested above, or what alternative considerations and practices my be more appropriate. Please note that, while many of the above details may seem irrelevant from certain limited perspectives, I am supplying these details to give a realistic idea of what a new user is faced with. (And while the examples given above are specific to "C:\Dev-Cpp", "C:\cygwin", or MinGW's "C:\msys" in a Windows environment, the general issue of systems-packages independence seems equally applicable to standard Unix/Linux systems as well; but in the case of Unix, it seems there is a whole lot of "ancient" systems legacy -- e.g., centralized installation -- that may perhaps also need to be considered.) As experience shows, it seems to me that the build process needs to be designed to allow for the possibilities that bugs will appear and that a relatively build-unspecialized user needs to respond to those bugs in a flexible manner. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Results of GiNaC (& CLN) builds
by Richard Haney 06 Aug '06

06 Aug '06

Appended to this message is the result of building and testing GiNaC with "make check-TESTS". In summary, all three of the "runs" (run_exams, run_checks, run_times) failed although some of the subtests passed. Also appended are listings of the "exams.out", "checks.out", and "times.out" files. Here are some relevant system specs: 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 Hopefully, with my description of the problems someone can provide information on how to resolve them and perhaps clear up some other dubious points that this description suggests. Hopefully, the problems are even very simple to correct. I decided to build the readline library although I suppose I may have been able to use "cygreadline5.dll"; in fact a test (after I had partially built the readline library) suggested that this is likely so; I surmise that essential .dll linkage specifications tend to be more stable and universal (and compiler-independent) than are static library linkage specifications. (The static cygwin libraries were most likely built with an "ancient" gcc and I surmised that they probably would not be compatible with a more recent gcc's output -- I think I've tried linking to some of them before.) I also built the termcap library to use with the examples in the readline library build. First, I briefly describe the problems with CLN: In building CLN I had to do considerable finagling with the Makefiles. (Typically, as from earlier experience in building an earlier version of CLN and GiNaC, I had to temporarily comment out the mingw's make.exe so that Borland's make.exe (the next make.exe in PATH) would answer configure's question "checking whether make sets $(MAKE)" with the right answer: yes; the test with mingw's make.exe says "no", but "yes" seems to be the appropriate answer for mingw's make.exe. Also, I had to change "/cygdrive/c" to "C:" (and sometimes also "/usr/bin" to "C:/cygwin/bin") in the Makefile pathnames for build tools and libraries and add "--tag=CXX" to libtool lines, especially if I wanted to execute make in a subdirectory.) And I ran into one error with "make check" at "test_I_io", resulting in the output "Illegal number syntax" evidently from function read_number_bad_syntax() in "cl_read_err_bad.cc". But when I commented out that test for "test_I_io" in function test_I(), the "make check" run was otherwise fine. I also set up a run of only the "test_I_io" test and found that the error occurred when I compiled the tests modules with -O2 optimization, but the error did not occur when I compiled them with the no (i.e., -O0) optimization. I also tried to use gdb with tests.exe but found that I could not set breakpoints in cl_I_read.cc, cl_I_read_stream.cc, or cl_read_err_bad.cc even though I recompiled these modules with the "-g -O0" flags and then rebuilt "libcln.a" using these three rebuilt object modules. (I even tried removing these three modules from the library build and putting them in the "tests" directory, but I seem to have run into "order-of-initialization" problems as suggested in header file "cln/modules.h"; the linker error in this case was "C:/Dev-Cpp/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16'".) I also made sure the -s linker flag did not appear in the commands in building "libcln.a" as well as "tests.exe". (However, I surmise that libtool may be doing some rather mysterious things in getting "database" information from mysterious files; but in each case -s did not appear in the immediately subsequent g++ command line that I surmise is generated by libtool and that seemingly should be regarded as the unequivocal description of what g++ is doing to build "libcln.a".) I also set up a rebuild of tests.exe and used "drmingw tests.exe" and an intended exception/fault in "cl_read_err_bad.cc", but the stack traceback output I got seemed slightly erratic. (If I recall correctly, I think there was listed an extraneous call to cl_abort() before the call to read_number_bad_syntax().). I surmised later that the erratic output was probably due to the fact that most of the relevant object modules for tests.exe were built with -O2. I also set up a run to force linkage of tests.exe to link to the mpatrol library to see if the error could be due to heap-memory or C-memory-function errors, but even though I got a rather large, verbose, three-figure MB log file, that log file showed no memory errors. Unfortunately, read_number_bad_syntax() calls something like cl_abort() rather than returning control to the calling function with an error indication. As a result an after-failure call to an "outside hook" function cannot easily be made for setting breakpoints and examining variables with gdb -- note that gdb breakpoints _can_ be set in functions whose object modules are not a part of the CLN library. (But rebuilding the library after its input object modules have been built is rather time-consuming as well, discouraging experimentation.) So with the dependency of the test on using optimization (or not) in compiling and linking the "tests" modules, I figured the problem was probably connected with the "order-of-module-initialization" issues described in header file "cln/modules.h" (which issues are apparently dependent on optimization); and so I decided to proceed with building the readline libraries and GiNaC, and possibly come back to this issue with "test_I_io" later, depending on how successful I was with GiNaC. Problems with GiNaC: Because of earlier experience, I generally made modifications to all of GiNaC's Makefiles in accordance with the ideas discussed above for CLN. I also liberally listed library names (sometimes pathnames) for the various "LIBS" and "..._LIBS" variables (even though many of these variables are not used), and I included "-lstdc++ -lmingw32" for these variables because an earlier build of GiNaC suggested that they were needed. I figured that duplication of library names on command lines probably wouldn't hurt and the Makefiles could be more easily adjusted if necessary, if duplication problems did arise. And I decided I needed to copy "libreadline.5.dll" (and "libhistory.5.dll" even if not needed) to "C:\Dev-Cpp\bin", the binary folder for my mingw gcc 3.4.2 and other mingw tools. This "bin" is in my PATH variable used to search for executables. I also had to make several adjustments of to config.h to account for the fact that I actually did have a readline library even though configure said I didn't -- three macro variables should say I have readline and two should provide the version numbers. (I copied "libreadline.5.dll" to "C:\Dev-Cpp\bin" after I ran GiNaC's configure.) I also had to modify "ginsh_parser.cc" (in folder "ginsh") and "timer.h" and "timer.cpp" (in folder "check") to use header <ctime> and function clock() in place of header <sys/resource.h> and function getrusage(), which apparently are not in my mingw runtime libraries. I also commented out (with //) all the "#line" (presumably comment) lines in ginsh_parser.cc because a comment in an earlier version of GiNaC said some compilers may choke on them -- I was trying to make the setup as robust as possible. (By the way, ginsh.exe seems to be working as intended.) So after a horrendous amount of finagling and discovery of what works and what doesn't, I finally completed the "make check-TESTS" test for GiNaC. Since the problems don't seem to be obviously trivial, even if minor adjustments could fix them, I have decided to see if I can get some help on this. I could send a zip file of my most recently modified Makefiles (particularly the .rtf backup versions that have manual modifications highlighted in boldface) and modified .cc, .cpp, and .h files if anyone is interested. (I usually create the text-format Makefiles from the .rtf backup versions). I also use the "modified" time-stamps in backups with descriptive file names and output files to keep a chronological history of what I've tried. And I often use "touch -m --reference=..." to synchronize text versions with .rtf backup versions, which are easier to edit with WordPad. (A newly created "Makefile" from an .rtf backup is what I usually use as the reference in the touch command to synchronize the Makefile with its backup. And I often add date/time stamps in the file names for easy overviews in Windows Explorer with files sorted as to modified date/time. The date/time stamps in the file names also serve to keep the output file names distinct in a sequence of experimentally varied trial runs.) Richard Haney Here are the appended listings of files: make_check-TESTS_out.rtf: GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia........./exams.ref exams.out differ: char 39, line 2 FAIL: run_exams GiNaC will now run through some rather costly random consistency checks: checking consistency of numeric types.. passed checking consistency of symbolic functions.... passed checking symbolic matrix manipulations./checks.ref checks.out differ: char 153, line 6 FAIL: run_checks GiNaC will now run through some basic timings: timing commutative expansion and substitution.... passed size: 50 100 200 400 time/s: 0.19 0.719 3.109 13.8 timing Laurent series expansion of Gamma function.... passed order: 10 15 20 25 time/s: 0.16 0.51 2.49 9.349 timing determinant of univariate symbolic Vandermonde matrices./times.ref times.out differ: char 192, line 6 FAIL: run_times ====================================== 3 of 3 tests failed Please report to <ginac-list(a)ginac.de> ====================================== c:\Dev-Cpp\bin\make.exe: *** [check-TESTS] Error 1 exams.out: ----------several historic failures: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. checks.out: ---------consistency of numeric types: (no output) ---------consistency of symbolic functions: (no output) ---------symbolic matrix manipulations: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. times.out: -------commutative expansion and substitution: (no output) -------Laurent series expansion of Gamma function: (no output) -------determinant of univariate symbolic Vandermonde matrices: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ==== end of message ==== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 21

Indexed vs labelled
by Vladimir V Kisil 01 Aug '06

01 Aug '06

Dear All, Browsing email on my vacation I noticed a discussion on indexed objects. So far my impression is that GiNaC FAQ is mainly written in do-not-do-this-and-that style. Some active GiNaC users (e.g. me) may wish to see more positive suggestion. For example, I would be grateful for answering such questions: Q4. "Indices" of various kinds proved to be useful in different areas of mathematics, e.g. linear algebra. If present idx and varidx classes are strictly reserved for differential geometric usage in spaces with fractional dimensions, are there plans to add some other classes, say "labels", which may be freely utilised for other purposes? Q5. I need expressions of the type \sum_{j=1}^n a_j b_j for an unspecified symbolic value n and quantities a_j and b_j *labelled* (rememberring that _indexed_ is already copyrighted) by j in this range. Since the varidx class for j is not encouraged and the Einstein summing convention is not "meaningful" in GiNaC, what is the recommended way to define such a sum in my program? Best wishes from the sunny Odessa ;-) Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk

3 2

RE: [GiNaC-list] Indexed vs labelled
by Alejandro Limache 01 Aug '06

01 Aug '06

It seems that my last email got chopped so I am resending it, sorry... >>Q4. "Indices" of various kinds proved to be useful in different areas of >>mathematics, e.g. linear algebra. > >>Q5. I need expressions of the type \sum_{j=1}^n a_j b_j for an unspecified >>symbolic value n and quantities a_j and b_j *labelled* (rememberring that >>_indexed_ is already copyrighted) by j in this range. > I have the same type of concern.

1 0

Simplifying indexed expressions not working on multi-indices scalar_product
by Alejandro Limache 28 Jul '06

28 Jul '06

According to section 4.14.5 "Simplifying indexed expressions" of the tutorial, if I set: scalar_products sp; sp.add(A, B, 0); then: A~mu~nu*B.mu.nu should be replaced by zero when using .simplify_indexed(sp). This is not working. See my simple code below. Is this a bug?, any help will be appreciated Alejandro PS. I am using Ginac version 1.3.4 on debian this are the rpm I've got: ginac-tools_1.3.4-1_i386.deb libginac1.3c2a_1.3.4-1_i386.deb libginac-dev_1.3.4-1_i386.deb %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main (void) { symbol A("A"),B("B"),mu_sym("mu"),nu_sym("nu"); idx mu(mu_sym,3), nu(nu_sym,3); ex e, e1; scalar_products sp; sp.add(A,B,0); cout << "scalar_prod 1 index:" << endl; e= indexed(A,mu)*indexed(B,mu); cout <<e <<endl; cout << e.simplify_indexed(sp) << " ==> correct " << endl; cout << "scalar_prod 2 indices:" << endl; e1= indexed(A,mu,nu)*indexed(B,mu,nu); cout << e1 <<endl; cout << e1.simplify_indexed(sp) << " ==> wrong, it is not zero" << endl; return 0; }

3 10

Re: [GiNaC-list] [patch] Document that shared libraries are not supported on some weird platforms
by Richard Haney 22 Jul '06

22 Jul '06

Sheplyakov Alexei wrote: > On Wed, Jul 19, 2006 at 10:45:13PM +0200, Richard B. Kreckel wrote: [...] > > [[...]] Actually, you *can* > > specify the prefix at the make install step by saying make install > > prefix=/path/to/whereever. > Do you mean "make install DESTDIR=/some/weird/dir"? A perusal of the root Makefile shows that the juxtaposition "$(DESTDIR)$(bindir)" appears in many places throughout the Makefile and that "bindir" is defined in terms of "exec_prefix", which is defined in terms of "prefix", which is defined as the value set with the "--prefix=..." option on the configure command line. (In ginac/Makefile, "$(DESTDIR)$(libdir)" occurs throughout the Makefile with a similar dependence of "libdir" on the value of configure's "--prefix=..." option.) So it seems that "make install DESTDIR=/some/weird/dir" would only work as intended if "--prefix=..." was not specified on the configure command line. But has anyone tested this use of "DESTDIR"? The readline library build's INSTALL document mentions this as a way to install its library, but I figured that since the GiNaC documentation didn't mention this, it may perhaps be only a nonfunctional vestigial remnant from the origins of GiNaC build components. If this use of "DESTDIR" does work in place of specifying "--prefix=..." on the configure command line, shouldn't this fact be mentioned in the GiNaC installation write-up? It would simplify things considerably. Or if this use of "DESTDIR" only works when "shared" libraries are not built, shouldn't this fact be mentioned in the installation write-up, especially in the case of MinGW-based builds, where DLL-building is not currently supported? Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

How output from the configure script can be quite misleading
by Richard Haney 22 Jul '06

22 Jul '06

When I first tried building CLN and GiNaC a few years ago, I got a message from the configure script similar to the following, which is the typical output in the most recent builds: <begin quote> checking whether make sets $(MAKE)... ./configure: eval: line 1: unexpected EOF while looking for matching `"' ./configure: eval: line 2: syntax error: unexpected end of file no <end quote> Sheplyakov Alexei's recent comments about building without modifying Makefiles and my most recent tests seem to show that this error message does not indicate a fatal error for the build process, but merely indicates an "error" that is a "normal" result of the test and whose potential ill consequences the configure script is quite able to circumvent. So when I first tried building CLN & GiNaC a few years ago, I think I probably got a configure failure because readline headers and/or binary library (libreadline.a) could not be found and/or because the CLN library could not be found. So when I found that configure did not produce results that would allow an error-free build, I, as a newbie to the process, began perusing all of the output to see if I could find some clear indication as to why the build was failing. The output associated with "checking whether make sets $(MAKE)..." looked like a problem that I needed to correct somehow (in addition to the problems of getting the configure script to find headers and/or binary libraries). I don't recall how I stumbled upon the idea that letting my Borland make answer the configure script's question would solve the problem. Perhaps I just didn't have my gnu make in any of my PATH directories at some point. Anyway, when my Borland make was answering the configure script's question, the answer was simply a "yes" with no error messages. However, other tests showed that Borland make was not up to the task of building the library. So it seemed quite clear to me that I needed to comment out my gnu make when I wanted to run configure and then restore my gnu make when I wanted to run make. It is my guess that this situation has probably resulted in a lot of needless modification of Makefiles by me. So the point of this message is that the quoted output above regarding "checking whether make sets $(MAKE)" can be extremely misleading, especially to a newbie. If the configure script eventually comes up with the answer "no" (as above), it seems very likely that there is no problem here that requires "operator" intervention and/or adjustment in that regard, regardless of the error messages produced in the interim. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0