This semester I was only enrolled in a total of 11 credits worth of classes (Embedded Systems – 4, Discrete Structures – 4, Software Engineering – 3). Since my status at the university is a non-degree graduate student, full time is set to 6 credit hours, so I was a “full time” student. But technicaly, since I was taking undergraduate courses, I was taking what normally would classify me as a “part time” undergraduate student. This was the first semester in which I had taken anything less than what my normal course load from before of 14-18 credits. Yet, despite only taking 11 credits, the classes kept me busy and on my toes. Academics still took about 30-50 hours per week (yes, I do time logs), and that I still came across those seemingly inevitable nights of studying, working on homework, labs, projects, etc.

Since my focus was strictly to satisfy my course prerequisites for the MS Computer Science program, I wasn’t involved on any on-campus clubs this semester. Previously during my undergraduate years I was deeply involved in organizations such as student government, publications, and clubs. But disconnecting myself from that to focus on academia certainly freed up more time towards doing well in my courses.

I actually ended up enjoying all of my classes, where my favorite one was Software Engineering. I particularly have this keen interest towards software requirements and analysis over design. It’s not so much that I don’t like designing products because I do — I woudn’t be an engineer if I didn’t. Just, I feel that it’s in my nature that I focus a lot on “future-proofing”, because one thing that I don’t like is having to change a design halfway (or more) through because requirements weren’t clarified. Also, I’m interested in looking into propective future software life-cycle models. Considering the history of software engineering, it’s pretty interesting at looking how life-cycle models have evolved. And as software companies are working in what seems to be a very popular object-oriented life cycle model, it’d be some food for thought as to what sort of model companies would be working on 10-15 years in the future.

Embedded Systems introduced me to lower-level programming, particularly Assembly language. I actually found myself not hating the language as it seems most people around me seem to, and I enjoyed the labs. I bought the microprocessor board the lab uses (Dragon12-Plus) as my justification to save gas money since on a typical morning it’d take me 45 – 60 minutes to get to campus. To me, the cost of the board (~$100) and the documentation ($0) was a much better expense than the text, and I’m happy that I do have a microprocessor board on me for future projects that I want to take up myself.

Discrete Structures was a class that seemed as if it took basic principles of logic and turned it over its head. I found the homework, quizzes, and exams to be not so much math problems but as puzzles instead. Boolean logic, set theory, proofs, and graph theory was the most interesting to me, but I never seemed to get combinatorics right. Even despite studying and practicing countless combinatorics problems, I was always bound to get something wrong! Even though the class is already done a part of me still wants to continue studying the topic by doing a problem a day or something around that sort. I do have a lot of respect for the instructor for this class since I perceive it as a class that would be difficult to teach without having the material get too dry for the students. Her heart is devoted to the topic, as it was also the area that she specialized for her Ph.D, and I wish I had as much passion in logic, algorithms, and the sort as her.

Taking just three classes with no other outside obligations was the perfect number. It certainly deemed itself as such come the time of final exams. Both Embedded Systems and Discrete Structures’ finals were both comprehensive. In the past, comprehensive final exams were the worst. There always seemed to be so much material to cover, and the stark realization that there was material that needed to be covered that was uncovered. However, studying for both of the classes wasn’t so painstaking as I initially thought. Reviewing the previous two exams for the classes and going through notes and homework for the later end of the classes were enough, since I had spent so much more time on preparing for the first two exams. Also, somehow by taking just three classes made it feel like there wasn’t enough material that was covered, and the structure of topics for my classes just seemed to make sense.

That all said, I did remarkably well in all of my classes, with multiple instances where I’ve scored well above the curve. However, I didn’t do quite as well as I had wanted because I had been working for a 4.0, and fatal screw ups in the combinatorics section of Exam 2 of Discrete Structures I feel inevitably will bring me to a B. So, I am expecting as my grades this semester as an A in Software Engineering and Embedded Systems, and a B in Discrete Structures bringing my semester GPA to a 3.64.

