Re: Python’s Sympy Module and the Cayley-Hamilton Theorem

[pbuk]

Hi @Mark44, I have a few comments on your recently posted Insight https://www.physicsforums.com/insights/pythons-sympy-module-and-the-cayley-hamilton-theorem/. The first two are related to the Insights platform and are directed at Greg.

1. The code is very hard to read without syntax highlighting. @Greg Bernhardt can't we get a Prism or Highlight.js plugin?
2. I think there is some horrible JavaScript running on Insights pages intercepting the copy command to insert a reference back to PF. Unfortunately this is broken (tested in FF and Chrome[ium] on Windows and Linux Mint) as it strips line endings, leaving all code on one line! I can understand the reason for wanting this but as it is implemented now it is a pain (and can easily be avoided by using the 'show source code' option in the browser and copying from there).
3. It is common practice elsewhere to post code in articles as a GitHub gist: this would help work around the above problem.
4. The screenshot of Idle is a great blast from the past! Seriously does anyone use Idle any more? Most Python programmers I know use VS Code, and I think many PF readers have been introduced to Python via Jupyter notebooks. Perhaps either of these coding environments would be more relevant to readers? Or just post output as text rather than a screenshot?
5. There is a standard for writing docblocks which should be followed so that IDEs can parse them properly, although there are a number of variations to this standard. One way of writing the docblock for getCoeffs that would work much better could be:
   
   def getCoeffs(poly, coefficients):
       """
       Get the coefficients of a polynomial.
   
       Parameters
       ----------
       poly: list - a list of tuples that contain the coefficients
           and exponents of the polynomial in question.
           In the i-th tuple, the subtuple at index 1
           holds the coefficient.
       coefficients: list - the list of coefficients that will be returned.
           The caller must define the list.
   
       Returns
       -------
       coefficients: list - A list of the cofficients.
       """
6. list is not a reserved word in Python, but it is the name of a type so using it as the name of a variable is not a good idea. You might be tempted to call it my_list but again that is not very helpful: the best name for it would be coefficients as I have used above, however...
7. Passing parameters by reference in Python is not the same as passing pointers in C. To illustrate this see the following code:
   
   def passbyref(my_list):
       # This will change the first element of my_list.
       my_list[0] = 2
   
       # This creates a new variable my_list in the scope of this function: the
       # reference to the original parameter is no longer available here.
       my_list = [3, 4]
       my_list[0] = 5
       return my_list
   
   # Now let's see how this works:
   a_list = [1]
   b_list = passbyref(a_list);
   print(a_list); # [2]
   print(b_list); # [5, 4]
   
   This means that your function definitions become def getCoeffs(poly): and def getExpons(poly): and instead of:
   
   expons = []
   expons = getExpons(trms, expons) # Get a list of the variable exponents of the polynomial
   print("Expons: ", expons)
   we have the simpler:
   
   # Get a list of the variable exponents of the polynomial.
   exponents = getExponents(terms)
   print("Exponents: ", exponents)
   You will also see that I have moved the comment above the code: end-of-line comments are not normally used in this situation. I have also changed trms to terms etc: there is no need for abbreviations like this and they make code harder to read.

To a greater or lesser degree of course these points are cosmetic, but the last two in particular really ought to be sorted as they could cause confusion.

 

[Mark44]

Thanks for the feedback, @pbuk! I have expertise in a lot of programming languages, but I'm still coming to grips with Python, as must be very evident.

Regarding the two functions I wrote, I had a nagging feeling that my versions seemed clunky, but I didn't explore things further. Much of how I do things is colored by many years of programming in C and C++. I recently purchased "Beyond the Basic Stuff with Python," by Al Sweigart, and have worked through the first half in an effort to write code that is more Pythonic.

 

[pbuk]

Much of how I do things is colored by many years of programming in C and C++.

That can make some things harder, but you can also use the knowledge you have gained to your advantage.

For instance once you know that a list in Python is just an array of pointers you can understand some performance implications. For example when we create a sympy matrix and want to access the element M[1][2] of a sympy matrix the runtime goes through the following steps:

1. Lookup the symbol M (1 memory access)
2. Find that it holds an array based at memory location X
3. Use the offset 1 to calculate the address of M[1]
4. Retrieve the pointer at this offset (+1 memory access)
5. Retrieve the item pointed to (+1 memory access)
6. Find that it is an array based at memory location Y
7. Use the offset 2 to calculate the address of M[1][2]
8. Retrieve the pointer at this offset (+1 memory access)
9. Retrieve the item pointed to (+1 memory access)
10. Find that it is a integer with the value 1

This is why we don't generally use lists (or Sympy matrices) for numeric routines in Python: instead we use numpy's ndarrays. When we access the element n.item([1, 2]) of an ndarray the runtime only has to

1. Lookup the symbol n (1 memory access)
2. Find that it holds an ndarray of integers based at memory location X
3. Use the offsets 1 and 2 to calculate the address of n.item([1, 2])
4. Retrieve the value at this offset and cast it as an integer (+1 memory access)

A total of 2 main memory accesses compared to 5 for the list of lists.

(errors, omissions and oversimplications excepted).

 

[Mark44]

Thanks, @pbuk! This is good stuff. In the C, C++, and computer architecture classes I teach, I always cover the difference between accessing data via array indexing vs. pointer arithmetic, and how this can impact running time in loops that execute a large number of iterations.