#!/usr/bin/env python
# coding: utf-8

# # Practical tips

# ## Numerics

# A [double-precision floiting point number](https://en.wikipedia.org/wiki/Double-precision_floating-point_format) 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:

# In[23]:


import sys
sys.float_info.epsilon


# ### Comparing floating point numbers

# In[6]:


0.3**2 == 0.09


# In[5]:


0.2**2 == 0.04


# In[8]:


import numpy as np
np.isclose((0.2)**2, 0.04)


# ### Range of floating point numbers

# In[8]:


print(sys.float_info.min, sys.float_info.max)


# In numpy, results that are larger than the maximum range a set to `inf` or `-inf`, respectively.

# In[29]:


a = np.exp(1000)
print(a)


# Undefined operations result in the floating point value [`nan`](https://en.wikipedia.org/wiki/NaN)

# In[9]:


print(np.sqrt(-1), np.log(-1), np.arcsin(1.1))


# ## Clean code

# See [https://xkcd.com/844/](https://xkcd.com/844/)
# 
# ![good_code.png](attachment:b51d942c-f39b-416f-aa39-c53ca8f64bb2.png)

# 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](https://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=clean+code&qid=1612906152&sr=8-1): "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
# * [Jamie Bullock, Clean Code: 5 Essential Takeaways](https://medium.com/better-programming/clean-code-5-essential-takeaways-2a0b17ccd05c)
# * [Esteban Solorzano, Clean Code in Python](https://medium.com/dev-genius/clean-code-in-python-8251eea292fa)

# ### Keep it short
# * Function bodies should be short — hardly ever longer than 20 lines and mostly less than 10 lines
# * Functions should take as few arguments as possible

# ### Make Code Self-Documenting
# 

# "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())

# ### Use meaningful and intention-revealing names
# * Example: `int elapsedTimeInDay` is better than `int days`
# * Function names should say what they do

# ### Unit tests
# "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](https://en.wikipedia.org/wiki/Unit_testing))

# ### From the Zen of Python
# * Beautiful is better than ugly.
# * Simple is better than complex.
# * Readability counts.
# 
# (Try `import this`)

# In[1]:


import this


# In[ ]: