From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-05-26 17:15:08
Yes, I will add your sentence about complexities,
and I will replace the word "optimal" with "optimized",
"Beman Dawes" <bdawes_at_[hidden]> wrote in message
> "Andras Erdei" <aerdei_at_[hidden]> wrote in message
> > On 5/24/06, Maarten Kronenburg <M.Kronenburg_at_[hidden]> wrote:
> >> In the boost vault
> >> http://boost-consulting.com/vault/
> >> under Math - Numerics the document
> >> infintdraft.pdf contains the
> >> Proposal for an Infinite Precision Integer
> >> for Library Technical Report 2, Draft.
> >> Any comments are welcome.
> > 1. My main concern is that both the interface and the specification seem
> > to
> > be too implementation-driven.
> > For example, i don't see any reason for specifying the time-complexity
> > the operations...
> The LWG discussed this, and decided that the time-complexity should be
> specified tightly enough to require implementations that are broadly
> but not so tightly as to require heroic efforts by implementors.
> > 5. Summary
> > It is high time to get an integer into the standard, but i would prefer
> > very minimal (strictly int-mimicking, no additional operations etc) one.
> The LWG also discussed this, and would like a fairly minimal approach
> (incidently, it is for TR2, not the standard itself). However, certain
> additional functions are required for real-world applications, and are
> efficient if part of the implementation.
> > Of course, the boost _implementation_ can provide a lot more than
> > this minimal integer, and when we have enough experience, then we
> > can bloat the interface to support common use-cases.
> > Similarly, let's restrict implementations as less as possible: if
> > ever comes up with a logarithmic integer class that provides O(N)
> > multiplication in exchange for addition being O(N*logN), then let them
> > do so...
> It might be possible to allow such an implementation by providing an
> clause. Perhaps something like: "Complexity requirements for certain
> functions may be relaxed if doing so allows improved complexity for other
> functions. Such complexity relaxations and improvements shall be
> by the implementation."
> Is that a good idea? I don't know enough about the problem domain to have
> strong opinion.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk