[Tutor] decimal precision in python

[Kapil Shukla]

i tried writing a small code to calculate option price using the binomial tree model. I compared my results with results of the same program in excel. There seems to be a minor difference due to decimal precision as excel is using 15 decimal precision and python (both 2.7 and 3.1) using 11. (at least that's what shown on shell)

can some one guide me whats the equivalent of using a double datatype on python and i can't use long() in 3.1 any more.

Please also suggest a free editor for python which can at least repeat previous command with a key stroke

regards

kapil

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Steve Willoughby]

On 06-Feb-12 07:25, Kapil Shukla wrote:
> i tried writing a small code to calculate option price using the
> binomial tree model. I compared my results with results of the same
> program in excel. There seems to be a minor difference due to decimal
> precision as excel is using 15 decimal precision and python (both 2.7
> and 3.1) using 11. (at least that's what shown on shell)

If you need lots of precision, you might consider using the decimal
class.  It'll cost you speed vs. the native floating-point type but
won't cause you round-off errors.

natively, Python uses IEEE double-precision math for all float objects.

For a float value x, instead of just printing it, try this:

print('{0:.30f}'.format(x))

> can some one guide me whats the equivalent of using a double datatype on
> python and i can't use long() in 3.1 any more.

Equivalent to what degree?  Python's float class generally will get you
where you need to go.  Also the int type automatically extends to
arbitrary-precision integer values so you don't need explicit "long"
type anymore.  (Unless I misunderstood your question there.)

> Please also suggest a free editor for python which can at least repeat
> previous command with a key stroke

I use vim, which has that feature.  I suspect any editor worth its salt
does, or could be programmed to.


--
Steve Willoughby / [hidden email]
"A ship in harbor is safe, but that is not what ships are built for."
PGP Fingerprint 4615 3CCE 0F29 AE6C 8FF4 CA01 73FE 997A 765D 696C
_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[James-2]

On Mon, Feb 6, 2012 at 10:25 AM, Kapil Shukla <[hidden email]> wrote:

i tried writing a small code to calculate option price using the binomial tree model. I compared my results with results of the same program in excel. There seems to be a minor difference due to decimal precision as excel is using 15 decimal precision and python (both 2.7 and 3.1) using 11. (at least that's what shown on shell)

can some one guide me whats the equivalent of using a double datatype on python and i can't use long() in 3.1 any more.

Please also suggest a free editor for python which can at least repeat previous command with a key stroke

regards

kapil

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Have you looked into the decimal module? (you need to import decimal)

http://docs.python.org/library/decimal.html

You can specify the amount of precision needed.

Also, i would suggest using 3.2, if it's not too late in your project.

As for editors, I hear VIM is good. I use Eclipse as an IDE personally. People seem to have some fairly definite ideas on what editor other people should use, bordering on religious fanaticism. 

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Dave Angel-3]

On 02/06/2012 10:25 AM, Kapil Shukla wrote:

> i tried writing a small code to calculate option price using the binomial
> tree model. I compared my results with results of the same program in
> excel. There seems to be a minor difference due to decimal precision as
> excel is using 15 decimal precision and python (both 2.7 and 3.1) using 11.
> (at least that's what shown on shell)
>
> can some one guide me whats the equivalent of using a double datatype on
> python and i can't use long() in 3.1 any more.
>
> Please also suggest a free editor for python which can at least repeat
> previous command with a key stroke
>
> regards
> kapil
>
>

A Python float is equivalent to a C double;  it's already about 18
digits, using the IEEE binary hardware available on most modern
systems.  However, it's a binary value, so it'll round in different
places than the decimal values that Excel probably uses.

You might want to read this:
http://docs.python.org/tutorial/floatingpoint.html

 From the subject you choose, you are apparently asking for a decimal
package.  You can use the python decimal package if you actually need
the round-off to be according to decimal's quirks.  Certainly that's
easier (and slower) to deal with.  Or you can use decimal because you
need more than about 18 digits.  It defaults to 28, but you can set it
higher or lower.   import decimal.

     http://docs.python.org/library/decimal.html 
<http://docs.python.org/library/decimal.html>


For a free editor that's python friendly, I'd suggest Komodo Edit,
http://www.activestate.com/komodo-edit

I use the non-free Komodo-ide, which is based on the free editor.




--

DaveA

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[modulok-2]

For money, you should probably use the builtin module 'decimal' instead:

http://docs.python.org/library/decimal.html

There's also the third party module 'mpmath' which provides arbitrary precision
floating point arithmetic.

http://mpmath.googlecode.com/svn/trunk/doc/build/index.html

-Modulok-

On 2/6/12, Kapil Shukla <[hidden email]> wrote:

> i tried writing a small code to calculate option price using the binomial
> tree model. I compared my results with results of the same program in
> excel. There seems to be a minor difference due to decimal precision as
> excel is using 15 decimal precision and python (both 2.7 and 3.1) using 11.
> (at least that's what shown on shell)
>
> can some one guide me whats the equivalent of using a double datatype on
> python and i can't use long() in 3.1 any more.
>
> Please also suggest a free editor for python which can at least repeat
> previous command with a key stroke
>
> regards
> kapil
>

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Steven D'Aprano-8]

Steve Willoughby wrote:

> On 06-Feb-12 07:25, Kapil Shukla wrote:
>> i tried writing a small code to calculate option price using the
>> binomial tree model. I compared my results with results of the same
>> program in excel. There seems to be a minor difference due to decimal
>> precision as excel is using 15 decimal precision and python (both 2.7
>> and 3.1) using 11. (at least that's what shown on shell)
>
> If you need lots of precision, you might consider using the decimal
> class.  It'll cost you speed vs. the native floating-point type but
> won't cause you round-off errors.

I'm afraid that's not correct. Decimal is still subject to rounding errors.

 >>> from decimal import Decimal
 >>> x = 1/Decimal(3)  # one third, as close as a Decimal can give
 >>> x + x + x == 1
False


The difference is that the rounding errors you get with Decimal are usually
different to the ones you get with binary floats. For example:

 >>> y = 0.1  # one tenth, as close as a binary float can give
 >>> y+y + y+y + y+y + y+y + y+y == 1
False

while the same calculation is exact with Decimal.

The reason for the error is the same in both cases: in the first, 1/3 takes an
infinite number of decimal digits, while in the second, 1/10 takes an infinite
number of binary digits. So Decimal 1/3 is not *precisely* 1/3, and float 1/10
is not precisely 1/10 either.

Binary floats can store exactly any fraction which can be written as a sum of
powers of 1/2, e.g.:

0.40625 = 13/32 = 1/4 + 1/8 + 1/32 so can be stored exactly in a float

Every other number is rounded. The same applies to Decimal: it can store
exactly any fraction which can be written as a sum of powers of 1/10.

The advantage of Decimal is that anything which can be stored as an exact
float can also be stored as an exact Decimal, plus some numbers which can't be
written as exact floats. But there are still plenty of numbers which can't be
stored exactly as either.



--
Steven

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Steven D'Aprano-8]

Col,

I think you wrote to me personally by accident, instead of to the Tutor list.
Nothing you said seems to be private, so I've taken the liberty of answering
back on the list.

col speed wrote:

> Just an idea - I'm not an expert by any means, just a dabbler, but:
> many years ago, when I was looking at options(I assume you mean the
> same as me as in puts etc.)
> they were quoted as fractions.
> Some fractions can't be quoted as exact decimals and some decimals as
> binary, so fractions *may* be more exact.
> I believe there is a fractions module, but it is quite easy to create
> your own Rational class.

Starting in Python 2.6, there is a fractions module in the standard library.
Unlike float and Decimal, it is effectively infinite precision:

 >>> from fractions import Fraction
 >>> z = 1/Fraction(3)
 >>> z + z + z == 1
True


This comes at a cost, of course. Unless you are very careful, you can end up
with fractions like this:

Fraction(2573485501354569, 18014398509481984)

That is very close to 1/7, and in fact it is the exact fraction equal to the
binary float closest to 1/7:

 >>> Fraction.from_float(1/7.0)
Fraction(2573485501354569, 18014398509481984)


So Fraction is not a panacea either. Unless you take care, you can easily end
up using an unlimited amount of memory for an extremely precise number, when a
much lower precision would be close enough -- or possibly even BETTER:

 >>> Fraction.from_float(1/7.0).limit_denominator(10)
Fraction(1, 7)


But yes, Fractions are a sadly under-appreciated tool for numeric calculations.


--
Steven

_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Steve Willoughby]

On 07-Feb-12 03:15, Steven D'Aprano wrote:

> Steve Willoughby wrote:
>> If you need lots of precision, you might consider using the decimal
>> class. It'll cost you speed vs. the native floating-point type but
>> won't cause you round-off errors.
>
> I'm afraid that's not correct. Decimal is still subject to rounding errors.
>
>  >>> from decimal import Decimal
>  >>> x = 1/Decimal(3) # one third, as close as a Decimal can give
>  >>> x + x + x == 1
> False

Sorry, I guess I took it for granted that was understood.  I was
referring to round-off caused by binary representation of a number that
by all appearances is a simple, rational, non-repeating decimal number
expressed in base 10.

In other words, when you're adding up financial figures, you'll get an
accurate sum without "mysterious" rounding off, but of course certain
fractions which don't have a straightforward way to represent as a
decimal value, like 1/3, are going to be an issue.  Good catch, though,
it was better to point that out.


--
Steve Willoughby / [hidden email]
"A ship in harbor is safe, but that is not what ships are built for."
PGP Fingerprint 4615 3CCE 0F29 AE6C 8FF4 CA01 73FE 997A 765D 696C
_______________________________________________
Tutor maillist  -  [hidden email]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor