help-octave
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]