GiNaC with GUI

[Richard B. Kreckel]

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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>