GSoC 2017 Application Mikayla Z. Grace: Extend Implementation of Different Vector Coordinate Systems to Vector Functions - sympy/sympy GitHub Wiki

Extend Implementation of Different Vector Coordinate Systems to Vector Functions

Name: Mikayla Z. Grace

University: University of Vermont in Burlington, Vermont, USA, class of 2019

Concentrations: Pure math major, writing minor, mathematical applications of computer science minor

Current skill set: New to GitHub; beginner in Python; intermediate in math

GitHub: https://github.com/mikaylazgrace

Programming preferences and experience:

I have taken an introductory CS course in Python at my school as part of my math major, but I discovered that I really enjoyed coding, particularly coding to solve math problems. While I am not enrolled in any programming classes this semester, I recently set up my GitHub account and am independently working on becoming more proficient in Python and Git through Code Academy. I would say that by the end of the semester and the start of the program I will be a solid beginner in both. I also have an on-site mentor, Christelle Vincent, PhD, who will be available over the summer. Regarding my mathematics background, I am a second-year pure math major and would put my math level at “intermediate”. I have taken courses in calculus, statistics, abstract algebra, number theory, and combinatorics.

My computer platform is a PC running Ubuntu. I have only used Python to code, and I use Idle as an editor, both of which I was introduced to through my CS course. My CS class used Python in Idle, so it was my first exposure to coding, and I’ve stuck with the same language and editor. Although I have not tried any other languages yet and don’t have another language to compare it to, a feature of Python that I like is how beginner-friendly it is. It was a great starting point for me to get into coding and while it is easier to learn than other languages, it can still build complex software such as SymPy. I plan on trying other languages and have an interest in learning Java through Codecademy. I have not yet used any other version-control software except Git, which I am still learning about. I’d like to explore other version-control software once I’m more advanced in Git.

In my CS class, a program that was fun to write was a guessing game. The assignment was to have the user guess how many jellybeans were in a cylindrical jar. Upon initializing, the program automatically created a “jar” using randomly generated height and radius. Then the volume of the jar was calculated which was then be used to determine how many “jellybeans” it contained. The user has was then given the jar’s dimensions and had to guess how many beans they thought were in it. The input was compared against the actual number and the player would “win” or “lose” based on if their guess was correct. We later modified this program to provide feedback to the user to tell them if their guess was too high or too low and gave them another chance to guess.

My favorite feature of SymPy is its ability to generate prime numbers. I’m a pure math major, and primes are one of the most mysterious aspects of math. They have a universal range of applications, and every number is generated from them, yet theorems like the Riemann Hypothesis about the distribution of primes are still unsolved. Currently, no one has a way of determining primeness except by brute-force factorization which can take supercomputers days to compute. I like that SymPy is exploring generation of primes through the Sieve of Eratosthenes, as I recently studied that method in my number theory course. I like that SymPy’s sieve is “smart” in that the sieve gets automatically extended up to any odd number that is requested but has not yet been sieved by SymPy.

Prior contributions to SymPy: WILL UPDATE IF PATCH IS MERGED

I currently have 2 PRs for SymPy. One is a patch I am working on that addresses an issue raised by another user in issue #8648 regarding the function .is_even. The original question was very specific: Given n is even, then n**2/2 should also be even. As it stood, SymPy returned None. Only answering this specific scenario would have been trivial, so I generalized it to take an integer written in quotient form and determine evenness/oddness by analyzing its decomposition. First, the function checked to see if the expression as a whole was an integer. If it wasn’t an integer, then it would return False because a number can only be even or odd if it’s an integer. If the Boolean value of .is_integer was true, the expression would be decomposed and each argument from the numerator and denominator would be tested to find out how many factors of 2 were in each. Counters outside of a for loop kept track of the factors of 2 and compared them at the end, with more 2’s in the numerator guaranteeing the number was even. More 2’s in the denominator or the same number of 2’s in the numerator and denominator returned None because we don’t have sufficient information to make a determination.

My other PR was testing for this function. Once the function from above is completed, I will go back, update the tests, and submit another pull request with the tests.

Project:

Currently, SymPy only accepts vectors in Cartesian coordinates. However, a user may wish to use another system such as cylindrical, spherical, or polar coordinates. These systems can be applied to certain problems in calculus and other areas of higher math which is why they are useful tools to include in SymPy. As a math major, vectors interest me because lines and vectors are simple elements that are well-understood, but they can be used to solve very complicated problems. I took linear algebra and calculus I-III, all of which heavily emphasized vectors.

To implement a system that divides the coordinate systems into classes would be helpful so that a user may define which system they would like to use. While there has been discussion debating whether a superclass or set of individual classes would work better, I'm favoring the former because of the issues raised in the comments in PR #10109. The framework for each class would parallel the existing class CoordSysCartesian for both consistency and readability. Once the classes have been created, creating functions to convert between them would be a logical next step. Below are the transformation functions between Cartesian (x,y,z) coordinates and spherical and cylindrical coordinates from an article shared with me by Alan Bromborsky.

Spherical polar coordinates and scale factors:

Cylindrical polar coordinates and scale factors:

The creation of each class is a natural place for a pull request to break the project into manageable branches. Adding functions to convert between them could be a pull request as well.

In looking at some previous work done on vector coordinate systems, it seems that there have been two major trains of thought: Either we should have each coordinate system be its own class or have a superclass that has subclasses within it (see PR #10109). Via email contact with Francesco Bonazzi who has done prior work on the topic (PR #9937), it seems that he has worked on creating a single class that would encompass all the coordinate systems where the individual classes are instances within the one overarching class. In the previous work with the superclass, there was some prior exploration in allowing for user-defined coordinate systems, which would be good to include and create a specific subclass for, so as to allow greater freedom for the user.

As an extension to this project, once the classes handling different coordinate systems are in place, it makes sense to modify the vector functions like dot, cross, etc. so that they too may handle different coordinate systems. This could easily be implemented since the functions already take Cartesian coordinates. This means other coordinate systems could use those same functions if we converted all classes to Cartesian coordinates, performed the function, and then converted the vector back into its originally inputted class before returning it. This would be optimal as it would reduce the internal redundancy of defining the functions again in each coordinate system. This extension could be a pull request.

Timeline:

For a timeline, this project can be broken up into three parts that would fit with GSoC’s three phases.

Phase I: Creation of polar coordinate subclass and spherical coordinate subclass, as well as conversions and handling

Phase II: Creation of cylindrical coordinate subclass and creation of conversion functions, as well as conversions and handling

Phase III: Creation of user-defined subclass and integration with other SymPy functions like plotting, integrating, dot product, etc.

I would think that the creation of the class and subclasses would be the majority of the work, as the latter phase would draw heavily on existing architecture within SymPy.

I have no other commitments or any vacations planned during the course of this program, so I will be available and willing to devote a minimum of 40 hours per week.

What I Hope to Get:

I view Summer of Code as an opportunity to immerse myself in coding. I view SymPy as an opportunity to merge coding with my passion for math. I hope that by coding mathematical concepts and problems, I will emerge with a deeper understanding of the mathematics involved because in order to code math, you must understand every aspect of the problem, otherwise the code won’t run or it will give unexpected errors. I hope that the learning experience of participating in Summer of Code will allow me to be a better coder and mathematician.