[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-16 20:34:05
[Download RAW message or body]

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

class KMathBackEndIface {
public:
    // expression evaluation, input is a c-like expression
    virtual double evaluateExpression(const std::string& AExprStr) = 0;
    // expression simplification input and output is a c-like expression
    virtual std::string simplifyExpression(const std::string& AExprStr) = 0;

    // library stuff, setting/getting/removing variables that may be
    // either just a real number or even a c-like (sub) expression
    virtual void setVariable(const std::string&, const std::string&) = 0;
    virtual std::string getVariable(const std::string&) = 0;
    virtual void unsetVariable(const std::string&) = 0;
};

class KMathBackEndException {
private:
    unsigned FCode;
    std::string FMessage;

public:
    enum {
        NOT_SUPPORTED_ERR = 1
        EXPRESSION_SYNTAX_ERR = 2,
        EXPRESSION_EVALUATION_ERR = 3,
        VARIABLE_NOT_FOUND_ERR = 4
        // and some other common error codes.
    }

public:
    KMathBackEndException(unsigned FCode, const std::string& AMsg) :
        FCode(ACode), FMessage(AMsg) {}

    unsigned code() cosnt { return FCode; }
    std::string message() const { return FMessage; }
};

// back-end handling
void registerMathBackEnd(const std::string& AName, const std::string& ALib);
KMathBackEndIface *loadMathBackEnd(const std::string& AName);
void unloadMathBackEnd(KMathBackEndIface *);

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.

[...]
> But I think it's more
> natural from the koffice point of view.

do do what?

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

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

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

iD8DBQE+dN/APpa2GmDVhK0RAva6AJ4k9d041XwF0J85s545o2U5EGR7MwCfReZt
GnMP/xQfWcXHx2MYRQCc9qM=
=0QFz
-----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]