I was thinking more of a user-level interface, via appropriate header
files, rather than putting GMP under the hood. I agree that the latter
would be "heavy".
Kostas
Steve Wampler wrote:
> Kostas Oikonomou wrote:
>> Good idea. I think doing this this would need Unicon's
>> interface to C, which is currently under
>> development. Perhaps Clint could comment in more detail.
>
> Actually, it shouldn't. This would all be 'under the hood'
> and embedded in the runtime system. (I assume the intent
> is to replace the existing multiple-precision code with
> this library.) Since the runtime system is already C,
> this shouldn't be a problem.
>
> However, is it worth it? I suspect that GMP has many
> features that wouldn't directly benefit Unicon (such as
> rational arithmetic) and thus translate to bloat. Getting MP
> floating-point might be nice - but would be a more substantial
> change than just replacing the existing large integer coard.
>
> Is there anyway to determine what the performance advantage
> would really be? I've never noticed a significant problem
> with the current code - but I don't use Unicon for much
> heavy-duty large-valued numeric processing. I suppose
> the only real way would be to instrument the current
> implementation, replace it, and then compare. (Might
> be a good student project to do this...)
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
