Arbitrary precision calculations

AI Thread Summary
The discussion centers on the challenges of implementing division in an arbitrary precision calculator, particularly when handling large numbers. While multiplication of thousand-digit numbers is efficient, achieving division with high precision (around 250 decimal places) is significantly slower, taking about 20 seconds. Participants suggest that optimizing algorithms for arbitrary precision can be complex, involving techniques like Fourier transforms and finite field math. A common approach discussed is calculating the inverse (1/x) and then multiplying, although this method has been noted to slow down exponentially with each decimal place. An alternative method proposed involves an iterative algorithm that starts with a rough estimate of the inverse and refines it to achieve higher precision quickly. This method doubles the precision with each iteration, allowing for efficient convergence to the desired result. Additionally, resources such as the Apfloat package and a VB-based package called XNUMBERS are recommended for further exploration and implementation guidance.
QuantumHop
Messages
68
Reaction score
0
I decided to write an arbitrary precision calculator but I'm having problems with division.

It will multiply a thousand digit number by another thousand digit number in about a second but to get a division result to about 250 decimal places is taking around 20 seconds, I cannot figure out how it should be done.

Anybody have any ideas?
 
Technology news on Phys.org
The optimizing algorithms for arbitrary precision can get complex, involving a combination of Fourier transforms and modulo (finite field) math. Apfloat (do a web search) is a package that you can get for free and includes source and some documentation on the algorithms. I'm not sure if division is done directly or if it's better to calculate the inverse (1/x) then multiply.
 
Last edited:
rcgldr said:
I'm not sure if division is done directly or if it's better to calculate the inverse (1/x) then multiply.
This is exactly the method I have used, it works but its very slow and the time taken to calculate the next decimal place increases exponentially. I was hoping there was some clever trick that would solve the problem, I've searched for solutions but haven't found one I can use in VB2010. ( yeah I know , learn a real language :biggrin: )
 
rcgldr said:
I'm not sure if division is done directly or if it's better to calculate the inverse (1/x) then multiply.

QuantumHop said:
I was hoping there was some clever trick that would solve the problem.
If you have a relatively fast multiply you can try this algorithm that converges to the result quadratically:

z ~= 1/x (use actual division for initial 16 bit estimate of 1/x).

then iterate this process using extended multiply algorithm.

z = z (2 - x z)

If you start off with a 16 bit estimated quotient, then the precision doubles to 32 bits after 1st step, 64 bits after second step, ... So if you need 64 bits, you would iterate twice, then do a test multiply t = x z, and adjust z +/- 1 bit for the final correction.
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
I tried a web search "the loss of programming ", and found an article saying that all aspects of writing, developing, and testing software programs will one day all be handled through artificial intelligence. One must wonder then, who is responsible. WHO is responsible for any problems, bugs, deficiencies, or whatever malfunctions which the programs make their users endure? Things may work wrong however the "wrong" happens. AI needs to fix the problems for the users. Any way to...
Back
Top