

Hello,
One of the topic proposed for GSOC2014 is to have a fully fonctionnal support for High Precision Arithmetic [1] computations in Octave. The proposal comes from Georgios Ouzounis and I propose myself as mentor.
Basically, it is a layer over GNU MPFR, which is itself a C library. So far, two strategies have been defined:
1) use the extension mechanisms of Octave to construct something outside core, most of the code being written in C++.
2) define a new basic type in libinterp, and do a bottomup approach to ensure upper layers handle transparently this new type.
Strategy 1 implies the development of a toolbox living its own life. Strategy 2 implies changes to Octave core, and a new "configure" option. The external toolbox already exists on OctaveForge. The second strategy implies to create a new branch on the main repository, with the goal to merge it at the end of the GSOC period.
In order to take fix the framework before the start of the coding period, I ask your advice: is there sufficient interest/value to Octave in having this new type targeted as becoming a basic type ? If yes, who could give advice and guidance over integrating this new type in libinterp ?
Regards
Pascal
[1] https://www.googlemelange.com/gsoc/proposal/review/org/google/gsoc2014/gouzouni/5629499534213120


If you define a new class, it effectively acts as a new data type from the user's perspective, so it seems to fulfill your usage requirements. The main pro is greater code separation. Of course, you can implement any of its methods in C/C++. Are there any cons?
F.


fgnievinski wrote
If you define a new class, it effectively acts as a new data type from the user's perspective, so it seems to fulfill your usage requirements. The main pro is greater code separation. Of course, you can implement any of its methods in C/C++. Are there any cons?
F.
Yes:
1) increase core compilation time and executable size
2) inadvertently break something
3) maybe that it will be required to adapt some upper layer functions making too restrictive assumption about its basic arguments
1) can be quantified/profiled; 2) is by nature random; about 3) changes will have to be carefully evaluated in order not to break previously working code not aware of High Precision numbers
Regards
Pascal


On Fri, 20140321 at 05:10 0700, fgnievinski wrote:
> Of course, you can implement any of its methods in C/C++.
Please, no C/C++. Just C++.
 Jordi G. H.


CdeMills wrote
fgnievinski wrote
If you define a new class, it effectively acts as a new data type from the user's perspective, so it seems to fulfill your usage requirements. The main pro is greater code separation. Of course, you can implement any of its methods in C/C++. Are there any cons?
F.
Yes:
1) increase core compilation time and executable size
2) inadvertently break something
3) maybe that it will be required to adapt some upper layer functions making too restrictive assumption about its basic arguments
1) can be quantified/profiled; 2) is by nature random; about 3) changes will have to be carefully evaluated in order not to break previously working code not aware of High Precision numbers
I think (3) is not true  unimplemented overloaded methods will simply result in, e.g., "Undefined function 'svd' for input arguments of type 'mp'."; existing implementations will never be called when input is an instance of class mp.
Regarding (2), the chances of breaking something are far far greater if Octave base is modified, compared to implementing a separate class.
As for (1), that assumes everybody wants the new data type; I think an optional package would serve better.
If I were you, the only doubt would be between implementing it using the new classdef or the old class syntax.
F.


Georgios Ouzounis wrote
On 21 March 2014 16:32, fgnievinski < [hidden email]> wrote:
...
To argue a little in favour of creating a new type and embedding it on Octave's core ... the main gain would be that if a new basic type is successfully created, then a good deal of already existent Octave's functions will be able to work upon multiple precision numbers.
As far as the language to be used is concerned, it is going to be mainly
C++ and if we the need comes up we might use .m files.
I fail to see how this reuse is possible  you cannot input arbitraryprecision numbers to BLAS/LAPACK or any other library used internally by Octave. Thus method/operator overloading seems inevitable. The only question is at what level that is going to happen. I'm arguing for overloading at the Octave level. You seem to prefer overloading at the C++ level. Notice if you do the former, you can still implement any individual method in C++ via MEX.
F.


In reply to this post by Jordi Gutiérrez Hermoso2
Jordi Gutiérrez Hermoso2 wrote
On Fri, 20140321 at 05:10 0700, fgnievinski wrote:
> Of course, you can implement any of its methods in C/C++.
Please, no C/C++. Just C++.
Jordi,
MPFR IS C. There are (at least) two C++ interfaces, but maintained outside MPFR. If we choose one of them and its development later stops, this will become hard from a maintenance perspective. In my opinion, it is simpler to encapsulate ourself MPFR directly. One less layer; one less source of issues.
Regards
Pascal


I think it makes more sense to think about doing this as a package now. If the implementation is successful it can always be added to core Octave as a future project.


