Adam Skutt <ask...@gmail.com> wrote: > On Jul 8, 7:23 am, Mark Dickinson <dicki...@gmail.com> wrote: > > On Jul 8, 11:58 am, Adam Skutt <ask...@gmail.com> wrote: > > > > > accurately. Moreover, in general, it's impossible to even round > > > operations involving transcendental functions to an arbitrary fixed- > > > precision, you may need effectively infinite precision in order to the > > > computation. > > > > Impossible? Can you explain what you mean by this? Doesn't the > > decimal module do exactly that, giving correctly-rounded exp() and > > log() results to arbitrary precision? > > You run into the table-maker's dilemma: there's no way to know in > advance how many digits you need in order to have n bits of precision > in the result. For some computations, the number of bits required to > get the desired precision can quickly overwhelm the finite limitations > of your machine (e.g., you run out of RAM first or the time to compute > the answer is simply unacceptable).
Yes, this appears to be unsolved yet, see also: http://www.cs.berkeley.edu/~wkahan/LOG10HAF.TXT "Is it time to quit yet? That's the Table-Maker's Dilemma. No general way exists to predict how many extra digits will have to be carried to compute a transcendental expression and round it _correctly_ to some preassigned number of digits. Even the fact (if true) that a finite number of extra digits will ultimately suffice may be a deep theorem." However, in practice, mpfr rounds correctly and seems to be doing fine. In addition to this, I've been running at least 6 months of continuous tests comparing cdecimal and decimal, and neither log() nor exp() poses a problem. pow() is trickier. Exact results have to be weeded out before attempting the correction loop for correct rounding, and this is complicated. For example, in decimal this expression takes a long time (in cdecimal the power function is not correctly rounded): Decimal('100.0') ** Decimal('-557.71e-742888888') Stefan Krah -- http://mail.python.org/mailman/listinfo/python-list