[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Mathematics with koffice
From:       Ulrich Kuettler <ulrich.kuettler () mailbox ! tu-dresden ! de>
Date:       2003-03-17 15:44:29
[Download RAW message or body]

On Sunday 16 March 2003 21:34, Christian Parpart wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 16 March 2003 10:53 am, Ulrich inspired the electrons to say:
> > On Friday 14 March 2003 21:13, Claus O. Wilke wrote:
> > > Clearly everybody will have a different opinion on what is the best
> > > backend. Therefore, it would probably be good to keep the architecture
> > > open, so that it is possible to use different backends. As an example,
> > > look at the texmacs project (http://www.texmacs.org/), which allows you
> > > to use a variety of different free and proprietary computer algebra
> > > systems.
> >
> > Hmm. texmacs is an interesting project. But as far as I can see texmacs
> > acts as shell for various algebra systems. That is the user still
> > interacts with a specific system and has to know its syntax. My aim is to
> > completely hide the backend. This way an occasional user does not need to
> > know who does the numerics. So the chosen backend should not really
> > matter. But this approach also forces a real tight integration. Currently
> > I link octave's libraries and use their objects directly. There is no
> > easy way to switch to another backend.
>
> You may be wrong:
>
> [interessting code deleted...]
>
> You can fully abstract the back-end by providing your own interface that
> represents the other back-ends. Now you need, of course, to write an
> interface implementation that acts as a bridge to the real back-end. But
> even here I see no problem. And, the error management can be done over a
> single exception class (KMathBackEndException) that gets a detailed message
> string and a exception code value.
>
> Think about it, it's possible.
>

Uhm. Yes, indeed. You are right. It's indeed possible. It's not as easy as 
your code suggests, just think about graphical programming or plotting 
functions, but still it can be done.

However I doubt if it's worth the trouble. After all, if it's done right you 
could switch the backends and wouldn't notice a difference. The idea was to 
completely hide the backend. So what could be gained by changing it?

Okay, from a math engine writer's point of view this is rather arrogant. So I 
apologize. ;) Of course you gain something by changing the engine. But still 
the question remains whether this gain is worth the much increased effort.

(That's really a question to me. Even if I cannot promise to implement the 
biggest possible solution very soon I'm very much interested in what is 
needed.)

>
> > But I think it's more
> > natural from the koffice point of view.
>
> do do what?

To hide the math engine's syntax behind a "graphical" formula input. In 
opposite to texmacs where the engine's answer is "simply" displayed nicely.

>
> > The flexibility of texmacs bases on the powerful builtin script language.
> > This is something I'd love to see in koffice, too. Maybe a good script
> > language could allow both an open architecture with tight integration.
> > But there is no such language yet.
>
> Yeah, but in this case you _need_ to write it yourself. I mean, you can't
> use already existing scripting engines implemented in the already existing
> back-ends. And, of course, this is even not recommented since they don't
> feel compatible each other.

Oh, it seems I wasn't clear enough. I was talking about a scripting language 
like texmac's guile. Such a beast could help a lot in any case.

>
> However, I definitely vote for a interface bridge to support multiple,
> different back-ends of math engines. This would even allow me to use my own
> yet not that featured implementation of math engine, libmath++ (which is
> fully featured by C++, no c no lisp no f/f77).
>

Interesting. Is there any code to be seen yet?

Greetings,
Uli

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]