Sunday, February 12, 2012

2/6 - 2/10 CS373 Weekly Blog

Good morning, everybody!

Another week has passed in the realm of college; amazing how time can fly so fast.

This week in software engineering, we discussed several topics: memory allocations on the stack versus the heap, variables and how they're allocated and/or cached; conditional statements, arguments and whether or not they're mutable or not; and different implementations of summing up a container of elements either using an index or an iterator (and whether or not a given container is indexable or iterable).

Discussion about stacks and heaps were a review for me, considering I hadn't really talked about them in a long time (maybe two, three years ago even!).  I knew there was a certain limit to how many records a stack can hold, but I didn't know of a specific number.  I can't really think of a time that a program would need that many layers of stack records to perform a specific operation (unless, of course, it is an incredibly expensive, basic arithmetic function) that would either use more than 1000 stack frames or would cause it to overflow.  Maybe that could be just because I haven't experienced the real world with actual software people use that I'm clueless on this idea, but the idea baffles me.  With the heap, I can understand.  Many programs can use a 'heap' of memory (get it?) that may cause a lack of memory issue.  Again, I guess it'll be something that will be more significant later on in the future.  I know this problem is a significant issue when dealing with smaller devices, such as mobile phones (iPhone, Android, Windows Phone 7, etc).  Since memory is not as available than those in modern-day computers, it must be used wisely.  Memory allocation and release must happen when variables need to be garbage collected; otherwise, memory leaks occur, and this intensifies the lack of memory issue.  This is critical!

I never knew that variables were cached, at least to a certain range.  It's kind of peculiar what kind of ranges Java and Python have specified (Java: [-128, 127] and Python: [-6, 256]).  I guess I can kind of understand Java's range in binary terms (127 is 01111111, -128 is 10000000 with two's complements method).  I guess Python decided with that range based on how frequently that range of numbers gets used? Who knows.  Since this class, I also didn't know (or at least didn't realize it) that arrays were mutable and were passed by reference.  In the past, many professors would just say that all things in Java were passed by value (that is, their values were duplicated and sent to methods).  But arrays clearly seem to be the exception here.

We also had a great review and discussion about indexability and iterability (those aren't words in real life; just in the computer science world). As a refresher, indexability refers to those containers where items can be indexed; that is, they can be found by using a certain subindex/get method that can be processed in constant time.  There are containers that can do this, but in linear time; these aren't truly indexable because we are merely walking down the list to find our item.  Iterability refers to those containers that can be walked through but (usually) don't have an index/don't care to have an index.  Such examples can include Maps and and Sets.  These containers only care about what that value is rather than where the value is.  Other containers, such as arrays and ArrayLists, care about where the value is rather than what the value is.  We note that certain containers (ArrayLists, Lists, LinkedLists, etc) can also be iterated upon, but certain containers are better off being indexable (ArrayLists, Lists) and others, iterable (LinkedLists, Maps, Sets).

The PFD project has been an interesting one in using Python.  I still get into the habit of using brackets to denote functions or loops; it's weird how everything is strictly bound by whitespace.  Also, I have to get into the habit of knowing that for loops do not exist in Python.  It's sort of inconvenient, but messier code (perhaps more elegant code when refactoring what to do) can be used to accomplish the same sort of thing.  More on the project will come next week!

Until then,

Corey

No comments:

Post a Comment