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

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-03-05 14:07:05

On 05/03/2011 17:02, Chad Nelson wrote:
> On Sat, 05 Mar 2011 15:53:30 +0100
> Mathias Gaunard<mathias.gaunard_at_[hidden]>  wrote:

>> It's not tailored to particularly large integers (well, in truth,
>> using it with very large integers would be catastrophic, because the
>> algorithms don't have good complexities).
>
> It can easily handle the range of values that are used in public-key
> encryption, which exceed the number of atoms in the universe by many
> orders of magnitude. If you need far larger values than that, you
> probably want GMP.

I didn't perform usability tests, I just inferred this from the 
complexities of your algorithm, which are not quite the state of the art.

It's fine if it doesn't scale very well yet, I just wouldn't want the 
library to restrict itself to certain applications too early.

>> It seems however that you library is stuck with the naive O(n^2)
>> implementation. [...]
>
> Only for the present. Which is something I've mentioned several times.

Sorry, I haven't read all messages.

>> On a side note, every algorithm that depends on multiplication should
>> take a functor that specifies which multiplication algorithm to use
>> (with a suitable default).
>> This way, I can provide my multiplication that uses an optimized FFT
>> routine to your algorithms, without requiring your library to contain
>> all possible optimized implementations of multiplication.
>
> That complicates the interface significantly, and would be completely
> unnecessary once the library matures enough to have faster
> multiplication algorithms.

You're forgetting several things here: first, some algorithms might be 
faster than others depending on the situation, and second, you'd have to 
include dependency on FFTW in the core of the library to provide the 
fastest solution.

>>> Certainly, but it doesn't outweigh the cost.
>>
>> What cost? The cost of reorganizing your library entirely?
>> I thought we agreed you'd have to do that anyway.
>
> The cost of freezing the internals at a 1.0 level, or of breaking
> client code when the interface has to change. Which is something else
> I've stated several times, which leads me to believe that you're either
> ignoring any part of the conversation that doesn't focus explicitly on
> your opinions, or that you're ignoring everything else in an attempt to
> intimidate me into redesigning the library to suit you.

I thought you had agreed that separating data and algorithms was a good 
idea in another thread, since many people were pointing it out, is that 
not correct?
I didn't have time to read all messages carefully (sorry again).

> I don't know what culture you grew up in, but mocking someone's words,
> questioning his competence, and finding any excuse to belittle his work
> is incredibly offensive in mine. And that's the content of at least half
> of your messages to me, when you're not simply expressing the
> unbelievably arrogant and self-centered assumption that you know the
> best way to do something that you've never attempted, but that I've put
> a hell of a lot of work into developing, and that anything I've done
> differently is automatically wrong.
>
> On the small chance that you really don't know how insulting your
> messages are, here's some advice: if you want your opinions to be taken
> seriously by anyone with a spine, try a little respect for the
> intelligence of the person on the other side of the conversation, and
> assume that he's competent and does things for a reason until proven
> otherwise, even if that reason isn't perfect. It will make people a lot
> more receptive to your ideas.

I am sorry you feel this way.
But please realize that you failed to provide reasons when I asked for them.

> At the moment, I don't think you'd give it a no-vote, because I don't
> think you'd bother actually reviewing the library unless it's out of
> spite.

For various reasons, some personal I suppose, I would not want Boost to 
contain a subpar bigint library.

Therefore, I am trying to investigate whether this library is 
competitive with the rest of the open source solutions, or if at least 
it has some interesting novelties others do not.

I asked for your assistance in this.

> The only competing library that matters, so far as I can see, is GMP.
> And GMP has licensing issues, which is the main reason why I started
> writing XInt in the first place -- I didn't originally write it for
> Boost, I wrote it for use in one of my own commercial projects.

A quick google search shows quite a few C and C++ libraries that 
implement big integer facilities under a liberal license (though LGPL 
isn't that restrictive in the first place).

Most of them only provide fixed size though.

> That's sufficient reason right there

Wouldn't that be up to the reviewers to decide?

> , but if you want more: there is no
> large-integer library with even a half-decent C++ interface, so far as
> I've seen. I *live* in C++, and I passionately detest working with
> poorly-designed programming interfaces. The old saw is "if you want
> something done right, do it yourself," so I did. It's a sentiment I've
> been sorely tempted to recommend to you as well, on a number of recent
> occasions.

Argument noted. Glad we cleared that up.