Mathematica Precision Issue in Mathematica

AI Thread Summary
The discussion centers on the challenges of increasing precision in computations using Mathematica, particularly when dealing with arbitrary-precision numbers, which inherently slow down processing compared to machine-precision numbers. The original poster is seeking efficient methods to enhance precision without significantly increasing computation time. Key suggestions include measuring different parts of the algorithm to identify bottlenecks and optimizing or parallelizing the slowest sections. The complexity of the equation, which involves multiple summations and derivatives, contributes to the slow performance. One participant shares their experience of successfully parallelizing a computationally intensive project, suggesting that utilizing available resources, such as university computing clusters, could be beneficial. Overall, the conversation highlights the trade-off between precision and computation speed and emphasizes the importance of algorithm optimization.
EngWiPy
Messages
1,361
Reaction score
61
Hello,

I have an equation that when I wrote using Mathematica to get results, the results were wrong in some places. This has nothing to do with the code, which is a 100% correct code. It is a presicion issue. But when I increased the precision, say up to 20, even to 10, the code takes a lot (I mean a huge amount) of running time, and I got no results. The question is: how can I increase the precision to get accurate results in an efficient way in time?

Thanks in advance
 
Physics news on Phys.org
Arbitrary-precision numbers are inherently slower to compute than machine-precision numbers. It is an unavoidable trade-off, so there is only going to be so much that you can do since you need the precision.

However, in general, when trying to speed up an algorithm the most important thing to do is to measure the different parts of your algorithm and actually find out where the bottleneck is. NEVER simply assume that you know which part is the slowest. Test it and find out for sure. Once you have identified the slowest part you can try to code it in an algebraically equivalent but more efficient manner or you can parallelize it etc. depending on the details.
 
DaleSpam said:
Arbitrary-precision numbers are inherently slower to compute than machine-precision numbers. It is an unavoidable trade-off, so there is only going to be so much that you can do since you need the precision.

However, in general, when trying to speed up an algorithm the most important thing to do is to measure the different parts of your algorithm and actually find out where the bottleneck is. NEVER simply assume that you know which part is the slowest. Test it and find out for sure. Once you have identified the slowest part you can try to code it in an algebraically equivalent but more efficient manner or you can parallelize it etc. depending on the details.

I am affraid that, I have nothing to do with the equations. But, I will try.

Furthermore, my equation consists of more than 10 summations, and has many derivatives in each iteration. So, I think it is natural to be slow. But it is affordable for the case of machine-precision numbers.

Regards
 
FYI, my final project for my dissertation involved a calculation that took 27 PC-days of computation. I parallelized the function and ran it over one weekend using all of my lab's computers as a jury-rigged cluster. Many universities now offer this kind of thing on a more "official" basis. If it is really a problem you might look into the resources available.
 
DaleSpam said:
FYI, my final project for my dissertation involved a calculation that took 27 PC-days of computation. I parallelized the function and ran it over one weekend using all of my lab's computers as a jury-rigged cluster. Many universities now offer this kind of thing on a more "official" basis. If it is really a problem you might look into the resources available.

Wow. Parallelism is a smart idea. I don't know, but I think the inter-dependence of the code may make this process difficult. Anyway, it is not that necessary for my thesis, whereas I believe that your project was worthy (27 PC-days).

But I felt that when I increased the precesion, the running time was largely incraesed relative to the corresponding machine-precision numbers.

Best regards
 

Similar threads

Replies
4
Views
2K
Replies
5
Views
3K
Replies
2
Views
2K
Replies
18
Views
4K
Replies
1
Views
2K
Replies
4
Views
2K
Back
Top