[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave & C++/Octave and symbolic math
From: |
Dirk Laurie |
Subject: |
Re: Octave & C++/Octave and symbolic math |
Date: |
Fri, 5 Jun 1998 12:44:40 +0200 (SAT) |
Steve Hill wrote:
>
> Hi,
> just thought I'd throw my threpence worth in.
>
> Octave is great & jwe has done a magnificant job, but I think that to
> really take it forwards, some major rewriting is eventually going to be
> necessary. I think that the two threads that have been appearing lately
> (Octave & C++ and Octave & symbolic math) are actually linked.
>
> As far as I understand things, octave is heavily based on the fortran
> LINPACK libraries, plus C, plus... The problem (as I see it), is that what
> we really lack is a good unified representation scheme (in whatever
> language it would be implemented -my personal preference would be as C++
> classes) that would allow the representation of various types of
> mathematical expression - symbolic, integer, rational, irrational (e.g.
> pi, e), real etc. With such a set of classes, many numerical matrix/vector
> operations could be rewriten to apply uniformly across the whole gamut of
> mathematical expressions. Eventually, such an integrated library could
> underly octave. Then , not only would octave handle symbolic math in a
> unified fashion with the way it handles numerical math; but also there
> would be a transparant C++ library available to handle this sort of stuff,
> which would integrate with octave.
>
> Now, I'm well aware that this is a huge task, but Rome wasn't built in a
> day. I have a few ideas about how one might go about getting such a class
> library together, and some code that might be useful as a starting point.
> I'd certainly be willing to work on getting an integrated C++ math library
> together. So if anyone is interested, or has some good ideas; let me know.
>
The problem with moving away from LINPACK etc is that those libraries are
maintained on a continuous basis by specialists. The moment you regard
some C++ implementation as your primary source instead, someone has to
take on the job of keeping the C++ source up to date -- someone who is
an expert in the field concerned and an expert in C++. I have a feeling
that such a person may well feel that there are better ways of investing
time than to reinvent the wheel.
Dirk