Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-04 02:39:28

On Thu, 03 Mar 2011 21:28:35 +0100
Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:

> On 03/03/2011 17:10, Chad Nelson wrote:
>
>> Not the same case at all. XInt isn't a language, it's a library
>> that's explicitly designed for very large numbers. If someone didn't
>> need numbers larger than the built-in types can handle, they
>> wouldn't use it.
>
> So you're already limiting the application area of XInt.
>
> The problem is that the application area you're restricting it to 
> doesn't seem to be the one that is the most likely to require
> arithmetic with infinite precision.

That makes no sense. It's a large-integer library. How does designing it
specifically for large integers make it unsuitable for its purpose?

>>> - So that the library is easily extendable
>>
>> What would you want to do to the internals of it that it doesn't
>> already provide, and that I wouldn't be willing or even eager to add?
>
> There are hundreds of functions that you can use with integers, each 
> with their own algorithms documented in various research papers.
> Do you really claim that your library can provide all of them?

Do they require specialized bit-twiddling? Or are they arithmetic
operations that can be described in terms of functions that the library
already provides?

>>> [...] If the user provides a SIMD type as a digit, you'll get
>>> optimized SIMD code for free, for example, in a completely
>>> externalized way. Now *that* would be awesome. [...]
>>
>> Yes, it would. But it would come at a cost.
>
> The design I am proposing would allow you to "outsource" the
> low-level optimizations and concentrate on the algorithms.
>
> Do you not see the value in this?

Certainly, but it doesn't outweigh the cost.

>>> Something else, I went through a code a bit, and I saw virtual
>>> inheritance. Just why do you need dynamic dispatch in a design where
>>> all information is purely static?
>>
>> For the policy-based options.
>
> I don't see how that requires virtual inheritance.

Yes, it's always much easier to attack something than to build it in
the first place.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*