But I can’t complain. It was a good semester.

I am thankful that school is going, more or less, well. So far I am doing good in all of my classes. My first round of midterms went exceeding well where I scored very, very high above the class average. However, my second round of midterms have been a bit of a setback for me scoring around the average. I may have become more complacent, or perhaps it was just an incredibly busy few weeks leading up to my “hell week”, but it’s okay. I still retain A’s in my classes and I hope to keep them as I come out of the semester.

There is, however, the unfortunate news that the graduate committee at KU hasn’t formally accepted me into their MS Computer Science program yet and insists to keep me as still a “non-degree” graduate student. The initial plan was for me to take course prerequisites (which I am doing now) and with a few prereqs out of the way, change my status from “non-degree” to “degree seeking” graduate. Honestly, I’m a bit surprised that I wasn’t transferred even as a “provisional” graduate student since my background is still within an engineering discipline (aerospace) versus something completely different, such as a humanities.

In either event, the “non-degree” status puts me at a setback with even continuing taking prerequisite courses to transfer into the MSCS program financially. A huge majority of financial aid is distributed under the condition that the student is “degree seeking”, and without those magic words under my status (despite the fact that I am seeking a degree) restricts my student financial aid to a null.

However, I had put in a few applications to other schools and their Masters program and fortunately I did get admitted to a Masters program in a Electrical/Computer Engineering and another one in Software Engineering at another University. (Not going to disclose the name yet.)

I’m in the works of handling a few financial kinks to determine whether it would be financially feasible to transfer to that University as soon as the Spring semester (January 2010). If it isn’t possible, I was given the option to defer my admission to Fall 2010, which then gives me enough time to find a job to take care of a few upfront costs.

That being said, I’m back on the job hunt. Despite the economy picking up, unemployment is still in record highs and I have that betting against me. But, I’m not giving up. I’ve sent a number of job applications out the past month and will be continuing to do so until something fruitful comes up. I’m also certain that at some point, I will find a good job where I can use my income to help me pay for my graduate school.

It’s hard for me to find anything to be thankful about being on the job hunt; being unemployed and looking for a job has been such a mind numbing, stomach wrenching experience. But, I am thankful that this time I am allowing myself to extend my opportunity to branch out elsewhere.

• a Discrete Structures exam
• an Embedded Systems exam
• a laboratory demonstration I need to present on modulus counter timers
• submitting design phase artifacts for my Software Engineering class, which includes the design specification and a prototype

I believe that for the most part, I have this week under control so long as I carefully manage my time correctly. But, I will post closer to the end of this week once things are done and out of the way on some more (big) updates on graduate school, job searches, and also a little thing that I happened to get my hands on today — Droid.

More updates to come later!

Even though I am, by technicality, a “graduate student”, I am still taking undergraduate classes in computer science since I’m in the transitory period between becoming an aerospace engineer to a computer scientist. One of the courses that I’m taking is a software engineering course that seems to be mostly comprised of juniors and seniors, and my professor ties in a lot of real-world work experience in making the material of software engineering come alive. Without a doubt, this class is by far my favorite class since I like a systematic, disciplined approaches to design and also because for each topic, I could relate with my own work experience, even though it may not have been directly related to software.

My professor talks a lot about different roles and functions people have (requirements analysis, programmers, designers, SQA, etc) and also reminds us to open our mind to what sort of role we, the students, see ourselves in. Whenever I think about, it ends up turning into a higher level thought of, “What do I want with a Master’s degree in Computer Science?”

I do know that I want to complement my Bachelor’s in Aerospace Engineering with this Master’s. From my time working, it’s apparent of the role that computer science plays into engineering (albeit aerospace or not) and I’ve adapted the attitude that to become a good engineer that deals with systems hardware, it would be good to also be able to understand that system’s software. And of course, there are the other factors too such as the fact that the brink of new technologies deals with computers and that this line of study is applicable to a seemingly unlimited number of industries.

Just, will I ever end up actually working on aerospace and computer science applications?

