|
From: | Georgios Ouzounis |
Subject: | Re: [RFC] Integrating High-precision arithmetic into Octave Core ? |
Date: | Fri, 21 Mar 2014 17:34:16 +0200 |
CdeMills wrote
>>I think (3) is not true -- unimplemented overloaded methods will simply
> 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
>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.
--
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.
[Prev in Thread] | Current Thread | [Next in Thread] |