Re: [boost] Interest in an arbitrary precision library?

From: Joel Eidsath (jeidsath_at_[hidden])
Date: 2005-09-03 00:17:33

>
>Do not agree. You should have ease of use _and_ efficiency. Modern C++
>techniques allow for this.
>  
>
I was trying to give myself wiggle room, but I pretty much agree with 
you.  I don't expect anything as fast as GMP, but I imagine that a plain 
C++ library could still do very well.

>It is not clear to me what you mean by "useful for number theory". You want
>the library to handle Z[sqrt(2)](log(2)) arbitrarily good? (this question is
>not rhetoric)
>  
>
You would set the precision of your calculations with a function call.  
(Specify the number of digits of accuracy.)

Example:
set_precision(3);
cout << arbitrary_sqrt(2) << endl;
set_precision(10);
cout  << arbitrary_sqrt(2);

Output: 
1.414
1.4142135624

>>3)  As well as arbitrary precision, it should provide error range math:
>>2.00 * 2.00 is not generally the same thing as 2.0 * 2.0
>>    
>>
>
>Do not fully understand, please expand this idea.
>
>  
>
For example:
1.0 + 1.00 = 2.0 (plus or minus .05)
1.00 + 1.00 = 2.00 (plus or minus .005)

>I do not fully like the idea of exceptions on the middle of my computations,
>I prefer to set the 'state' of the object to Nan. Even for big ints.
>
>  
>
That would work too.  Whatever the solution is though, I don't want it 
to attempt a normal int division by zero internally if asked to do a big 
int division by zero.  There is no way to handle that sort of error at 
run time.

>>9)  Precision for rational numbers may be set as a static member
>>variable or it may not.  In the second case, expressions involving
>>rational numbers of different.
>>    
>>
>
>I see no point in using rational numbers, but maybe I am missing something.
>
>  
>
By rational, I a type that is "more than just integers."  (Mathematics 
is my field, not CS.)  Built-in types like float and double hold 
rational numbers.  So I am not talking about a struct that holds a 
numerator and a denominator, if that's what you were thinking.

Joel Eidsath