Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #107587 > unrolled thread
| Started by | Peter Otten <__peter__@web.de> |
|---|---|
| First post | 2016-04-25 10:16 +0200 |
| Last post | 2016-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.
Re: Optimizing Memory Allocation in a Simple, but Long Function Peter Otten <__peter__@web.de> - 2016-04-25 10:16 +0200
| From | Peter Otten <__peter__@web.de> |
|---|---|
| Date | 2016-04-25 10:16 +0200 |
| Subject | Re: 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.
Back to top | Article view | comp.lang.python
csiph-web