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

[Georgios Ouzounis]

On 21 March 2014 16:32, fgnievinski <address@hidden> 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.