Hi, On Mon, 15 Jan 2001, Stefan Weinzierl wrote:
we wrote a small program called gTybalt, which combines GiNaC, Root and TeXmacs.
Many thanks for doing this! Now, Stefan, would you share the little secret about the name "gTybalt" with us or am I just dense right now? It certainly doesn't seem to be rot13...
This yields a graphical user interface to GiNaC.
Since the Root-package includes CINT, you basically have the same functionality as ginac-cint.
In addition, gTybalt provides routines for plotting functions of one or two variables. The plotting routines are based on Root and are quite fancy.
Furthermore by integrating TeXmacs, you get high-quality output, e.g. mathematical formulae are displayed using TeX fonts.
TeXmacs is a what-you-see-is-what-you-get editor and the resulting formulae can easily be converted to LaTeX.
At the present stage, the very first alpha-release of gTybalt is available. (This means: Don't expect too much !) You are welcome to visit the web-site
http://www.fis.unipr.it/~stefanw/gtybalt.html
for more information and the source code.
Okay, installing all those supporting packages is a somewhat intrusive procedure. We had a close look at it, though. I have a couple of comments on the patches you applied to the GiNaC files. For those who haven't seen them yet, let me sum up: they consist of a bunch of `#ifdef __WITH_GUI__' delimited statements that turn the output function to something useful for TeXmacs. This works great. But, frankly, it is ugly. Our Todo-List <http://www.ginac.de/ToDo.html> says something about "systematic I/O-Philosophy". There might be people who wish to have their expressions directly print OpenMATH or MathML or MathML or Maple-Input or Mathematica-Input... You name it. What we *should* do instead of defining more and more .print_my_fancy_format(ostream & os) methods to the interfaces is this: * define some printflags (maybe an enum) that tells how the output should look like, * make ex::print(), basic::print()... aware of these flags and handle everything inside those print functions -- but without bloating them (by moving out code into static functions as far as reasonable). * [optional] some of the already existent print methods may be eliminated now, if the flags can incorporate this distinction. Let's go one step further towards "the best of all worlds"(tm). Ideally, in the end one would write code like this, using manipuators: ex e = 3/2*pow(Pi,2); cout << e << endl; // prints 3/2*Pi^2; cout << ginsh << e << endl; // ...the same in this case... cout << tex << e << endl; // prints \frac{3}{2}\Pi^2 // 1 2 cout << pretty << e << endl; // prints --- Pi // ... imagine more... // 2 This can't be done so simply, since std::cout is an object of type ostream and it simply not clever enough to remember such states as tex, pretty and so on. It is only designed for hex, oct, boolalpha and a few others. However, it is straightforward to derive your own class from ostream that handles such flags and define a GiNaC::ostream cout; somewhere so one could choose it simply by saying using GiNaC::cout;. Chapter 21 in Bjarne Stroustrup's Book TC++PL3 (The C++ Programming Language, 3rd ed.) is a readable and rather realistic description of streams in C++ and gives enough insight to implement this. Stefan, since you had a look at the output and understand it and since the output must be reorganized anyways and since I am rather busy on other frontiers and since I would love to have your routines in GiNaC (once they are reorganized), would you be willing to volunteer on this? And remember: good patches are very welcome!
Please note that at the moment gTybalt is based on OLD VERSIONS of GiNaC and CLN. You need GiNaC 0.6.4 and CLN 1.0.3.
Oh, it just crosses my mind: Please check out the configure.in file in GiNaC's CVS if you want to port it to 0.7.0 and CLN 1.1. The configure script shipped in GiNaC 0.7.0 unfortunately triggers some problems in conjunction with Cint. They are resolved now, since Masaharu Goto seems to have settled on a new scheme for overloading operator new(). freedom, luck and happy hacking -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>