Quick Update
I've looked into changing around the interface a bit, but I always ran into trouble so I've decided to leave things as they are and have begun writing some basic documentation. That's about all that has been happening for the past couple of weeks. Before this week is done I should have the documentation written and then will look into what to do after.
Decisions, Decisions
SymPy
One of the major usability issues I'm finding with the current interface for the geometry module is the static methods that exist. In one way they really make sense since things are grouped together appropriately, but it's extra typing required and the ideas of concurrency and collinearity, for example, will [most likely] be obvious to those using the module. This brings me to a few options to take, and I'd love to hear any one's opinion:
I personally like #2. The classes will become simpler, and I can hide more things. In terms of the latter statement, the reason I like #2 is because I'd like to hide the LinearEntity class as much as possible. It's more or less there to reduce a lot of code that would be rewritten, yet I don't really want it to be exposed. Right now this is the only thing I'm really looking at in terms of the interface, because I think it's a reasonable one. So, any thoughts or suggestions on those options, or maybe a better option that I haven't thought about?
Research
As for my research, things are coming along there too. I really wish I put a bit more extra effort in there since it is what I plan on doing in my future. Progress has been quite limited lately due to the fact that I'm entering the more difficult area of my problem for analysis. The problem is simply Largest Common Subgraph, and currently I'm only doing an analysis under the classical complexity theory (i.e., NP-Completeness). I'm gonna take a close look into a few of the "unknown" areas left and then hopefully start looking into a parameterized analysis of the problem. Parameterized analysis is a big thing for my supervisor, especially since his PhD supervisor was half of the team which developed the theory. I really like it; it's a very practical complexity theory.
What I'm hoping to do is more in-depth literature search, start BibTeX-ing my references and really focus on writing a paper out of this. With both a classical and parameterized approach, along with algorithms for some of the sub-problems that are poly-time, I'm hoping I can get a paper out of this. Maybe I'll also introduce the practicality of the problem with examples from chemistry (such as molecules, and similarity between them). If all goes well, maybe it can even become my honours thesis, or at least a strong foundation for my honours thesis.
One of the major usability issues I'm finding with the current interface for the geometry module is the static methods that exist. In one way they really make sense since things are grouped together appropriately, but it's extra typing required and the ideas of concurrency and collinearity, for example, will [most likely] be obvious to those using the module. This brings me to a few options to take, and I'd love to hear any one's opinion:
- Leave everything as is so one would call, for example, Point.are_collinear() or LinearEntity.are_concurrent()
- Refactor all of these static methods outside of the class into a more "global" setting such as util.py so that class prefixes would not be required, hence separating control and structure (Very Model-View-Controller oriented design). Currently the control is in the classes and accesses the private data of each. This option would not access the private data since it will be external to the class itself. This is doable since all pertinent data is readily available through methods or property methods.
- Since all the functionality already exists in the classes, simply leave it there and wrap all of them in a more global setting so that less code has to be moved and very little written.
I personally like #2. The classes will become simpler, and I can hide more things. In terms of the latter statement, the reason I like #2 is because I'd like to hide the LinearEntity class as much as possible. It's more or less there to reduce a lot of code that would be rewritten, yet I don't really want it to be exposed. Right now this is the only thing I'm really looking at in terms of the interface, because I think it's a reasonable one. So, any thoughts or suggestions on those options, or maybe a better option that I haven't thought about?
Research
As for my research, things are coming along there too. I really wish I put a bit more extra effort in there since it is what I plan on doing in my future. Progress has been quite limited lately due to the fact that I'm entering the more difficult area of my problem for analysis. The problem is simply Largest Common Subgraph, and currently I'm only doing an analysis under the classical complexity theory (i.e., NP-Completeness). I'm gonna take a close look into a few of the "unknown" areas left and then hopefully start looking into a parameterized analysis of the problem. Parameterized analysis is a big thing for my supervisor, especially since his PhD supervisor was half of the team which developed the theory. I really like it; it's a very practical complexity theory.
What I'm hoping to do is more in-depth literature search, start BibTeX-ing my references and really focus on writing a paper out of this. With both a classical and parameterized approach, along with algorithms for some of the sub-problems that are poly-time, I'm hoping I can get a paper out of this. Maybe I'll also introduce the practicality of the problem with examples from chemistry (such as molecules, and similarity between them). If all goes well, maybe it can even become my honours thesis, or at least a strong foundation for my honours thesis.
Rubber Bands
My latest development is the convex hull algorithm. For anyone who may be unfamiliar with a convex hull, think about it this way: imagine a set of points in the 2D plane. Now imagine stretching a rubber band so that every point is inside the rubber band. Finally, let this rubber band close in on the points. Every point that the rubber band touches is part of the convex hull, and forms a polygon such that every point is contained on or within the polygon. I used the Graham scan algorithm to perform this calculation.
This pretty much completes the functionality that I specified I would do so now it's time to go back and look over everything for usability purposes. I want to make the interface as intuitive and as simple as possible for use. After that, it's documentation stages. Finally, after all of this is done I'll look into other possibilities for the geometry module such as 3D geometry, or possibly consider working on some other stuff in the SymPy core.
This pretty much completes the functionality that I specified I would do so now it's time to go back and look over everything for usability purposes. I want to make the interface as intuitive and as simple as possible for use. After that, it's documentation stages. Finally, after all of this is done I'll look into other possibilities for the geometry module such as 3D geometry, or possibly consider working on some other stuff in the SymPy core.
Subscribe to:
Posts (Atom)