Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-10 14:40:37

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/10/2010 01:34 PM, Giovanni Piero Deretta wrote:

> I would actually find some use for a big int class and I hope that
> yours find its way into boost as it is the most promising so far.

I hope so too. :-)

>> What's the difference between having a calculation function that
>> takes the components of raw integers and a class to reallocate 
>> them, and simply sending in the raw integer objects that already
>> have all the components and know how to reallocate themselves?
> 
> Those are not the options. The choice is between having a function 
> that takes one or more generic input ranges and an output range (as 
> most std algos) and a function that only works on some specific 
> integer type.
>
> The advantage would be that the big int algos would work on any
> sequence of bytes (or whatever smallest amount of computation you
> use... probably ints?).

digit_t, defined as the unsigned integral type that's half the size of
the largest integral type the platform supports.

> If I wanted to I could simply use a vector<char> (or deque or
> whatever) and back_inserter without having to write anything more.
> And wouldn't need to use your raw integer object.

As an alternative, you could just write your own raw integer class, or
modify mine. So long as it provides the same interface as the one that I
wrote, the algorithms I've provided will work with it -- they're all
templates.

> As you have experimented yourself in this list, the bigint class
> itself has proved to be the most contentious issue as everybody has
> his own requirements (move vs reference count, fixed buffer vs 
> reallocation, etc).

Yeah, I've noticed. :-(

>> Any algorithm that has to modify the size of a buffer has to deal
>> with memory allocation, one way or another, at some level.
> 
> The fact that std::back_inserter deal with memory allocation in no
> way implies that std::copy (or any other algorithm) needs to deal
> with memory allocation. BTW, the fact that it doesn't need to, does not
> mean that it can't. It is perfectly acceptable (and in fact desirable)
> for std::copy to be specialized to treat optimally back_inserter
> iterators to known containers (for example by explicitly calling
> reserve).

Such a specialization would be very close to what I've got -- the
algorithms tell the raw integer object to reallocate itself to a certain
size, and that's the extent of their dealings with memory allocation.
The object is free to ignore the request, or use a different size; the
algorithms don't assume anything about it, they just work as best they
can with what the object gives them.

>> The more indirect you make it, the harder it is to get speed out of
>> it. I'm trying to make the fastest pure-C++ large-integer
>> implementation I can.
> 
> generic programming in C++ is about having the most flexible 
> abstraction with the smallest abstraction penality. What do you
> think will prevent you from extracting the highest performance?

Experience. :-) There's always a cost to adding indirection, be it in
run-time performance, longer compile times, higher memory usage, or more
work for the developer or user of the library. I'm trying to get the
maximum performance for the amount of work it requires to write and
maintain the library, while at the same time making it as easy for the
end user to use as possible. Minimizing compile times and memory usage
are secondary, but still concerns.

> There are probably many people on the boost mailing list that could
> give advice.

I've got advice coming out of both nostrils and an ear already. Some
good and some not so good, and it's difficult figuring out who knows
what they're talking about sometimes, and which parts of the good advice
are even applicable to this library.

That said, I've been trying to take as much of the good advice as I can.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwRMaIACgkQp9x9jeZ9/wSSSgCfUoP4CMntWmxDgvWKVY/HEA8X
npoAnA1sq0DfFe1FteZDmF9VwYhlqWpz
=PkKB
-----END PGP SIGNATURE-----