Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: DE (satan66613_at_[hidden])
Date: 2010-03-27 05:57:52

on 27.03.2010 at 0:47
 Chad Nelson wrote :
>> first, to make 'xint::integer' consistent (if i were you) i'd make all
>> public member functions non-member friend functions because 'int' and
>> other fundamentals have no member functions
> Most of the non-operator member functions are there because n1692
> required them.
i wasn't aware of it
but my first statement still holds
on the other hand looking at .net ints and double having 'toString()'
and other member it's becoming a common practice
you may wonder what other people think about it

>> what about compile time fixed precision ints? like 'xint::fixed<128>'
>> with '128' denoting number of bits (or bytes?)
> I don't see any obvious reason why that couldn't be implemented on top
> of xint::integer. It should only require a fairly simple set of template
> wrappers. I think it should be deferred until the underlying library
> makes it through the review process though.
in my view a templated version must be somewhat different
as i figured out you use memory allocation for arbitrary precision
objects and one won't want to pay this overhead for simple (portable)
int128 for example
an 'xint::fixed<N>' (let's call it this way for now) must be a
pod-like type which reuse all of the algorithms for 'xint::integer'

> Also, I'm noting who made suggestions for the library, for an
> acknowledgments page. Do you prefer to be known only as "Pavel", or do
> you have a publicly-known last name?
well, let it be just Pavel

on 27.03.2010 at 7:02
 Chad Nelson wrote :
> I'm aiming for the more casual user of large integers. Somebody who
> needs a large-integer package to do specific calculations in his
> closed-source software, for example, and needs a Boost-licensed
> implementation a lot more than the highest performance. Or the person
> who needs an open-source large-integer package that's 100% portable, so
> he can compile it on some weird system cobbled together from old
> supercomputer parts. Or the guy who just needs a large-integer package
> to solve a particular mathematical programming puzzle and doesn't want
> the headaches of installing GMP, compiling it, and figuring it out.

> Don't think that those people don't exist -- the whole reason I started
> writing it was because I was in the first camp myself. :-) I suspect
> that people like that make up the vast majority of those who need a
> large integer library.
you read other's minds, don't you?
i believe once you have state-of-the-art public interface for your lib
you can easily switch to virtually any implementation
so i don't see a problem here at all

-- 
Pavel