The challenge may not be where you expect it. For instance, Matlab
Central has an "mptoolbox" entry. It defines a new class, and
interface to GNU MPL using mex files. I just tried it, it is sort of
working. License is BSD, can we use it as a starting point ? Can we
relicense it under GNU GPL ?
If you want to interfere with fortran libs, the challenge is the data
type. Either you use quadruple precision (it will be better but still
limited), either you use the same approach as in MPACK, i.e. define a
new fortran type. Once the choice is made, what comes next with
respect to BLAS and LAPACK ? Rewrite everything ? Touch everything ?
Provide some wrapper ? The real issue in my opinion is that you can't
just re-use fortran code, saying 'I want this algorithm to work on
another data type'.
Regards
Pascal
2013/6/24 Richard Clift <address@hidden>:
Hey Pascal :)
Hmmm interesting! I never made had to interface with octave's own fortran
libs before but
could be a nice challenge! :)
I'll at least give it a look!
Richard
On Mon, Jun 24, 2013 at 5:32 PM, Pascal Dupuis <address@hidden> wrote:
Hello Richard,
A place where I find Octave could be better is about high-precision
arithmetic. Currently, a matrix is considered as badly scaled if its
condition number is smaller than 10^16; with some kind of simulations
this is a limiting factor.
There are a number of higher precision libs: Gnu MPL, ARPREC, MPACK, ...
Supporting higher precision means
1) choosing some lib
2) integrating it smoothly inside Octave
3) make either a new octave type, either a new octave class available
in order to support it
4) imagine how to bind this new type with the octave core functions,
in particular the fortran libs
Regards
Pascal
2013/6/24 Richard Clift <address@hidden>:
Hey,
I'm a PhD in applied maths in england and I want to improve my
programming
so I thought it be a good idea to help out Octave.
I thought I start off small and then increasingly to more and more!
so i'm open to suggestions hopefully I can help :)
Richard