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

List:       koffice-devel
Subject:    Re: Mathematics with koffice
From:       Christian Parpart <cparpart () surakware ! net>
Date:       2003-03-18 4:54:22
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 17 March 2003 4:44 pm, Ulrich inspired the electrons to say:
> On Sunday 16 March 2003 21:34, Christian Parpart wrote:
> > 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.

*heh* My code I suggested was just in time coded as I was writing 
this mail ;) So, of course, it may provide more.  But the question is, 
do you want an office application or a science framework for maths 
and others(?).

And even if you want to see this in koffice as a base feature, you must 
know not everybody has a math back-end installed there. Of course, 
not everybody loves math ;-)  or just has to do maths. 

However, providing an back-end interface that works with different 
engines will surely provide a tester methods like
virtual bool supports(const std::string& AFeature) const = 0;
which is well known in the W3C's DOM world e.g.

if (engine->supports("3dplot-widget"))
    provide3dPlotWidget(engine);

> 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?

The ability to switch alternatively to a different backend that supports 
the feature X more stable (think of recurive functions, infinite numbers, 
etc.) Although to extend the functionality by replacing the old backend 
with either a newer version or even another once, where the second 
point is more important.

> 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.

Of course, the subject was what let me feel to carefully read the posts.
However, having the ability to switch to my own back-end _some_ day is 
not the only reason for me to push this up. Think about, a guy X doesn't 
want the math package M to be installed or even can't do so, but guy X 
has already installed the math package P which is at least same powerfull 
than M. And, most important, we want's to use koffice has his UI for his 
science work. Do you want him to use everything but koffice, just because 
he can't/doesn't want use M?

> (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.)

For this, I'd suggest that we make a proposal of what we really want koffice 
can do and what of them may stay optional.
Also, note, putting most features in doesn't really feature koffice for sci 
workers, a to full bloated application doesn't seem to be an invitation for 
every interests.

[snip]
> > > 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.

Shall that (unified) scripting language be for the user-level or for koffice 
itself to bridge the backend or (as I propose) for the backend currently 
used?

However, both is possible and needs an implementation of that language at 
koffice level. One answer for the why may be that the currently existing 
science scripting language are definitely not intuitive enough (as we talked 
about some day in kde-edu-devel) and we, though, need something that is easy 
to learn for the user, intuitive, and selfdescribing.

> > 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?

http://freshmeat.net/projects/libmath/
It is currently (and unfortunately still) in 0.0.3 but stable and already 
accepted as it seems so. However, I've some some yet uncommitted 
code in my local repository that will be checked in as it's ready. I've 
actually holidays (for about 2months) so I've time to improve and extend 
alot). The next release will contain a completely redesigned expression 
simplification (generic) and its own scripting language.

Best regards,
Christian Parpart.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+dqZ+Ppa2GmDVhK0RAuuUAJ0fs0l9TdbeQ0nhwz1Vw1ghUyfiggCcDFv9
Q6SuxOS87TRW0h64Fbr/vV4=
=8V9Y
-----END PGP SIGNATURE-----

_______________________________________________
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]