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.

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.

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.

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.

To Halt or Not to Halt: A Vexing Dilemma That Withstands the Passage of Time

-D23, M11, Y14-
Good morning-day-evening-night to you. As expected, programming is indeed not the answer to the universe; there are only a few many problems that cannot be solved by algorithms. Those who are familiar with the likes of Alan Turing and his Turing machine and/or Alonso Church's lambda calculus most likely recognize this dilemma and may have attempted to resolve the vexation because it would be quite nice to be able to solve everything algorithmically. For those of you who are not so well-versed in this issue:
Imagine you wrote a function that contained an infinite loop that would only run if such-and-such a statement were True, and exited the function if said statement were False. Now, could you write a program that could predict if the previous function would halt (exit) or not halt (run the infinite loop until kingdom come)? Therein lies the conflict, for such a program might be capable of managing some extremely simple variables, but because such a program would have to use the function itself in order to evaluate the function, then:
A--If the predicting program returned True, then that means the function should be caught in an infinite loop, and therefore, the predicting program would have never reached the code within its own body that would allow it to have returned anything.

B--If the predicting program returned False, then that means the function halted, which means that the function exited itself, and if this were indeed the case, then how did the predicting program--which contains the now exited function inside it--reach any conclusion?

If this is flying completely over your head, take a moment to catch those thoughts, and mull over them. A key part here is to note that any return statements in the predicting program that come after the return statements and infinite loops of the function should not be reached.

It is truly a marvel to think about, and because we now have an example of a non-computable problem, this problem can be used to implicate the existence of many more non-computable programs in a process called "Reduction."

Final words:
1__2
2__4
3__6
4__8
: __ :
n__2n

Yet another example of a puzzling dilemma: there are just as many even integers as there are integers. No matter what integer you say, I can match an even integer to it. This means, that even though even integers are a strict subset of all the integers--leaving out all the odd integers--the number of even integers that exist (infinity) is the same 'infinity' as all the integers that exist.

And us humans think we are so smart. We cannot even understand what it means to count.
Thanks for reading!

General Statements and a Remark

-D16, M11, Y14-

Welcome back (or welcome, if this is your first time) to another episode of my take on mathematical expressions and reasoning! After the past week, I feel fairly confident that I can complete a big-Oh proof and its negation without serious trouble. What unnerves me is the increasing scope of the proof (e.g., proving general statements about more than one function via the big-Oh). I cannot help but picture a lengthy series of questions that requires me and other students to take two different pieces of code, calculate the bounds of their worst cases, and then prove a general statement between some combination of the four functions. A massive undertaking that could not be successful unless no mistakes are made. I am certain there are well-paying jobs for this; the ability to calculate code and determine its strengths and weaknesses for a software company on paper must be valuable.

Another remark: I recoil from the fact that some example proofs we do in class have "omitted book-ends" within them. I recognize that the class is not long enough for these book-ends to be included while staying on track with what must be taught, but unless these book-ends are included in the Course Notes posted online for the course, or these book-ends are nothing more than elementary arithmetic (I have not had time to complete these book-ends as of late), it seems somewhat counter-productive to the primary goal of education. If we were to solve these book-ends incorrectly, and convince ourselves when we study that what we did was correct/complete, we harm our own academic growth. Understanding how to structure a proof is vital--but the same can be said for the proof itself. One helps build and solidify an answer, and the other is the answer. Hopefully, if I can make time during this excessively busy month, I will be able to ask my professor or my TA about these "omitted book-ends."

Thank you for reading. 

Big-Oh and Last Theorem Follow-up

-D08, M11, Y14-

Hello my good sirs and ladies. I shall report that the realm of Big-Oh is not as opaque as it at first appeared. Another course of mine that deals more heavily in actual computer-science programming techniques has introduced the ideas of sorting and selecting types of codes in accordance with their performance. This performance is measured through worst-case scenarios, which has consequently made understanding how to derive crude mathematical equations that describe the steps taken in code clearer. For example, binary searching--which involves breaking sorted lists of data into smaller parts and then reducing the size of the relevant part of the list until you have found the specific data you asked for--is based off of logarithms. In a sorted list of 2048 indices, binary searching would take approximately 11 steps in the worst case scenario (the item is not within the list) to complete the search, while a linear search pattern (looking at each index one by one) would take 2048 steps to complete the same search. As you probably know, the log(2048) with base 2 is equivalent to 11, and thus the general pattern of binary searches are: log(list_size) with base 2 = number of steps n. Big-Oh cases simply aim to state this process in a logical proof.

Alright, aside from that, I have been working on and off on the treacherous Last Theorem, and have managed--I think--to have proven the Last Theorem for all integer exponents that have a factor of 4. If you do not recall, the Last Theorem states that there are no three positive integers a, b, and c that can satisfy the equation a^n+b^n=c^n for any integer value of n greater than 2. In my uploaded photo, you will notice that I did not include a proof for all n that have a factor of 4, because--aside from the fact that it is intuitive to believe that what does not work for the number 4 will not work for the number 4(2) or 4(3) or 4(4) or... 4(n)--I at one point was frustrated by my inability to prove the theorem when n = 3, and ended up looking to the World Wide Web for guidance.

Feel free to peruse my effort and point out my mistakes. My problem-solving process was to transform the theorem into a mathematical expression, analyze the contrapositive and negation to determine what seemed easiest, and attempt a proof for a small portion of the theorem. My proof was a proof by negation. Hopefully, after careful review and anyone else's insight(s), I will be able to revise and/or expand this proof.

Thank you for reading and perusing!