- GiNaC-list - ginac.de

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

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

21 Jul '06

Sheplyakov Alexei wrote: > So I propose to document that shared libraries are not supported on > MinGW. What about this patch? > > Index: INSTALL > =================================================================== [...] > --- INSTALL 19 Oct 2005 20:54:13 -0000 1.54 > +++ INSTALL 20 Jul 2006 13:37:43 -0000 [...] > +To build ginsh modified version of GNU readline library is necessary. It > +is available at <http://gnuwin32.sourceforge.net/packages/readline.htm>. [...] There is one more thing about the proposed use of the modified readline library. Since it seems that the primary advantage of the modified readline library is that it might permit an "automatic" default linkage to legacy UNIX functions in libgw32c.a , there is also a need for "automatic" default include directories as well. Having to explicitly specify prototypes for legacy functions in libgw32c.a would seem to defeat or complicate the purpose of using libgw32c.a . I suppose one possibility would be to use cygwin headers as a last resort (included farthest down in the source code if their inclusion is needed) and to use cygwin include directories as default include directories to be searched _after_ the default MinGW gcc system include directories, but how would one specify that to gcc? All the methods I know for specifying include directories to gcc place those directories ahead of the standard gcc system directories in priority. So I suppose that in order for the modified readline and libgw32c.a to be effectively useful, gcc would need to be rebuilt with such default lower priority directories specified automatically, but then the default legacy header files would also need to be supplied with the MinGW gcc standard header files in the packaging of the MinGW gcc standard runtime libraries. There is also the question whether inclusion of such a legacy header for a function xyz could cause a conflict between the legacy and main system prototypes for another function uvw whose prototype is specified in that legacy header and also in a main system header. Moreover, macro definitions and the like used for prototypes in system header files are often extremely complex so that a "casual" programmer might be extremely intimidated in attempting to make any ad hoc debug adjustments as to specifying prototypes. (I remember once having to modify a MinGW gcc system header because a simple macro variable in it collided with a variable of the same name in a build package; but fortunately only a simple change in the variable name in the MinGW gcc system header was sufficient to solve the problem so that I didn't have to understand everything that the header file was doing and how it related to other parts of gcc and the runtime libraries. I think this event probably occurred when I was doing a build of CLN or GiNaC a few years ago.) 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] Results of GiNaC (& CLN) builds
by Richard Haney 21 Jul '06

21 Jul '06

Sheplyakov Alexei wrote: > You should definitely read this: > http://www.catb.org/~esr/faqs/smart-questions.html > > and this: > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > WARNING! These pages *DO NOT HAVE ANYTHING TO DO* with GiNaC! > They try to give an idea how to ask questions the smart way. > > > I had to do several fresh starts of ginac from .tar.bz2 to find out > > a workable use of the patch. > As usual, > patch -p0 < where/the_patch/is Thanks for the information. I appreciate the helpful comments and information. But I didn't think I was being stupid or rude, and even though the references are likely to be helpful, I am taken aback by the seemingly implicit "prickly-pear" attitude of those articles, and moreover, I think that the advice misses the point that the world of ideas and systems tends to be quite a bit more complicated than what the author presumes. Contrary to what the author seems to believe, I do not think there is a universal, "true", "right", "one-size-fits-all" way to ask questions. Lots and lots of things in computer systems routinely seem to be "broken" and I don't think it is necessarily due to the fault of "Microsoft Windows" or the saving grace of UNIX/Linux systems design. For example, there seems to be no "html" target in GiNaC Makefiles in spite of what the documentation seems to indicate. It's not just GiNaC. It seems to be quite frequent that documentation is often out of sync with actual systems development. So I suppose "stupid" questions would be inevitable. I suppose I could write a book about what's "wrong" with modern computer systems. But that's not my purpose. What I'd like to do is to understand the design philosophy as to why certain legacy practices and legacy designs seem to be needed. So I try to frame my questions in a way that will solve the most problems most effectively rather than to interminably nitpick a million and one questions in protracted, excruciating detail. Design schemes and philosophies matter. (But I also agree that examples and pertinent detail matters.) The "right" level of abstraction matters. But abstraction is an extremely fluid commodity. There is a lot of arbitrariness to it. And it often has the danger of leading to factional ideologies, flame wars, religious wars, and so on. There are lots of unanswered questions I have about GiNaC and its build process. Here are a few of the seemingly more important ones: Why is it necessary to specify the installation root directory at the time of running configure? Why can't that be done _simply_ at the actual time of doing the installation? Why is it necessary to use libtool? Is libtool a "fixed", universal product? Or is it simply something that is tailored specifically to the particular build process, in this case GiNaC's. Why is it necessary to compile each library module twice? (I suppose the idea is that two different versions are needed for the two different potential forms of the library: "static" and "shared". Is this true?) If a .dll version is not possible, can all the excess machinations be eliminated by declaring "--disable-shared" on the configure command line? Shouldn't a comment to this effect be put in the installation documentation so that mingw-users don't needlessly go through the excess machinations in the hopes of getting a .dll? There are probably other important questions that ought to be asked here, but the above are the more salient ones that come to mind. Sheplyakov Alexei wrote: > ./configure && make && make check && make install > > works just fine. If you happen to know a standard, "legacy"(?) configuration of your system that GiNaC build is happy with, I would expect your results. But when systems have a horrendous variety of degrees of freedom for creative, alternative designs, it is amazing the build process works at all. In any case, I would think it important to design the general build process to be both robust and flexible. Maybe this is not the right place to ask this question, but it does seem to matter here the most (grep is such a common tool that I doubt if there is a specific, preferred forum for this): I have not been able to get (cygwin or any other) grep to do a routine, "recursive" sweep through _all_ subdirectories. I have only been able to get sweeps at only fixed depths by using, for example, "./*/*/*" for the filename specification. Can anyone explain how to get a complete recursive sweep through all subdirectories with grep? The documentation seems to be silent on precisely what's needed here. Examples would help.

3 3

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