Saturday, October 26, 2013

While For Loops Run

While loops and for loops confuse me, because I don't really see any merit in using for loops. Here's what my teacher, Mr. Stephen (pseudonym), says about the for and while loops. "You use a for loop when you know how many times your program will run ahead of time, and you use the while loop when you have no idea how many times your program needs to run" [citation needed]. Of course, this is also the teacher who encouraged me to "talk to Zolie (pseudonym)" [citation needed], so his advice might not be the most trustworthy. At first, Mr. Stephen's explanation seemed simple, but the more I thought about it, the less useful it seemed. Why not just establish a while loop with a condition that counted the number of times the loop had run? Mr. Stephen's rule now seemed unnecessary. I guess I'll just disobey him, always use while loops, and that'll be fine.

Since I need to fill up half a page, I'll just fill in this space by showing that I know what a for loop is. The syntax for a for loop goes something like this:

for(establish variable; create condition; increment variable)
{
      <insert what the loop does here>
}

This contrasts with a while loop, for which the syntax is:

while(condition)
{
       <insert what the loop does here>
}

The while loop is much cleaner and simpler, and for those reasons, I prefer it over the unwieldy and unnecessarily verbose "for" loop.

Sunday, September 29, 2013

Programming Lingo

It's tough to keep all these terms straight in my head. Apparently, a modifier statement is different from a constructor, which in turn is completely different from initialization constructor. Each one of these terms makes my head spin, and I can't tell them apart. I didn't think it was going to be much of a problem at first, but when the quiz rolled around, I realized how little I actually knew. For me, the largest problem was keeping everything straight in my head, and matching up the right terms to what I knew needed to be in each class. I finally figured out that the system works like this.

public class ClassName{
  <define instance variables>
  public ClassName(){ //default constructor
     <assign some default values to your instance variables>
  }
  public void setInstanceVariable(variable){ //modifier method
     instancevariable = variable;
  }
  public <instancevariable datatype> getInstanceVariable(){ //accessor method
     return variable;
  }
  public toString toString(){ //toString method
    return ""+ variable;
  }
}

Sorry if the post was dry, but i needed to make sure I could write out the concepts for my own use, and so that I could map out what every class should look like. I think the way I learned to identify each component was to think about what each part did in the structure of the class, and to learn the function of each method. For example, the accessor method is a "get______" because it accesses and grabs that variable's value for the user. That helped me spatially place each method in it's place and associate the name with the method. Thanks for reading!

Sunday, September 15, 2013

Thirty Two into Sixty Four?

This unit in class, we learned about bits. How certain variables require certain amounts of space, and how bits quantify that amount of space. To most people in the classroom, those concepts seemed intuitive. Everyone nodded their head along with the presentation, and no one asked any clarifying questions. I however, was clueless. I had no idea how why mod existed. So I stumbled through the first problems of the worksheet, trying to sort things out in my head, and to make some sense out of the conflicting rules in my head. "Why could a int fit into double, but not double into int." I knew what the answers were, but it was only through a knowledge of other examples. I didn't have a rule that would help me actually understand why concepts were the way they were. I ended up scribbling some answers down (I know no one else does this), and praying that some of them were correct. If someone had asked me why I had answered what I did, I honestly would not have been able to defend my answers.

When I got the paper back, I was relieved to see that only three or four problems were marked incorrect. Mostly, I had missed the questions that had required casting. When Mr. Stephen (fake named used for anonymity) walked past with our worksheets, I asked him questions (these questions were relevant). He reexplained the box analogy, how a variable could store something, akin to a box, and how each variable was sized differently. That was why the data stored in a double (64 bit) variable couldn't fit into a int (32 bit) variable. The box example really made sense the second time around, and I appreciated the time time my teacher took to reexplain it.

To be honest, I think the best thing a student can do is to ask questions. It's a powerful tool to keep a student engaged with the lecture, and it often snatches extra knowledge for the student. All it takes is the courage to ask. That's programming with panache.