After fortran and excel, my most used piece of software/language/tool was Matlab. It has been a constant companion in office for me for quick prototyping. Seriously started using it when I was in NAL and ever since have used it off and on in office.
Then came python and slowly python has become my numerical/computation engine of choice, apart from the various benefits of using python, I love the fact that unlike matlab, for comparison, there isn’t any limit in python. All kind of tasks and computations can be done with minimum effort. Be it numerical computation or website management.
And thanks to the Python packages NumPy, SciPy , Sympy and Matplotlib, most MATLAB code can be almost cleanly and easily translated to Python code. There are however some clear differences that must be accounted for.
Zero index – Python uses a zero-indexing standard, while MATLAB uses a one-indexing standard, making most algorithms give a one-off error if directly converted. This is quickly fixed, but requires some application of thought for algorithms where the index is part of the mathematical calculations. If you are converting Matlab to python, this is the most slippery zone.
Differencing between arrays and functions – or difference between () and  – Python does not allow accessing arrays by the a(1) standard and instead uses a. This can cause some confusion as to why a function will not run but can be quickly eliminated, as it casts an error. Functions are still called with soft parentheses. If your are converting Matlab to Python, this is the most frequent mistake you will do.
Slicing arrays – A Python slice of an array is issued with the : operator like MATLAB, but unlike MATLAB, beginning and end are assumed unless stated otherwise. Unlike MATLAB, slice operations in python do not copy the array, but simply provides a view into it. This can cause problems with iterative algorithm that assumes the array is constant – Python uses the copy function to copy arrays, where MATLAB copies them as default. This is a mistake that’s hard to debug during compilation, so be extra careful.
And the biggest pitfall of all is the integer division.
Maybe since Python was not exclusively designed as a numeric language, it does not automatically cast integer division as a floating point number, should the division not have an integer solution. Python automatically casts integer division to another integer, rounding the result down. This can prove problematic if any of the mathematical expressions include a fraction like 3/2
It can be easily corrected with two easy solutions.
1. Adding a punctuation mark after the integer, to indicate it should be treated as a floating point value. In the above example we would then write 3./2. instead of 3/2
2. Importing the built-in function to convert integer division to floating point numbers automatically. This will require the very first line of code in the relevant file to be “from __future__ import division”
Do you know of any other pitfalls?