$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Richard Peters (r.a.peters_at_[hidden])
Date: 2004-04-30 05:01:01
----- Original Message -----
From: "Christoph Ludwig" <cludwig_at_[hidden]>
> Hi,
>
> > There is not much special about my library. Like the gmp, this library
uses
> > expression templates to avoid the creation of temporary values, which
when
> > the values become large provide an increase in performance.
>
> I sometimes wonder whether a bigint library that implements move
> semantics could not provide an additional significant efficiency
> gain. (Since I can avoid temporaries most of the time, my applications
> don't profit from expression templates that much.) I never performed
> experiments, though, this is only a conjecture.
>
> Do you have any plans in this direction?
What would implementing move semantics look like? Do you mean that an
expression like x = y * z where y and z aren't used after this expression
can be implemented as a swap(x, y); x *= z? I'm not sure how to implement
it, but if a method exists which provides a significant efficiency gain and
does not interfere with the interface too much, then I'm certainly
interested in implementing it.
> > Once the
> > interface matures, I want to make the library be able to use other
arbitrary
> > magnitude libraries to perform high-speed calculations.
>
> Hm, I "inherited" some time ago the task to maintain a computer
> algebra library that can be built on top of several bigint libraries.
> Since these libraries are optimized for different use cases and this
> fact shows in their respective interfaces, it is hard to come up with
> a wrapper that does neither favour one particular library nor pulls
> all libraries down to their least common denominator.
My idea was to delegate the simple operations +, -, * etc. to the other
libraries, like gmp. This makes the speed of the library higher in the case
such a library is installed, but does not give me the burden of coding
really efficient versions of those operators myself. The big integer library
will remain a reasonably general-purpose integer library. I do not intend to
make this library cover every area where large integers are needed, but I
want to provide a reasonable library for average integer calculations. I
intend to use this library for cryptographic algorithms, where I want decent
performance, but also a simple intuitive interface. Therefore, I would like
a 'normal' library where the backend is adapted to the frontend, and not the
other way around.
Best regards,
Richard Peters