A double-precision floiting point number is stored in a total of 64 bits (1 sign bit, 11-bit exponent, 52-bit mantissa). This corresponds to about 15 decimal digits of precision. Any calculation resulting in a higher precision is subject to rounding errors. An upper bound of the relative error due to rounding can be obtain in python like this:
import sys
sys.float_info.epsilon
2.220446049250313e-16
0.3**2 == 0.09
True
0.2**2 == 0.04
False
import numpy as np
np.isclose((0.2)**2, 0.04)
True
print(sys.float_info.min, sys.float_info.max)
2.2250738585072014e-308 1.7976931348623157e+308
In numpy, results that are larger than the maximum range a set to inf
or -inf
, respectively.
a = np.exp(1000)
print(a)
inf
<ipython-input-29-7891d9d166db>:1: RuntimeWarning: overflow encountered in exp a = np.exp(1000)
Undefined operations result in the floating point value nan
print(np.sqrt(-1), np.log(-1), np.arcsin(1.1))
nan nan nan
<ipython-input-9-e46aa987836e>:1: RuntimeWarning: invalid value encountered in sqrt print(np.sqrt(-1), np.log(-1), np.arcsin(1.1)) <ipython-input-9-e46aa987836e>:1: RuntimeWarning: invalid value encountered in log print(np.sqrt(-1), np.log(-1), np.arcsin(1.1)) <ipython-input-9-e46aa987836e>:1: RuntimeWarning: invalid value encountered in arcsin print(np.sqrt(-1), np.log(-1), np.arcsin(1.1))
A key issue in large software project is to manage complexity. The total cost have of having a mess can be large in terms of wasted time and money. From Robert C. Martin books Clean code: "As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero".
A few simple rule might help. The text below was adapted from
"Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. — Robert C. Martin
Not so clear:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
Better:
if (employee.isEligibleForFullBenefits())
int elapsedTimeInDay
is better than int days
"Unit tests are typically automated tests written and run by software developers to ensure that a section of an application (known as the "unit") meets its design and behaves as intended." (from the wikipedia article on unit testing)
(Try import this
)
import this
The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!