Showing posts with label data structures. Show all posts
Showing posts with label data structures. Show all posts

Saturday, February 18, 2012

#4 Feb 19

The week of the test...<Hitchcock scream + thunder and lightning>. Well, not so much - it was a pretty simple test if you've been following the material in class - and the best part was that most of it was a multiple-choice format which meant that we got the results in a day. I've always found the aftermath of a test to be more stressful than the test or its preparation, so I was quite happy.

This week we mostly covered different data structures, container classes and the cost of performing operations on those structures. But before I talk about that, there was one point made about using references instead of pointers which I really liked:
A reference always needs an l-value, so if you have a function that takes an argument by reference, mistakenly doing something like f(0) will cause a compiler error, but if you were taking the argument by pointer, then it would compile - but now you're dealing with that dark evil which has haunted programmers for centuries - the NULL pointer!

Back to data structures - the summary of all that was taught can be found in Prof. Downing's schedule here. Some interesting things in the discussion -

  • A Deque is a variation of ArrayList except that instead of being front-loaded, it is center-loaded. This means that the cost of insertion and removal becomes an amortized constant - way better than the O(n) it was for insertion into an ArrayList. 
  • Also, stacks and queues are backed up by sequential structures, but queues cannot be backed by vector since vector does not offer a push_front / pop_front functionality. (It's O(n) for front-access, but ~O(1) for back-access)
  • Similarly, priority_queues cannot be backed by lists since they need to implement heaps which need indexing capability. Also, it can't be modified in place since it doesn't return an l-value.

Also, this week we turned in project 2  - the Australian voting problem. The problem itself was quite easy - the unit tests took a very long time, since the problem input was quite cumbersome. Also, we did it as a pair programming exercise. The experience was a mixed bag - it's always better to have another pair of eyes on the code you do, but managing time to have compatible schedules so that we could program together was more of a challenge than the problem itself. This led to us tackling the problem quite late, which is something I dislike since I prefer finishing off assignments as soon as I possibly can.
I'm looking forward to see how the other projects go. In the meantime, do not be fooled into extending the XP philosophy into your shopping patterns (from xkcd.com):



Btw, did you realize that a third of the course is already complete!