[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 15:42:31
[Download RAW message or body]

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

On Tuesday 18 March 2003 12:55 pm, Ulrich inspired the electrons to say:
> On Tuesday 18 March 2003 05:54, Christian Parpart wrote:
> > > > 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(?).
>
> I fully agree. That's the central question. And as we talk about koffice I
> have a strong preference for the former. koffice is aimed at people that
> want to get their stuff done without being scared away by software
> internals.

I don't see any problem here  ;-)

> > > 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.
>
> It's questionable if this flexibility can be achieved. And this is not a
> mere technical question. You need to communicate to your users how to
> combine which backends with which adapters to get certain sets of features
> with certain bugs. That's not the kind of question an office user wants to
> think about.

um.... as I can remember, you told us just 3 things you wanna see in koffice, 
so what certain sets of features are you talking about?

> > science work. Do you want him to use everything but koffice, just because
> > he can't/doesn't want use M?
>
> Nobody who doesn't want to needs to do maths with koffice (even when it's
> possible... someday.) If he is happy with what he's got, why should he
> bother with something new?

Yeah, I really was happy with KDE 2.2.2, too. I'm sure you, too, didn't you?
I guess you switched over because KDE 3 is more improved and so on.
Apply this to a math back-end. Why should I upgrade/move? Because the other 
nad/or new package does support linear regression tests in expression string 
syntax e.g. I could give lots of examples, but do they all really matter by 
now? Don't think so ;)

> > > (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.
>
> My current plan is to build the smallest package that could possibly be
> useful. From there it will be possible to add more. So I want to be able to
> (a) evaluate formulas numerically, (b) plot functions, and (c) define
> functions graphically pretty much the way MathCAD does. This surely won't
> make a huge scientific application but will be valuable for many ones that
> need to do some simple computation quickly. Heavy scientific work will need
> other tools.

Exactly. You wanna use exactly 3 features by the given back-end. Don't tell me 
that _this_ will be a mess to bring up a common bridging interface. Let's 
call it generic, or back-end independant. I personally don't _really_ like 
octave. This may (by the time) change of course. But actually... no.

> > 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?
>
> I don't see a difference between the user-level or koffice itself. Just
> think about emacs or texmacs. The backend's scripting language (that only
> the advanced koffice user will know about) is a completely different story.
>
> > > > 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/
>
> Nice. ;)
> (Who doesn't like Kaesetorte?)

Sorry, what???!? 
I hope u'r just kidding me.

Go, write it yourself, _without_ _any_ _help_ of anyone, and then tell me 
"Kaesetorte".....

naa..... forget it, you don't need to answer, I give up. seem very stubbornly 
to see that there're also advantages of such a generic interface I intent to. 
And, not only to repeat, this has nothing to do with libmath++.

Greets,
Christian Parpart.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+dz5nPpa2GmDVhK0RApNUAKCFVK8AmichaH84JJZzh1oB7BBcmgCfeVED
FRtebd91+7Ehhf0DpIMrU/c=
=LVjk
-----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]