A Special Announcement... and Trees

-D01, M03, Y15-

Hello and welcome back! Due to the absence of classes the week before last, there was nothing to report. And now, for a specialized announcement:

----------------------------------------------------------------------------------------------------

Dear TA,
    I choose my summary of object-oriented programming for assessment. It may not be technical;        however, I was of the opinion that the concepts were of greater importance.

----------------------------------------------------------------------------------------------------

And now, back to our regular program:

So this previous week we came upon recursion in what have been termed 'binary trees.' Rather than create trees of code where the root and its internal nodes have any number of child nodes, these binary trees always have no more than two children per internal node or root. For those who are having trouble visualising such a thing, consider factor trees from your childhood:

The difference between binary trees and factor trees include:
+Binary Trees ["BT's"] contain unique data (no repeats of data)
+BT's do not require factoring--only the structure is the same.

In addition, we learned how to utilize binary search methods (recursively of course) on these binary trees. These search methods, which are dependent upon the organization of the BT data structures (for example, a BT could be organized such that all numbers to the left of each internal node--and the root node--are less than the node in question, and the numbers to the right are larger than that node) allow for data to be searched for supremely faster than if the computer was forced to check every piece of data within the BT. Binary search methods are equivalent to the logarithm function, and I must say, I definitely prefer searching through the log(10-kajillion) than searching through 10-kajillion pieces of data.
Just my personal preference. No pressure.
Just kidding, this shouldn't even be up for debate. 10-kajillion searches when data is already organized in a clearly helpful manner is madness.
Thanks for reading!

Class-Action Python-suit

-D15, M02, Y15-

"You are not the Father."
If you have heard that line before, you have either been on the internet far too long, or you have watched that particular show. For those of you who are familiar with object-oriented programming, the negation of that statement should ring a few bells. Or alarms. Or whatever it is your class does.

For those who aren't familiar with object-oriented programming:
Think of a thing that has a function. Think of a washing machine, a cash register, an ATM, a racehorse. Now, strip away its physical manifestation, leaving only what it does in its stead. A cash register can take in money, money can be taken out of it, money can be exchanged, it's possible to check how much money is in a register.
Now, transform those things into binary, all contained within one grouping of code.

That, is a class. 

Amazing, is it not? 

Rather than toss a load of functions into some file, you can group them together in a class. Although they work like functions, they are referred to as methods when this occurs. If a function requires the use of a class/a classes various arguments of inputs/outputs, then consider transplanting it into the class. This form of structuring code is useful in keeping similar code together and working, allowing for a process dubbed 'inheritance.'
Inheritance allows a class to bestow its methods for use in other, more specialized classes. This way, if you must alter your code in some fundamental aspect, you will not need to go through each class of code that requires the power of the 'father/mother-class.' Unless what you changed was specifically utilized by the child-classes of course. Moreover, because the child-classes have all the attributes of the parent-class, and then some, it is no longer necessary to directly access the parent-class's methods.
Thus, you turn objects--fiction or non-fiction--into lines of code.
For a less concept-focused perspective, the Python Foundation has an extensive explanation on the nuts and bolts of __init__, class(), __repr__, instance variables, and the like.
Thank you for reading.

Post Scriptum:
Zvikaramba, if you're reading this, THANKS FOR THE FEEDBACK. And the name's Jameson.
John.
Jonah.
Jameson.

Recursion and Test-ing

-D07, M02, Y15-

Top of the morning/day/evening to you! Now that I have raised my own spirits, I shall talk about recursion. I do not know what has occurred between last week and this week; yet somehow, writing recursive code has become clear--at this point in time of course. You simply implant your function or method with itself whenever you reach a point where the code might fail otherwise. Practicing writing the output of such code has not particularly helped me as much as actually seeing recursion utilized in more ways. And by different ways, I speak of sorting methods such as quick sort, as well as Stacks and Queues.

Even though I still cannot wrap my head around recursion (I get that it is similar to solving a problem inside another problem...but the fact that these are the same problem is truly astounding, especially since you have not finished solving the first problem in the first place), creating and using stacks and queues (which are simply program versions of what they are in reality) has been helpful. Although other students like Courtney here have had little trouble with these things, I admit that I abhor using techniques that I do not understand. Well, to a satisfactory degree, that is.

Besides this, we had a midterm this week in place of a lecture, testing on our understanding of recursion, inheritance, and class and method structuring. It was fair, and I believe I did well--especially because coding recursion was not on the test. In the future, I expect that we will learn some techniques involving raising Errors, 'trying' code, and other preventative measures to protect code from breaking in unusual circumstances.

And finally, the idea of unittest, where you write an entire separate file to test the extent of your code. At the moment, it seems excessive, given the ease of using doctest, which works within the code itself; nevertheless, I am sure that this will not be the case when we must code thousands of lines for a client or clients. The most difficult part of writing any form of test cases would be writing them to actually push your code to the extreme. I don't know why, but I really don't want to hurt my code. Being the creator of the code, you understand how it works, and it becomes difficult to deliberately try to misuse it in ways that should work properly. It is analogous to breaking in a shoe that you just finished making, except it might explode if done improperly.

Thanks for reading.