Today I learned a very valuable lesson; reading the tests in a suite will often prevent much heartache. I say that for a few reasons. While my primary (and thus actually preferred) programming language is Matlab (totally should be read as "Octave"), I often tell people that it's Python. Why would I do this? That is because, as I mentioned in my previous post, the population of people who understand that language is sparse and I'd rather not have to deal with the slightly awkward expressions offered upon hearing this. Why are the subsequent expressions awkward? I don't actually know. I could make guesses, but since I'm unlikely to receive a truthful answer, then a "guess" is all they would amount to, at best. In other words, without plopping someone into an environment and evaluating their emotional state (how would that be done exactly?) as they go through the language, it's almost impossible to verify or place any validity in an answer received, outside of "I understand it" or "I do not understand it". That being said, it's often easier to choose the lesser of two evils and choose a language with which the audience is at least somewhat familiar.
What does this mean on my end? It means that, for everything I've ever written in Octave/Matlab (I'm going to be using the names interchangeably henceforth due to the extensive similarity in their code), I will be rewriting an edition in Python. Does this mean that I know Python and consider myself an expert? Not in the least, however since Python seems to be the official language of the sciences, and it's used by one of my all-time favourite entities, CERN, then I'm certain that Python can handle almost anything that I throw in its way. The downside is that this also means a lot of reformatting and that there may be some computational errors along the way. Probably induced by the data structures themselves but I don't actually know how Matlab stores matrices, much less how it allocates memory for these things. I mean, I know it has data structures, but I'm pretty sure it's unique in its processing, since it handles the mathematical computations exceedingly well.
Conversely, I'm honestly having trouble getting the same function to work well in Python. 
Like, it ends up being a much smaller amount of code but these
suggest that something is going to have to be handled differently if I want to maintain functionality even in this context. Granted, the Python edition doesn't have the surface plot encoded or even the contour plot, but if it is honestly having trouble with the initial portion of the descent then I probably shouldn't worry about either of those things as yet.
Nevertheless, I'm again proud of this little accomplishment of getting my budget written over and working with some sample data. 
In this case, the linear regression plot
works as well, but I ended up having to use numpy's polyfit feature instead of gradient descent like I wanted to. Either that or severely limit the range being used in the analysis...but that honestly seems a bit contradictory since gradient descent is hailed as a machine learning algorithm designed to find the local (or global) optima and I feel that if the range becomes too small then its ability to do that would be heavily stifled.
I suppose, therein lies the challenge; finding the happy medium satisfying a sufficient range and a runtime that doesn't last a lifetime. Either that or find something else that performs much the same task. Nonetheless, I'm still pleased with even this minor bit of progress.
Top comments (0)