Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #107587 > unrolled thread

Re: Optimizing Memory Allocation in a Simple, but Long Function

Started byPeter Otten <__peter__@web.de>
First post2016-04-25 10:16 +0200
Last post2016-04-25 10:16 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Optimizing Memory Allocation in a Simple, but Long Function Peter Otten <__peter__@web.de> - 2016-04-25 10:16 +0200

#107587 — Re: Optimizing Memory Allocation in a Simple, but Long Function

FromPeter Otten <__peter__@web.de>
Date2016-04-25 10:16 +0200
SubjectRe: Optimizing Memory Allocation in a Simple, but Long Function
Message-ID<mailman.66.1461572195.32212.python-list@python.org>
Derek Klinge wrote:

> I found that the pattern of an additional digit of accuracy corresponding
> to 10*n did not hold as strongly for that value (I can post data if
> desired). I also got some results that seem to contradict the mathematical
> definition. For example try EulersNumber(10**15).LimitMethod(), the
> definition places this limit at e, and yet the (python) answer is >3.035.
> Please let me know if I've fouled up the implementation somehow.

There's nothing wrong with the formula, but floating point numbers have 
limited precision. At some point your calculation will become mostly a 
rounding error.

You'll see the surprising

>>> n = 10**14
>>> (1+1/n)**n
2.716110034087023
>>> n = 10**15
>>> (1+1/n)**n
3.035035206549262

on most modern computers with most programming langagues.
 
https://docs.python.org/3.5/tutorial/floatingpoint.html

has some introductory information.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web