On Sun, 6 Mar 2011 06:01:24 -0500 Gordon Woodhull <gordon@woodhull.com> wrote:
On Mar 6, 2011, at 5:22 AM, Ivan Sorokin wrote:
After your reply I changes my mind. As I see you had considered all my suggestions long before I posted them. If they really lead to unavoidable performance penalty I think current implementation is a good trade-off.
I vote for inclusion XInt into boost.
Seems like Chad's reply was off-list?
Not deliberately. I hit reply as usual, and didn't notice that it wasn't sent to the list like it usually is. Makes me wonder how many other replies of mine have gotten misaddressed. :-(
Could the rest of us see what convinced Ivan?
On Sun, 06 Mar 2011 02:10:50 +0300 Ivan Sorokin <sorokin@rain.ifmo.ru> wrote:
I believe that arbitrary precision arithmetic library is very useful. But I don't think that in it's current status XInt is appropriate for boost.
Regardless, thank you for your comments.
Below is the list of features which I believe should be improved. The list is sorted by importance.
1. Parametrize with container type. [...]
I actually tested earlier iterations with containers such as vector for their storage. The performance numbers were noticeably worse.
Another option could be wrapping containers into some entity with interface suitable for integer_t needs.
I haven't tried that, but it did occur to me as a way to allow the range interface that has been requested. Although again, I'd prefer not to do something like that until the internals have stabilized some.
One more thought about "secure" option. There are no standard containers with this option. I think either both standard containers and integer_t should have such option or both shouldn't have. This is yet another argument for container parametrization.
I'm not sure I understand your argument. Are you saying that because there are no standard containers with a zero-memory-before-releasing option, that the library shouldn't provide one either?
2. Signed Zero.
I'm sure that long integer arithmetic should behave as close to native integer numbers as possible. Native integer types don't have negative zero. As the documentation mentions, this is done "for use in a planned future unlimited-precision floating point library". Although the only function that behaves differently on negative and positive zero is sign(true), I still believe that this is redundant and planned floating point library should use it's own sign bit.
This was argued over passionately last year. I was on the don't-include-it side, but some very compelling reasons convinced me to do so, reluctantly. The clincher was that any implementation of the aforementioned floating-point library would be seriously hampered without it.
3. Alternative representation of negative numbers
Currently integer_t supports bit arithmetic, but its result differ from one of native integer types: [...]
For negative numbers, yes, because sign/magnitude is far more efficient than two's complement for most operations in this kind of library. (Addition and subtraction are the exceptions.)
I propose the following solution. Currently integer_t stores the sign bit and value bits (absolute value). Instead of the sign bit let integer_t hold a bit "inverse_value" with the following meaning: [...]
As an option, there might be some call for that. Using that as the default would adversely affect the performance, because many of the algorithms -- even basic ones like multiplication and division -- are geared toward sign/magnitude, necessitating conversion to it before every such operation and back after.
The implementation of addition and subtraction for this representation is not more complicatedthan for current one. But it allows bit arithmetic to work in the same fashion as it works with native integer types.
Do you foresee a lot of need for such negative value bit-manipulation in a large-integer library?
4. About options naming.
The option name "threadsafe" is misleading as it implies something about concurrency. Instead it means just disabling copy-on-write. [...]
Copy-on-write is the only thing that *isn't* completely thread-safe about the library. Thread-safety is the important feature; copy-on-write is an optimization that affects it.
xint::nothrow_integer really is "xint::integer or nan". Maybe the name that reflects "integer or nan" representation is better?
Sorry, but I don't understand. xint::nothrow doesn't throw exceptions; that is its reason for existing. The ability to hold a Not-a-Number value is a secondary aspect, to give it a value that is never valid, as a way to report errors. -- Chad Nelson Oak Circle Software, Inc. * * * -- Chad Nelson Oak Circle Software, Inc.
Certainly, here's the entire reply: * * *