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:

1. Leave everything as is so one would call, for example, Point.are_collinear() or LinearEntity.are_concurrent()
2. 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.
   
3. 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.

Updates!

Since it has been over a week since my last update, I figured I'd just leave a note so that everyone knows what's on the go with my SoC work. One thing I've been doing is profiling the code and making small modifications here and there to speed things up a tiny bit. Some things may be impossible to speed up since I use the simplest possible formulas and whatnot. I've also been looking at the interface, and have been considering how to improve its usability. I haven't came to too many decisions as of yet. I'm hoping that within the next week I can have those decisions made. I am fairly happy overall with the current interface, and think it's fairly simple to use. Once I get that finalized I'll start working on some documentation about the interface, and also a tutorial. I'm also going to go through the code and rewrite the docstrings so that they are a little more than the obvious.

I have been working though, fixing up some simple issues, mostly involving pretty printing. Got to have things print pretty though! I think eventually I may start looking into the match routines and see if I can make them more robust. That's about it for now!

Current Work

So basically I've been kind of caught up this week in a bunch of things. As for my SoC work, I'm working on some core stuff for the trig module, which will include simplification of some trig identities along with trig expansion. Right now what I have gets unbearably slow quite fast, so I'm looking into ways of speeding things up. As for taking an expression and combining it into a single expression, well I'm not worrying about that for now because it seems like it may be much more complex (but I don't know for sure). Things are moving though, and things are going pretty good especially considering the fact that the actual date for beginning coding is a little more than two weeks from now.

Getting There

So the first iteration is nearing completion. You can get a copy of it by clicking here. Most of the functionality is there, but I do not guarantee that it will all work perfectly yet. There isn't a lot missing besides for a couple of things in polygon/triangle, along with some missing ellipse intersections (besides for ellipse/line intersection). You can give it a try, but there is no document describing how to use it right now. The layout of code is very similar, but not the same, as the UML Diagram I created before starting.

If anyone decides to give it a try, give me some feedback on the interface and how easy it is to use, some suggestions you would make, some errors you encountered, and your own test cases that fail. All feedback will be greatly appreciated. One of the things I didn't plan on doing but may work on later is reporting to the user what conditions will make something True. For example, if the user asks if the points (1, 1), (2, 2) and (x1, x2) are collinear, there is no way to tell. Right now the system will return False, but why not be a bit more informative and return some structure, or raise some exception saying that it would be True if x1=x2. Maple works this way.

There's still a fair bit of work to do, but at least a "proof of concept" implementation is in place. The set of test cases I've been using are also available if someone wants to look at them for ideas on how to use the code.