Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-04 12:55:16

On Fri, 04 Mar 2011 16:19:45 +0100
Joel Falcou <joel.falcou_at_[hidden]> wrote:

> Oook ... well, first i want to stress out i am not here to get
> personal at you Chad. This is a review process not a crusade.

Yes, and I'm trying to keep that in mind. I apologize for any
frustration that leaks out.

>> Why would you? Give me a viable use-case, and if it fits the
>> library's design criteria, I'll be happy to try to make it happen.
>
> Well, let's say i just have some file format storing large integer
> this way or receiving large integer over a network by unconnected
> packet. It's a variation of reading the int value from a string like 
> "45748764465768754564634687314313270".

And what interface do you envision to allow this?

>> No, you cannot. Deliberately. If you were able to, then the interface
>> would be permanently stuck at a version-1 state, because if I made
>> any future changes to it, it would break existing client code. In my
>> opinion, the freedom to improve the internal design without breaking
>> client code is far more desirable than giving client code free rein
>> to mess around in its internals.
>
> No. you shield yourself from this by having a proper iterator/range 
> types that hides said details of your internals. [...]

Then I misinterpreted your argument, for which I apologize. Yes, I can
provide a (read-only) iterator interface to the digit_t values of an
integer. I don't think that will limit future development much. I've
put it on the to-do list.

If you want more than read-only, then even if the library provides it,
it will have to be marked as officially unsupported and subject to
incompatible changes without warning in future versions.

>> [...] Point B, it can handle essentially any mathematical operation
>> that can be expressed as a combination of existing operations. No
>> one has yet provided any concrete example of a mathematical
>> operation that *can't* be done using the operators and functions
>> already available, and I suspect you'd have to get pretty esoteric
>> to find one.
>
> OK, so let me rephrase. What if i want to implement a function that
> has a non trivial algorithm which is faster than the usual combo of
> operations ?

If such a function isn't use-specific, I assume it would be more at
home within the library than as an add-on, and I'd suggest providing a
patch if you're willing and able to offer it to the public. If not,
then you're right, the only way to do it well would be with read/write
access to the internals.

>> Then you're don't understand it.
>
> Maybe, but I'll wager I do. Other concern is sharing data like this 
> between threads may lead to memory contention and/or false sharing if 
> data fit incomplete cache lines.

It isn't meant to be shared between threads. The internal code is
single-threaded, and if you enable this on the public interface, you
explicitly *dis*able the library's thread safety.

>> GMP is a collaboration of dozens of developers, contains years of
>> work, and includes low-level optimizations that go against XInt's
>> design goals. XInt is the product of one developer over five months.
>> Do you measure a child's running speed against that of an Olympic
>> gold medalist?
>
> No I am not, you are by actually putting the dreaded "it is fast"
> line in the documentation.

And most people who have commented on it are misinterpreting it as a
claim that "it is faster than..." or "it is the fastest." It says
neither. That line explains an important design criteria of the library.

> Development is not a fire and forget process, even more so if you go 
> over some task like this one where people has tons of diverging use 
> cases and expectations. I am not slapping you with a large trout for 
> fun, i am just trying to show you that, if made more generic, you can 
> still have your current impl and let said people with unusual needs
> be able to tweak the library from the outside to fulfill them.

It's not an excuse, but I'm very short of sleep and more than a little
frustrated. Please forgive the tone of my previous reply.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*