[RFC] Integrating High-precision arithmetic into Octave Core ?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Integrating High-precision arithmetic into Octave Core ?

CdeMills
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 bottom-up 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.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/gouzouni/5629499534213120
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

fgnievinski
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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

CdeMills
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
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Jordi Gutiérrez Hermoso-2
In reply to this post by fgnievinski
On Fri, 2014-03-21 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.



Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

fgnievinski
In reply to this post by CdeMills
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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Georgios Ouzounis



On 21 March 2014 16:32, fgnievinski <[hidden email]> wrote:
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.

Hello Felipe,

Correct me if I am wrong here but I think there has been a misunderstanding between you and Pascal. I suppose when you talk about a new "class" you mean a new package containing that class right? The cons that Pascal wrote where referring to the creation of a "new type as part of Octave's core" while you asked if we see any cons on creating a new package. ( again, please correct me if I am wrong  ).

To argue a little in favour of creating a new type and embedding it on Octave's core, yes there is a bigger risk on hurting other portions of Octave if we are not careful and that is why, if we go for it, we will need Octave's core developers assistance, but 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.

To sum up, we want other Octave's developers opinions and that is why we started that discussion here on the mailing list. If you think that creating a new basic type for Octave is too much for a GSoC project, then a new package would be the way to go, but if you think it doable, we would need your help and guidance.

Georgios Ouzounis.


--
View this message in context: http://octave.1599824.n4.nabble.com/RFC-Integrating-High-precision-arithmetic-into-Octave-Core-tp4663230p4663236.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

fgnievinski
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 arbitrary-precision 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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

CdeMills
In reply to this post by Jordi Gutiérrez Hermoso-2
Jordi Gutiérrez Hermoso-2 wrote
On Fri, 2014-03-21 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
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Georgios Ouzounis
In reply to this post by fgnievinski



On 21 March 2014 17:48, fgnievinski <[hidden email]> wrote:
>I fail to see how this reuse is possible -- you cannot input
>arbitrary-precision 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 "float-on-steroids" 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!

Georgios Ouzounis.

--
View this message in context: http://octave.1599824.n4.nabble.com/RFC-Integrating-High-precision-arithmetic-into-Octave-Core-tp4663230p4663239.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Nir Krakauer-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Georgios Ouzounis

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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

fgnievinski
In reply to this post by Georgios Ouzounis
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
> >arbitrary-precision 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 "float-on-steroids" 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 sub-classing the built-in type "double".    That way you can call methods of the built-in class and other built-in 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 re-implement fminsearch, only the functions and operators called by fminsearch that operate on your class.

For details, please see:
- Behavior of Built-In Functions with Subclass Objects
<http://www.mathworks.com/help/matlab/matlab_oop/subclassing-matlab-built-in-classes.html#brr3cdl-1>
- Invoking Superclass Methods in Subclass Methods
<http://www.mathworks.com/help/matlab/matlab_oop/ordinary-methods.html#brdqjju-1>

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.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Georgios Ouzounis

> I did a little bit of research and it seems the best route would be
> sub-classing the built-in type "double".    That way you can call methods of
> the built-in class and other built-in 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 re-implement fminsearch, only the functions
> and operators called by fminsearch that operate on your class.
>
> For details, please see:
> - Behavior of Built-In Functions with Subclass Objects
> <http://www.mathworks.com/help/matlab/matlab_oop/subclassing-matlab-built-in-classes.html#brr3cdl-1>
> - Invoking Superclass Methods in Subclass Methods
> <http://www.mathworks.com/help/matlab/matlab_oop/ordinary-methods.html#brdqjju-1>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Integrating High-precision arithmetic into Octave Core ?

Jordi Gutiérrez Hermoso-2
In reply to this post by CdeMills
On Fri, 2014-03-21 at 08:55 -0700, CdeMills wrote:
> Jordi Gutiérrez Hermoso-2 wrote
> > On Fri, 2014-03-21 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.