Very Large number Calculations with No Loss in Accuracy ?

33 views
Skip to first unread message

Amy Valhausen

unread,
Apr 11, 2016, 3:53:17 PM4/11/16
to sympy
Very Large number Calculations with No Loss in Accuracy ?

Given a 1700 digit number, we want to store the value and perform two functions on it with NO loss of accuracy, its ok if calc time takes longer but better if faster.

Where x = a 1700 digit long numeric value

The two calcs to be computed with be ;

X * (up to a four digit value )

then we take the modulus of this resultant of 400 ;

( x % 400 )

If we cant multiply  [ X * (up to a four digit value ) ] and then take the modulus due to
processing bottlenecks, ceilings - then can this be done where we first take the
modulus of the original x = 1700 digits and then multiply this by the four digit value
and then take the modulus of this after?  Ideally Id prefer to be able to do the
first scenario.

Constraints Im aware of regarding this to date ;

Firstly, Im only running on a WinXp 32 bit system and not able to upgrade currently.

Secondly, Ive been becoming aware of a lot of issues, bugs, errors with python, sympy,
etc.. in properly handling very large number calcs.  These problems seem to arise
out of data loss through use of floats and related.  Details on a number of different
approaches can be viewed here ;

https://groups.google.com/forum/#!topic/sympy/eUfW6C_nHdI
https://groups.google.com/forum/#!topic/sympy/hgoQ74iZLkk

My system will not properly handle "float128" floats, although Ive been told
by one person this would be able to handle wsuch a computation - altho the prob
is it seems that float128 is rarely actually a 128 float and certainly not on my system.
Also due to internal processing peculiarties it seems that most floats will lose
data on these kinds of computations.  If I understand correctly, one of the best
candidates for getting the most accurate values returned involves the use
of arbitrary precision and representing the inputs as strings and not just straight numeroc
values?  Also, ideally, Id like the formula to be able to handle rationals without
accuracy loss.  So  "x" starts off as a whole number, but when I multiply it
by the four digit value, Id like that value to be any numeric value such as an integer,
whole number or rational like "2243.0456".

Structure of one of the methods Ive been experimenting with ;

from sympy import mpmath
mpmath.mp.dps = 1700
x = (mpmath.mpf" INSERT 1700 DIGIT NUMBER HERE"
(x % 400)

An example with live data ;

from sympy import mpmath
mpmath.mp.dps = 1700
x = (mpmath.mpf"4224837741562986738552195234618134569391350587851527986076117152972791626026988760293885754068768475423919991676816860701478996539715076968649431668262941552499272851934021744703799728797962346859481772141964720120813934781420732260156446701740408591264289745960985811289070246238359268267313892549883722768575435935465369820850766441187744058828599331364172396647692768693734233545999439071435129082764340446292057962343360114463696515950803159895238667237356887294549618489296157716384494295159851060500050371940523385701946860964162569067371175357615144192344763876540813882107379891591055307476597279137714860430053785074855035948744902479909111840444834198237419177418965268614345042634655648237818899253116247916585686713243193074635608527160273611309051938762676520507404815180792793701259216609316118483835216791263172902470123821111779223204735647931377027227055312940934756325611832463728974558417085791096461266371917752574370345933533929245534623041989305973992490523694190318284666464757159324866096861573704540654160644711274766759520501013633999706244117691235878123489694261724158073725644897527727473450037615295487637338687848351441331386946416003718795419822246935787682977520303924734875834943985619000970655639767984458204513958680501990182471695393372003272654902387493955849775308922901631024199011283441050881608686856746206012270890984260424834329551281249797545775091226433669036680463406283858413423722935297859778786945935751468048494081427689669730664660260908636113264573712854536295005312934569838992758429422872122606102877623867968067833225444280667381025371705347744037508121975424674439904984528128036994803804742198422695627759844248"
(x % 400)

But I have no idea if accurate results are being returned with this, would love to hear anyones suggestions?

Aaron Meurer

unread,
Apr 11, 2016, 5:50:54 PM4/11/16
to sy...@googlegroups.com
It's worth pointing out that if you use exact integers or rationals
(you can convert a float to a rational with nsimplify()), then there
are no accuracy loss issues, because the result of the calculation
will be a (large) rational number, which can be evaluated to a float
exactly.

Also, if you are starting with an exact non-rational value like
sqrt(2), then you are also better off using that exact value using
SymPy's symbolic features, like

In [16]: from sympy import sqrt

In [17]: sqrt(2)**6000 % 400
Out[17]: 176

This answer is exact because SymPy symbolically computes sqrt(2)**6000
(which is 2**3000), and takes that integer mod 400.

Note that this is different from the answer with 1.4142 because the
extra digits of sqrt(2) come into play when taken to the power 6000
(as pointed out in the other thread, sqrt(2)**6000 is about 900 digits
long, so you need to work with roughly that many digits to get to
accuracy within the range of 400).

Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/6330cf73-4307-4086-b842-2d34cec517b2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages