On Fri, 04 Mar 2011 16:19:45 +0100 Joel Falcou <joel.falcou@lri.fr> 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. * * *