Will I end up eventually forgoing my aerospace engineering degree and end up sticking to software, or vice versa?

I know I have a lot of time to figure out where my specific interests are in computer science. I suppose my fear with taking up two (or more) disciplines is that I would end up becoming a jack-of-all-trades, master of nothing. And that would be kind of amusing and contradictory since I am pursuing a Master’s degree.

Let’s say you are given the expression,

To solve this you would go through 4 simple steps:

1. Change each of the numbers in the summation into binary
2. Map the binary numbers into a Karnaugh Map
3. Group the Karnaugh Map as necessary
4. Interpret the expression.

Change each of the numbers in the summation into binary. In order, this would give you:

0000, 0001, 0010, 0011, 0100, 0101, 0110, 1010, 1011

Map the binary numbers into a Karnaugh Map.

Group the Karnaugh Map as necessary.

Interpret the expression. Thus, the reduced boolean expression in sum-of-products form is

So, for example if you’re given 1D7A in hex and asked for representing -1D7A simply take its 2’s complement.

1. Convert to binary: 1D7A = 0001 1101 0111 1010
2. Flip the 1’s and 0’s: 1110 0010 1000 0101
3. Add 1: 1110 0010 1000 0101 + 1 = 1110 0010 1000 0110
4. Convert back to hex: E286

Therefore, the representation of -1D7A in hex is E286.

I’ve put together a bunch of screenshots I’ve taken from my TI-89 on the graphs of exponential functions, from y = x, y = x^2, …, y = x^10. The important thing to take from it is that when remembering how these functions look like:

• y = x is a line
• even exponents yield parabolas
• odd exponents yield cubic curves (“squigglies”)

This is very trivial knowledge, but I’m putting this up because graphs of functions tend to be one of those things that once learned, people toss aside by relying on their graphing calculators can do. And knowing this off-hand is good general knowledge, really. (I.e., determining if a function is injective or surjective without breaking a sweat.)

I don’t intend on making posts under the category “The Toolbox” in-depth, as I want them to be short and to the point. Of course, if there’s anyone out there in teh internets who’d like me to elaborate more on certain topics I’d certainly be willing to help.

Of course, they’ll been plenty of posts on my other endeavors in music and art, but hey — an engineer needs to have their own toolbox of sorts.

I’m aware that making the computer game is a method for us to learn the principles of Software Engineering, but nonetheless I find the project to be exciting. Quite some time ago (Jan 09),  during a layover for a flight, I made an outline of goals for myself to do. It wasn’t a set of goals that actually hit the ground running since I always seemed to find myself tired when I was coming home from work then, though I did accomplish a few things here and there of what I listed out.

My software engineering project is under the constraints of time, I’m fully aware that one semester of a mere four months is not enough time to create the-most-super-awesomely-advanced-indie-student-game-ever. But, it’s certainly enough time to learn the principles of what I’ve been wanting to learn — game development, Python and more importantly, software engineering — altogether.

This will be a good semester.

1. If Superman were able and willing to prevent evil, he would do so.
2. If Superman were unable to to prevent evil, he would be impotent.
3. If he were unwilling to prevent evil, he would be malevolent.
4. Superman does not prevent evil.
5. If Superman exists, then he is neither impotent or malevolent.

Let:

a = “Superman exists”
b = “Superman is able to prevent evil”
c = “Superman is willing to prevent evil”
d = “Superman would do so”
e = “Superman is impotent”
f = “Superman is malevolent”

Therefore, we can rewrite the hypothesis as follows:

Now we can come up with the conclusion that Superman doesn’t exist (not a)  using the Rules of Inference!

Note that Step #9 states that “If Superman exists, then he is neither impotent (not e) OR malevolent (not f)”. The above simplifies this statement to “If Superman exists, then he is not malevolent (not f)” in Step #10.

Step #10 can also be simplified by saying “If Superman exists, then he is not impotent (not e)”, and still reach the same conclusion — that he doesn’t exist (not a).