From kreckel at thep.physik.uni-mainz.de Wed Mar 7 20:08:00 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Wed, 7 Mar 2001 20:08:00 +0100 (CET) Subject: So what shall we buy? (Porting GiNaC) Message-ID: >From the macho-computing-on-macho-machines-dept. Let me briefly report on some newer timings I ran on some nifty up-to-date machines using the timings in GiNaC 0.7.3. The competitors were: an IA-64 (Itanium) machine running at 733MHz, a cheap off-the-shelve Athlon system with 800MHz and a newer Alpha 21264A (known as EV67) running at 677MHz clock speed. All had mind-boggling amounts of memory. The IA64 and the Athlon were running under Linux, the Alpha under Compaq's Tru64. The compiler used was GCC 2.95.2 except on the Itanium where I had to use a newer GCC 3.0 snapshot from CVS. Two tests were omitted because there seem to be bugs in the exception handling of the IA64 compiler and for obscure reasons the Alpha program chose to crash on one test (you won't believe how many compiler problems one sees when doing this kind of stuff). As we all know, computer algebra in practice tends to be code that does a lot branches giving good branch prediction a real chance. Also, the floating point unit usually idles a lot. So, we can expect the Alpha processor to run far from optimal performance. Although the GNU compiler is known not to generate good EPIC code and the IA64 processor is not yet released anyways and the final hardware might differ from the one used here, I find the Itanium timings rather disappointig. For your personal edification and without further apologies here are the numbers: commutative expansion and substitution (a.k.a. Denny Fliegner's test) size IA64 Athlon 21264A Ratio 50 0.13 0.07 0.06 1.85 / 1.00 / 0.85 100 0.64 0.35 0.29 1.82 / 1.00 / 0.82 200 3.01 1.719 1.41 1.75 / 1.00 / 0.80 determinant of univariate symbolic Vandermonde matrices dim IA64 Athlon 21264A Ratio 6x 6 0.02 0.006 0.01 3.33 / 1.00 / 1.66 8x 8 0.21 0.11 0.13 1.91 / 1.00 / 1.18 10x10 2.09 1.01 1.25 2.07 / 1.00 / 1.24 determinant of polyvariate symbolic Toeplitz matrices dim IA64 Athlon 21264A Ratio 6x 6 0.12 0.065 0.07 1.85 / 1.00 / 1.08 7x 7 0.56 0.30 0.35 1.86 / 1.00 / 1.67 8x 8 2.42 1.32 1.53 1.83 / 1.00 / 1.16 Lewis-Wester test A (divide factorials) IA64 Athlon 21264A Ratio 0.2 0.095 0.05 2.11 / 1.00 / 0.52 Lewis-Wester test B (sum of rational numbers) IA64 Athlon 21264A Ratio 0.025 0.009 0.009 2.78 / 1.00 / 1.00 Lewis-Wester test C (gcd of big integers) IA64 Athlon 21264A Ratio 0.25 0.11 0.075 2.27 / 1.00 / 0.68 Lewis-Wester test D (normalized sum of rational fcns) IA64 Athlon 21264A Ratio 0.6 0.369 0.33 1.62 / 1.00 / 0.92 Lewis-Wester test E (normalized sum of rational fcns) IA64 Athlon 21264A Ratio 0.59 0.299 0.29 1.97 / 1.00 / 0.96 Lewis-Wester test F (gcd of 2-var polys) IA64 Athlon 21264A Ratio 0.07 0.036 0.04 1.94 / 1.00 / 1.11 Lewis-Wester test G (gcd of 3-var polys) IA64 Athlon 21264A Ratio 1.97 1.159 1.02 1.70 / 1.00 / 0.88 Lewis-Wester test H (det of 80x80 Hilbert) IA64 Athlon 21264A Ratio 6.49 3.689 4.07 1.75 / 1.00 / 1.10 Lewis-Wester test I (invert rank 40 Hilbert) IA64 Athlon 21264A Ratio 2.43 1.31 1.56 1.85 / 1.00 / 1.19 Lewis-Wester test J (check rank 40 Hilbert) IA64 Athlon 21264A Ratio 1.26 0.62 0.74 2.03 / 1.00 / 1.19 Lewis-Wester test K (invert rank 70 Hilbert) IA64 Athlon 21264A Ratio 15.5 8.62 9.66 1.79 / 1.00 / 1.12 Lewis-Wester test L (check rank 70 Hilbert) IA64 Athlon 21264A Ratio 7.44 3.54 4.02 2.10 / 1.00 / 1.14 Lewis-Wester test M1 (26x26 sparse, det) IA64 Athlon 21264A Ratio 0.34 0.179 0.19 1.90 / 1.00 / 1.06 timing Lewis-Wester test N (poly at rational fcns) IA64 Athlon 21264A Ratio 817.6 674.399 568.7 1.21 / 1.00 / 0.84 timing Lewis-Wester test P (det of sparse rank 101) IA64 Athlon 21264A Ratio 1.45 0.959 0.64 1.51 / 1.00 / 0.67 timing Lewis-Wester test P' (det of less sparse rank 101) IA64 Athlon 21264A Ratio 5.51 3.12 2.42 1.77 / 1.00 / 0.78 timing Lewis-Wester test Q (charpoly(P)) IA64 Athlon 21264A Ratio 111.07 70.18 52.04 1.58 / 1.00 / 0.74 timing Lewis-Wester test Q' (charpoly(P')) IA64 Athlon 21264A Ratio 225.23 151.34 105.65 1.49 / 1.00 / 0.70 Now let's all rush and get ourselves some Athlons for doing computer algebra. If they only had dual boards... From kreckel at thep.physik.uni-mainz.de Sun Mar 11 17:32:02 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sun, 11 Mar 2001 17:32:02 +0100 (CET) Subject: sqrfree In-Reply-To: <3986BF25.82241271@fourier.ujf-grenoble.fr> Message-ID: On Tue, 1 Aug 2000, Parisse Bernard wrote: > Doing some tests with square-free factorization, I believe I have > found a bug. > Let e by (x+y)^2*(x-y) expanded and call sqrfree(e,x). You do not > get the original expression, it remains expanded. > If y is replaced by 1 it seems it works. Last week I had a look at this. It was a crude copy of Yun's algorithm found in Geddes' book. That algorithm has a minor error, however. :-) I do think it's fixed in the CVS version now: > sqrfree(expand((x+y)^2*(x-y))); (x+y)^2*(x-y) > sqrfree(expand((x+y)^2*(x-y)),[x]); (x+y)^2*(x-y) > sqrfree(expand((x+y)^2*(x-y)),[y]); (x+y)^2*(x-y) By the way, I downloaded giac.tgz the day before yesterday and found the remark "GiNaC import/export is now waiting for a stable interface format." What's that about? Is there anything we can do / clarify? Regards -richy. PS: You really do have factorization over Z[i]?!? Are you going to allow algrbraic extensions like RootOf and all this? -- Richard Kreckel From stefanw at fis.unipr.it Mon Mar 19 11:41:16 2001 From: stefanw at fis.unipr.it (Stefan Weinzierl) Date: Mon, 19 Mar 2001 11:41:16 +0100 (CET) Subject: CLN 1.1 Message-ID: Dear Richy, I was planning to upgrade to GiNaC-0.7 and CLN-1.1, but I ran into a small problem: CLN-1.1 does not build out of the box on my system. After configure and make, in the "test" subdirectory: c++ -O exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o ../src/.libs/libcln.so -lm -o .libs/exam -Wl,--rpath -Wl,/usr/local/lib exam_I.o: In function `test_integer_plus(void)': exam_I.o(.text+0xc1): undefined reference to `default_print_flags' Runnnig nm -u on src/.libs/libcln.so.1.0.0 shows me that default_print_flags is indeed unresolved, together with some other symbols, which I suspect should be better resolved: ... cl_class_bignum cl_class_complex cl_class_dfloat cl_class_ffloat cl_class_fixnum cl_class_gvector_integer cl_class_gvector_number cl_class_lfloat cl_class_modint_ring cl_class_ratio cl_class_sfloat cl_class_string cl_class_svector_number cl_class_svector_ringelt cl_class_univpoly_ring default_print_flags ... I have a slight suspicion that it might be the compiler. The compiler I'm using is gcc 2.91.66 Best regards, Stefan From kreckel at thep.physik.uni-mainz.de Mon Mar 19 12:02:04 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 19 Mar 2001 12:02:04 +0100 (CET) Subject: CLN 1.1 In-Reply-To: Message-ID: On Mon, 19 Mar 2001, Stefan Weinzierl wrote: [...] > I have a slight suspicion that it might be the compiler. > The compiler I'm using is gcc 2.91.66 Bingo! We keep seeing a lot of those problems. Please upgrade your compiler to GCC 2.95.2 or GCC 2.95.3. If your are running RedHat, please see . Luck -richy. -- Richard Kreckel From kreckel at thep.physik.uni-mainz.de Mon Mar 19 13:21:23 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 19 Mar 2001 13:21:23 +0100 (CET) Subject: CLN 1.1 Message-ID: Hi there, Has anybody noticed that Majordomo was written by a bunch of brain-dead morons? When anybody mentioned the word "unstable" in a mail it gets sorted out and ends up as a Majordomo error because they match against the regular expression "/\buns\w*b/i" which is obviously meant for "unsubscribe" but matches other stuff, too. I have deleted the most idiotic patterns from the check and hope it works better now, but if anybody has a good alternative for Majordomo I would like to hear about it. Sorry for being inpolite but it just overcomes you when you have a look at those scripts. It is unbelievable! Now to Julian's question: I hope to package and upload it today or tomorrow. Some people are also eager for Cint and I have sorted out most problems with Masaharu now which so far prevented a reasonable packaging. I don't know yet how that is going to work out, though. As for the library versioning, no that is ok. The numbers attached to the filenames are a priori unrelated to the library version number. If you find this irritating, please have a look at the info page provided by libtool. Sorry, I do not know why you get "checking for CLN - version >= 1.1.0... no". I have just installed cln_1.1.0-2_i386.deb and cln-dev_1.1.0-2_i386.deb and run configure and it works fine. Could you please investigate by having a look at config.log and find out why the test program "failed to compile or link"? (By manually creating that test program and try to get it running.) Regards -richy. PS: I assume that you are running i386 since the build daemon usually takes some days or weeks? -- Richard Kreckel ---------- Forwarded message ---------- Date: Mon, 19 Mar 2001 12:43:58 +0100 From: owner-ginac-devel at thep.physik.uni-mainz.de To: ginac-devel-approval at thep.physik.uni-mainz.de Subject: BOUNCE ginac-devel at ThEP.Physik.Uni-Mainz.DE: Admin request of type /\buns\w*b/i at line 2 Admin request of type /\buns\w*b/i at line 6 >From kreckel at thep.physik.uni-mainz.de Mon Mar 19 12:43:56 2001 Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by zino.physik.uni-mainz.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA22673 for ; Mon, 19 Mar 2001 12:43:56 +0100 Received: from antoinette.snu.ac.kr (mail at antoinette.snu.ac.kr [147.46.115.122]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f2JBhpV08288 for ; Mon, 19 Mar 2001 12:43:52 +0100 (MET) Received: from stoev by antoinette.snu.ac.kr with local (Exim 3.22 #1 (Debian)) id 14ey4Z-00084x-00 for ; Mon, 19 Mar 2001 20:43:39 +0900 Date: Mon, 19 Mar 2001 20:43:33 +0900 From: Julian Stoev To: ginac-devel at thep.physik.uni-mainz.de Subject: Re: CLN 1.1 Message-ID: <20010319204333.A18940 at antoinette.snu.ac.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from kreckel at zino.physik.uni-mainz.de on Mon, Mar 19, 2001 at 12:02:04PM +0100 Sender: Julian Stoev Is there a hope for ginac Debian unstable packages appearing somewhere on the ftp? And BTW, I don't know why, but the names of the cln libs in Debian unstable are: -rw-r--r-- 1 root root 3098108 Mar 16 04:44 libcln.a -rw-r--r-- 1 root root 636 Mar 16 04:44 libcln.la lrwxrwxrwx 1 root root 15 Mar 19 20:24 libcln.so -> libcln.so.1.0.0 lrwxrwxrwx 1 root root 15 Mar 19 20:24 libcln.so.1 -> libcln.so.1.0.0 -rw-r--r-- 1 root root 940300 Mar 16 04:44 libcln.so.1.0.0 Shouldn't these be 1.1.0 libraries? when I start the configure of ginac, I get checking for CLN - version >= 1.1.0... no *** Could not run CLN test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means CLN was incorrectly installed *** or that you have moved CLN since it was installed. In the latter case, you *** may want to edit the cln-config script: /usr/bin/cln-config. I am with Debian unstable updated daily. On Mon, Mar 19, 2001 at 12:02:04PM +0100, Richard B. Kreckel wrote: |Bingo! We keep seeing a lot of those problems. Please upgrade your |compiler to GCC 2.95.2 or GCC 2.95.3. If your are running RedHat, please |see . From pearu at cens.ioc.ee Mon Mar 19 14:06:55 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Mon, 19 Mar 2001 15:06:55 +0200 (EET) Subject: Majordomo alternative (was Re: CLN 1.1) In-Reply-To: Message-ID: On Mon, 19 Mar 2001, Richard B. Kreckel wrote: > > Has anybody noticed that Majordomo was written by a bunch of brain-dead > morons? When anybody mentioned the word "unstable" in a mail it gets > sorted out and ends up as a Majordomo error because they match against > the regular expression "/\buns\w*b/i" which is obviously meant for > "unsubscribe" but matches other stuff, too. I have deleted the most > idiotic patterns from the check and hope it works better now, but if > anybody has a good alternative for Majordomo I would like to hear about > it. Sorry for being inpolite but it just overcomes you when you have a > look at those scripts. It is unbelievable! > Try Mailman for a good alternative, http://www.list.org/ Pearu From stoev at users.sourceforge.net Tue Mar 20 12:32:05 2001 From: stoev at users.sourceforge.net (Julian Stoev) Date: Tue, 20 Mar 2001 20:32:05 +0900 Subject: CLN 1.1 In-Reply-To: ; from kreckel@ginac.de on Mon, Mar 19, 2001 at 01:21:23PM +0100 References: Message-ID: <20010320203205.A30343@antoinette.snu.ac.kr> On Mon, Mar 19, 2001 at 01:21:23PM +0100, Richard B. Kreckel wrote: |As for the library versioning, no that is ok. The numbers attached to the |filenames are a priori unrelated to the library version number. If you |find this irritating, please have a look at the info page provided by |libtool. OK. Thanks. |Sorry, I do not know why you get "checking for CLN - version >= |1.1.0... no". I have just installed cln_1.1.0-2_i386.deb and |cln-dev_1.1.0-2_i386.deb and run configure and it works fine. Could you |please investigate by having a look at config.log and find out why the |test program "failed to compile or link"? (By manually creating that |test program and try to get it running.) I've just rebuild the Debian package from source. To do this I had to install libgmp3-dev. After the rebuild and the install it works fine. Probably there is some obscure dependence on libgmp3-dev in cln-dev, when it was compiled with gmp installed. Probably you have to change your deb depends for cln-dev somehow to include the libgmp3-dev. --JS From kreckel at thep.physik.uni-mainz.de Tue Mar 20 12:47:06 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Tue, 20 Mar 2001 12:47:06 +0100 (CET) Subject: CLN 1.1 In-Reply-To: <20010320203205.A30343@antoinette.snu.ac.kr> Message-ID: Hi Julian, On Tue, 20 Mar 2001, Julian Stoev wrote: > I've just rebuild the Debian package from source. To do this I had to > install libgmp3-dev. After the rebuild and the install it works fine. > Probably there is some obscure dependence on libgmp3-dev in cln-dev, > when it was compiled with gmp installed. > Probably you have to change your deb depends for cln-dev somehow to > include the libgmp3-dev. Not really. CLN links against libgmp3. But the headers are not needed any more for running the library, even not for linking against libcln. (We have rejected a dozen or so patches that "fixed" CLN for use with gmp3 for exactly this reason: we don't want to rely on the gmp header filese being there. All we need to know is sizeof(mp_limb_t), then we can map this to our data structures.) So, we have the following dependencies: cln depends on libgmp3 (but not libgmp3-dev) cln-dev depends on cln and thus on libgmp3 the whole package build-depends on libgmp3-dev Probably something got screwed elsewhere. I will build the cln package again, this time not here but on one of the Debian project machines. Please holler if cln-1.1.0_3 reintroduces the problem on your machine! Regards -richy. PS: Hubert, we could need a machine running woody. Can I just use higgs? -- Richard Kreckel From kreckel at thep.physik.uni-mainz.de Sat Mar 24 20:37:39 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sat, 24 Mar 2001 20:37:39 +0100 (CET) Subject: For the brave and adventurous... Message-ID: ...there is some great new compiler food! It's called GiNaC-0.8.0, it is completely fat- and cholesterol-free and available at every good grocery shop next to you. For the not so brave and adventurous, Debian and RedHat pre-cooked servings are expected to follow next week (well maybe). Here is the summary from the NEWS file: * Complete revamp of indexed objects. Instead of multiple classes for indexed things and their indices there is now only one "indexed" class and two types of indices: "idx" for simple indices and "varidx" for indices with variance. There are predefined delta, epsilon and metric tensors, and a function simplify_indexed() that performs canonicalization and dummy index summations. Matrix objects can be indexed for doing simple linear algebra. * Added an option "expand_indexed" to expand() to perform expansion of indexed objects like (a+b).i -> a.i + b.i * Renamed get_indices() to get_free_indices(), which no longer returns dummy indices and checks the consistency of indices in sums. * sqrfree() factorization fixed and improved syntactically. * subs() works on matrices. * Matrices can be constructed from flat list of elements; diagonal matrices can be constructed from list of diagonal elements with diag_matrix(). * Fixed memory leak in expand(). * Operator% for objects of class ncmul has gone. Use operator* now for that case too, which is much more natural. Happy hacking -richy. -- Richard Kreckel From pearu at cens.ioc.ee Fri Mar 30 12:17:56 2001 From: pearu at cens.ioc.ee (Pearu Peterson) Date: Fri, 30 Mar 2001 12:17:56 +0200 (EET) Subject: lt-exams test is running forever Message-ID: Hi! In my Alpha(ev56) Linux box (with RH6.1, gcc 2.95.2, the latest GiNaC from CVS, CLN-1.1, GMP-3.1.1) the lt-exams test is running already 15 hours: GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia.......... Any ideas why? Pearu From will at brain.ncl.ac.uk Fri Mar 30 17:20:18 2001 From: will at brain.ncl.ac.uk (Will Woods) Date: Fri, 30 Mar 2001 16:20:18 +0100 (BST) Subject: Large archive problem Message-ID: Hi, I am working with large matrices (~100x100) and had trouble with restoring archives of them. I wrote the attached test program which just adds the same expression to an archive n times (with a unique name each time). For any n, the expression can always be retrieved from the original archive. But reloading it from file into a new archive object only succeeds for n<108 (in this case - other size expressions have different limits). Great package though. Our problem solution went from several hours under Macsyma to just 36 seconds with GiNaC! Will System: GiNaC 0.8.0 CLN 1.1.0 Linux Mandrake 7.2 AMD 700Mhz 128Mb -------------- next part -------------- #include "iostream.h" #include #include using namespace std; #include using namespace GiNaC; int main() { // const int n = 108; //Archive is corrupted after saving and loading const int n = 107; //Works fine archive ar; symbol x("x"),y("y"),z("z"); ex foo = sin(x+2*y)+3*z+41; char nme[10]; for (int i = 0; i < n; i++) { sprintf(nme,"foo%d",i); ar.archive_ex(foo,nme); } //Save this archive to a file ofstream fout("test.gar"); fout << ar; fout.close(); //Reload it from file into a new archive archive ar2; ifstream fin("test.gar"); fin >> ar2; fin.close(); try{ ex ex1 = ar.unarchive_ex(lst(x,y),"foo0"); //Works fine for both cases cout << "Original archive gives " << ex1 << endl; // Fails for too large an archive with message // "expression with name 'foo0' not found in archive" ex ex2 = ar2.unarchive_ex(lst(x,y),"foo0"); cout << "Reloaded archive gives " << ex2 << endl; } catch (exception &e) { cout << e.what() << endl; } } From cbauer at student.physik.uni-mainz.de Fri Mar 30 19:13:45 2001 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Fri, 30 Mar 2001 19:13:45 +0200 Subject: Large archive problem In-Reply-To: ; from will@brain.ncl.ac.uk on Fri, Mar 30, 2001 at 04:20:18PM +0100 References: Message-ID: <20010330191345.A25196@iphcip1.physik.uni-mainz.de> Hi! On Fri, Mar 30, 2001 at 04:20:18PM +0100, Will Woods wrote: > But reloading it from file into a new archive object only succeeds for > n<108 (in this case - other size expressions have different limits). There was a bug when there were exactly 128 items of any kind (strings in this case) in an archive. It is fixed now in the CVS. > Great package though. Our problem solution went from several hours under > Macsyma to just 36 seconds with GiNaC! We're all happy that you like it. :-) Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From will at brain.ncl.ac.uk Sat Mar 31 22:14:59 2001 From: will at brain.ncl.ac.uk (Will Woods) Date: Sat, 31 Mar 2001 21:14:59 +0100 (BST) Subject: Large archive problem In-Reply-To: Message-ID: Hello again, The problem appears to be with the routines write_unsigned(..) and read_unsigned(..) in archive.cpp. They work fine for values less than 128, but as an example, try passing 128. The former writes only one byte (and maybe there should be a char cast there??), but the read algorithm reads in two bytes. Sorry I don't have the fix for this, I just implemented a hack of always writing out precisely four bytes every time, which works for me at the moment... Hope this helps. Will On Fri, 30 Mar 2001, Will Woods wrote: > > > Hi, > > I am working with large matrices (~100x100) and had trouble with restoring > archives of them. I wrote the attached test program which just adds the > same expression to an archive n times (with a unique name each time). > For any n, the expression can always be retrieved from the original > archive. But reloading it from file into a new archive object only > succeeds for n<108 (in this case - other size expressions have different > limits). > > Great package though. Our problem solution went from several hours under > Macsyma to just 36 seconds with GiNaC! > > > Will > > > System: > > GiNaC 0.8.0 > CLN 1.1.0 > Linux Mandrake 7.2 > AMD 700Mhz 128Mb > > > > > From ping at lfw.org Wed Mar 28 19:50:11 2001 From: ping at lfw.org (Ka-Ping Yee) Date: Wed, 28 Mar 2001 09:50:11 -0800 (PST) Subject: Minse Message-ID: On Sat, 24 Mar 2001, Pearu Peterson wrote: > > Dear Ka-Ping Yee, > > I am writing a GiNaC (www.ginac.de) interface to Python and by now I have > wrapped most of the GiNaC library. Now I looking for > (preferably GPL,LGPL) tools that can render mathematical formulae to be > displayed on text screens. I just learned about the Minse and it seems to > me that it does exactly what is needed in PyGiNaC. Hi! This sounds like a pretty neat project. It would be cool if my MINSE work could help you in this endeavour. > I am writing to you to ask if you are interested in sharing Minse code in > this project? Only the part that renders a formula to a text is needed. I have put up a preliminary source distribution on my home page (http://www.lfw.org/ping/). It is not documented but i hope you will be able to find your way around it. Download both .tar.gz archives; each one unpacks separately. The "glyphd" archive is the renderer; run "make" there and try ./textren text.cfg lat1 5 It will accept typesetting expressions such as @bar(a + b, at rad(3)) The "minse" archive is the stylesheet engine. It will accept MINSE expressions and turn them into typesetting expressions for the rendering machinery. Try running ./ftext in that directory and typing in MINSE expressions, e.g. skuld[1029]% ./ftext =: a + b -> a + b =: a/b -> a --- b =: 'lim((f(x+h)-f(x))/h, h .approach 0) -> f(x + h) - f(x) lim ----------------- h -> 0 h -- ?!ng I never dreamt that i would get to be The creature that i always meant to be But i thought, in spite of dreams, You'd be sitting somewhere here with me.