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

[fgnievinski]

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.




--
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.