On Dec 28, 3:55 pm, jerry.carl...@gmail.com wrote: > But i am after the extra precision: > > >>> from math import * > >>> (1+1e-16)-1 > > 0.0
Sounds like you don't care too much about the base-10 part, so there may be other solutions out there. Have you tried: 1. mpmath? 2. sympy? 3. Sage? Any of these is likely to be faster than a decimal solution. One thing that it would be *really* nice to have is a set of Python bindings to MPFR---to me, MPFR is the one obvious way to do high-precision math. Maybe bindings already exist somewhere. Sage includes them, but also includes many hundreds of megabytes of other stuff that you probably don't need or want. Maybe you could get access to MPFR via ctypes; I don't have any idea how feasible or complicated this might be. > Sure, you can say, there is such a small market for this application, > and maybe I should use other tools. Well, I found Python so much > easier to use for other reasons. And, again, it seems like there is a > desire for it outside of my own office. Well, I'd certainly find high-precision sin, cos, ... within Python useful. I'd guess the market isn't *so* small. > Agree: sin, cos and atan would do it. I'll see if I can find time. I've just discovered a half-finished version of atan for Decimal sitting on my computer, complete with error analysis. > Wow, i would never think my posting would go that high in the Python > world. I can't wait to tell my colleagues after these holidays ;-) LOL---hardly! I'm just one of hundreds of Python core devs, and I've only been that for around a year... > If I improve (in my view that is) the existing modules (dmath) etc. i > will keep you posted. For now I am reducing large arguments of > goniometric functions by adding the following into the dmath's sin(x) > and cos(x): > > x=Decimal.__mod__(x,Decimal('2')*pi()) > > Works fine for what i need, but i am sure it's not the right way to do > it. I don't know of any better way to deal with large arguments. The main problem is that the reduction step can introduce fairly large errors: for example, if you're using a value of pi that's accurate to 10**-20, say, then reducing something of magnitude 10**5*pi will give a result with error of around 10**-15. As far as I know, this problem is essentially unavoidable, and it's the reason why implementing sin for inputs like 10**999999999 isn't feasible. Mark -- http://mail.python.org/mailman/listinfo/python-list