Sunday, 8 March 2015

[List]---[List] (It's a Linked list ok)

-D08, M03, Y15-

Hello and welcome back to another slog post brought to you by our sponsors:
Just kidding, I have no sponsors. In fact, at the moment, a substantial portion of all higher learning staff members--primarily teaching assistants--are on strike, so everything is 'up-in-the-air' (uncertain). Hopefully, the universities involved will be able meet the union's grievances without causing further suffering for us victims students.

Anywho! An assignment we had last week was quite challenging--particularly in the case of creating an artificial intelligence that employs recursion to determine the best outcome. I had hoped to work together with a friend on the assignment; but alas, all my friends had already paired off, and I wasn't going to throw my chips in with someone I didn't know or someone who did not aim to work just as hard as I would. *shrugs*

Aside from that, we went over a new data structure: Linked Lists. Values that 'point' to other similar values in such a way that each value only points to one other value--think of a regular Python list (or not, here's an example: [1, 2, 3]) except with arrows replacing the commas and an additional arrow at the end pointing towards 'the end itself' (e.g., [1] => [2] => [3] => [X]). Because this type of chain-listing does not exist by itself, a 'Linked List Wrapper' is used to keep track of this data structure (the first value is referred to as the 'front,' the last value as the 'back,' and the like). Overall, I do not see this as too terrifying an idea. As with all things, there are likely to be difficult pieces to this puzzle; nevertheless, lists are not particularly as intimidating as recursion.

Thank you for reading.

Saturday, 28 February 2015

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!

Sunday, 15 February 2015

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.

Saturday, 7 February 2015

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.

Saturday, 31 January 2015

Some Deliberations Concerning the Month of January

-D31, M01, Y15-

Welcome back! Something may feel different since the last time you were here--presuming you have been here before. What could it possibly be? The entire display has been revamped. That's what it is. No, I will not be focusing my future blog posts upon the topic of the Medieval Ages (although that is quite tempting); however, I will be taking the time today to speak of my experience so far in my computer science course.

+ First off, I was tasked with creating not only a text-based Python game, but also with creating the game environment in which the game--and others similar to it--could be played. For those with minimal programming experience, think of it as creating the Main Menu screen of a 3-in-1 game and then making one of the 3 games.
I must say, it was quite challenging to do alone. I have had experience creating games in the past; however, those did not require object-oriented programming. At least, not in as direct a way as was required for this assignment.
All in all, I feel as though I should make an effort to work with a partner in future assignments, not merely to help distribute the workload, but to possibly understand what it means to work as a team on a single project. Not many programmers work alone, so obtaining some experience--and possibly more programming friends--would be a good idea.

+ Second, Recursion. Wow. Basically, create a function and then use that function inside its own code. It drives me nuts. Yes, I have no trouble tracing through recursion code...but when tasked with creating one that does nothing more than return the largest list length out of an argument that is a list of a list of a list of integers...NO. Nothing I attempted worked. The fact that it calls itself within itself is just preposterous. How do you keep track of all those lists if the function calls itself after taking note of one list in order to deal with a list inside the previous list?
See? I don't. I intend to research this further unless more is taught in class.

+ And third, I am somewhat put off by the style of teaching. A large amount of it revolves around teaching concepts through showing examples of code in class in combination with online course notes. For some reason, it does not really feel like learning. Now of course, there is a probability that this is a good thing--that I am enjoying what I am learning. I loath the idea that I should base how much I have learned upon how well I do on future tests; but the educational system in place presently leaves me little choice. Regardless, I intend to put my knowledge and skills to work after the semester ends by creating game apps for Android as a more competent way of assessing what I have learned.

Thank you for reading.

Saturday, 24 January 2015

Code Note

-D24, M01, Y15-
Hello and welcome back to another exciting edition of this blog. This time around, I shall be stepping away from mathematical expressions and reasoning to focus upon programming itself. Over the past week or so, I have read a number of articles and blogs concerning the necessity of having such a blog.

From my perspective, a blog--as in, an internet-based journal of sorts--is not necessary; rather, a way of keeping track of one's programming endeavors is. Last year, when I first began to program seriously, I kept track of my problems via 'ye olde and relyable' pencil and paper. It would consist of written out code, which I would implement in a programming environment (known as Wing), in addition to crossed out lines of code, comments scrawled around it and within it, and various diagrams and sketches depicting both what I desired the code to do and my varying reactions as the code itself failed and/or succeeded.
Especially important was writing down exactly what caused the error(s)--less important were the excess words I employed to berate myself in the cases where I had merely misspelt code or forgotten some key characteristic of, say, a dictionary.
In doing this last semester, I assured that I would not make the same mistakes again, either from memory, or by simply referencing my previous writings.

In sum, documentation is key to effective coding. Now, it is important to note, as Mr. Mark Dalrymple did, that, when coding for clients, a computer scientist should transfer such documentation to a secure file of some sort in the event that the terms and conditions of the job require it to be sent to the client.

Until then, I shall document the bulk of my bugs and solutions on paper...and post the most notable of them on this blog. Last week, I came across a notable bug that angered me quite a bit, so here it is:
--------------------------------------------------------------------------------------------------------------------------
Problem: when initiating a class with only one argument (self) along with an instance variable creating a dictionary, Python declared that said instance variable did not exist. An AttributeError.

Solving-Process:
After indignantly shaking my head at the object's failure, I call it a few more times to be certain. Indeed, something is wrong. Try adding the instance variable as an argument? Of course that works, but not the way the object ought to. I need the object to initiate it's own empty dictionary, empty list, etc., without an additional argument!
ARGH.
All my notes say I am right. What is this?
Finally decide to speak to a fellow computer science student also taking this course, I shall call him T. T's code worked correctly and after a single comparison, I was certain that my code was structured in a nearly identical way. There are only so many ways to write an __init__ method for an object at this point in time. I shall call my code one more time.
FIX: I forgot the ending parentheses for the object consistently until this point.
This is beyond embarrassing. Never again. At least it is solved.
--------------------------------------------------------------------------------------------------------------------------
Thanks for reading, I hope I elicited a chuckle of some sort at my own expense.

Monday, 1 December 2014

Final Words Concerning Mathematical Expressions and Reasoning

-D30, M11, Y14-
Hello. So I have been painstakingly attempting to comprehend and apply the halting function to another uncomputable function via reduction, where you define the uncomputable function within the halting function to show that said uncomputable function is in fact uncomputable.
<<about 3 hours later>>
Alright, I think I managed to apply successfully. It seems that these type of not computable functions hold to similar structures: they return only boolean or they return some other output that never changes--such as the number 42. Only then does it seem that the halting function can be (presumably) defined by these functions, and since we know that the halting function is not computable, it is safe to say that the function of interest which was utilized to define the halting function, cannot be computable either.

Now, aside from this, we were briefly introduced to the idea of induction. Although this is a topic in Calculus courses, the steps by which computer science induction is completed has a key difference: you begin with the induction hypothesis, prove it with the induction step, and then determine the base case(s). Although this course makes heavier use of mathematical expressions than Calculus, I do not see how induction problems in this course can so differ from induction problems in Calculus is they are the same thing. The first replaces language with their mathematical equivalents, whilst the second retains the language.
However, the induction problems in this course do bear a striking resemblance to big-Oh and big-Omega proofs, and those are definitely easier to prove when one goes through and proves it and then determines what elements (c and B) were necessary for the now complete proof to work.

It sounds suspiciously similar to circular reasoning, in my opinion, but that is a discussion for a later time. Thank you for reading this conclusion to Mathematical Expressions and Reasoning.