Hello Nir Krakauer,
Thank you for taking the time to provide some feedback! Creating a package is always one of the two ways to go! It will surely be more independent as a package!
Georgios Ouzounis.
On Mar 21, 2014 6:42 PM, "Nir Krakauer" < [hidden email]> wrote:
I think it makes more sense to think about doing this as a package now. If the implementation is successful it can always be added to core Octave as a future project.


Georgios Ouzounis wrote
On 21 March 2014 17:48, fgnievinski < [hidden email]> wrote:
> >I fail to see how this reuse is possible  you cannot input
> >arbitraryprecision numbers to BLAS/LAPACK or any other library used
> >internally by Octave. Thus method/operator overloading seems inevitable.
> >The only question is at what level that is going to happen. I'm arguing
> for
> >overloading at the Octave level. You seem to prefer overloading at the
> C++
> >level. Notice if you do the former, you can still implement any
> individual
> >method in C++ via MEX.
>
> F.
>
>
Felipe,
I am quoting what Pascal Dupuis wrote as a comment under my proposal on
Google melange site, answering one of your questions :
"what I would like to have as basic property about those MP values is that
they become some kind of "floatonsteroids" which are transparently
handled by .m file. If some algorithm does not make any distinction between
float and doubles, and return some floating point number with the same
accuracy (significant digits) as its input values; it should unmodified
exhibit the same behaviour for MP value. This implies that MP become some
basic octave class. A number of functions choke when the input data are of
type "class"."
That is what I want to achieve! I clearly don't have all the answers yes,
and that is why I am asking other core developers to assist on this project
if they are willing to. The question is, can you see that happening? Can
you see that happening in the three month period of GSoC? I have never
worked on an open source project before, so I am pretty bad at estimating
the time needed for such a project! That is why I am asking for your
expertise on the subject!
I did a little bit of research and it seems the best route would be subclassing the builtin type "double". That way you can call methods of the builtin class and other builtin functions directly with objects of the subclass.
You'd have a mixture of method implementations. The basic arithmetic operators would be overridden, calling MPFR internally via MEX.
For example, you do not need to reimplement fminsearch, only the functions and operators called by fminsearch that operate on your class.
For details, please see:
 Behavior of BuiltIn Functions with Subclass Objects
< http://www.mathworks.com/help/matlab/matlab_oop/subclassingmatlabbuiltinclasses.html#brr3cdl1>  Invoking Superclass Methods in Subclass Methods
< http://www.mathworks.com/help/matlab/matlab_oop/ordinarymethods.html#brdqjju1> Not sure how far the Octave classdef implementation is, but I guess it'd be a nice incentive to have one more project using it.
F.


> I did a little bit of research and it seems the best route would be
> subclassing the builtin type "double". That way you can call methods of
> the builtin class and other builtin functions directly with objects of the
> subclass.
>
> You'd have a mixture of method implementations. The basic arithmetic
> operators would be overridden, calling MPFR internally via MEX.
>
> For example, you do not need to reimplement fminsearch, only the functions
> and operators called by fminsearch that operate on your class.
>
> For details, please see:
>  Behavior of BuiltIn Functions with Subclass Objects
> <http://www.mathworks.com/help/matlab/matlab_oop/subclassingmatlabbuiltinclasses.html#brr3cdl1>
>  Invoking Superclass Methods in Subclass Methods
> <http://www.mathworks.com/help/matlab/matlab_oop/ordinarymethods.html#brdqjju1>
>
> Not sure how far the Octave classdef implementation is, but I guess it'd be
> a nice incentive to have one more project using it.
>
> F.
Thank you for your proposal Felipe! It will take a while for me to do my study on your suggestion and come back to the list!
Georgios Ouzounis.


On Fri, 20140321 at 08:55 0700, CdeMills wrote:
> Jordi Gutiérrez Hermoso2 wrote
> > On Fri, 20140321 at 05:10 0700, fgnievinski wrote:
> >> Of course, you can implement any of its methods in C/C++.
> >
> > Please, no C/C++. Just C++.
>
> MPFR IS C.
Using C++ to interface to C is fine. What I meant that I don't like is
this mixture of styles where you use malloc and free in C++ code
instead of new and delete, or macros instead of templates (for
example). If possible, RAII wrappers to the C code should be written.
If possible, templates should be used instead of macros. If possible,
use polymorphism instead of switch statements on type. This is how all
of Octave works, especially for wrapping the Fortran libraries and the
occasional C library.
Although most of C is a subset of C++, one should not write C++ as if
it were C. And for new Octave code, we really should avoid writing C
unless absolutely necessary. It's just a pet peeve when people say
"C/C++" as if they were the same language. For example, few people say
something like "you can implement any of its methods in Java/Haskell".
 Jordi G. H.

