[Raymond L. Buvel, on http://calcrpnpy.sourceforge.net/clnumManual.html ] >>> The clnum module handles this calculation very quickly: >>> >>> >>> from clnum import mpf >>> >>> mpf("1e10000") ** mpf("3.01") >>> mpf('9.9999999999999999999999932861e30099',26)
[Tim Peters] >> That's probably good enough for the OP's needs -- thanks! >> >> OTOH, it's not good enough for the decimal module: >> >> (10**10000)**3.01 = >> 10**(10000*3.01) = >> 10**30100 >> >> exactly, and the proposed IBM standard for decimal arithmetic requires >> error < 1 ULP (which implies that if the mathematical ("infinite >> precision") result is exactly representable, then that's the result >> you have to get). It would take some analysis to figure out how much >> of clnum's error is due to using binary floats instead of decimal, and >> how much due to its pow implementation. [Raymond] > Indeed, it is not clear where the error is comming from especially since > you can increase the precision of the intermediate calculation and get > the exact result. > > >>> mpf(mpf("1e10000",30) ** mpf("3.01",30), 20) > mpf('1.0e30100',26) > > Is this the kind of thing you will need to do in the Decimal module to > meet the specification? It will vary by function and the amount of effort people are willing to put into implementations. Temporarily (inside a function's implementation) increasing working precision is probably the easiest way to get results provably suffering less than 1 ULP error in the destination precision. The "provably" part is the hardest part under any approach ;-) -- http://mail.python.org/mailman/listinfo/python-list