Boost logo

Boost :

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


On Sat, 05 Mar 2011 15:53:30 +0100
Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:

>>> 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?
>
> 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.

> [...] Even for multiplication, there are a lot of different
> algorithms. The best algorithm to use depends on the situation, a
> fast fourier transform is probably the best when dealing with large
> values for example.
>
> 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.

> 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.

>> 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.

>>>>> 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.
>
> This is a review, not a personal attack.

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'm asking you why you need to do a specific thing, since I see no
> reason to, and you reply with that kind of comment?
> Am I to understand you don't wish to continue a discussion with
> someone that is obviously going to give you a "no" vote? [...]

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.

> Likewise, I would also warmly welcome answers to several questions I
> have asked you that you have ignored. What are the advantages of your
> library over the myriad of existing ones?
> The reason I'm asking you that is because, from my possibly narrow
> view, you do not compare favourably to them. I would gladly be
> corrected on this topic.

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.

That's sufficient reason right there, 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.

-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk