Year View| Tuesday 27 April 2004 (Day View)

Sat 24 Apr | Sun 25 Apr | Mon 26 Apr |   Tue 27 Apr   Wed 28 Apr | Thu 29 Apr | Fri 30 Apr |

27.04.2004 – Tuesday 27 April – Chocolate, Visual Basic & Capped Results

Morning

• I was at uni before nine o’clock, attended both my lectures – where I may have learnt stuff but I can’t remember any of it if I did, and augmented my slide towards destitution by buying lunch at the main refectocide .

Evening

• After my lectures, I went down to the labs where I found out from the newsgroup that I was required to save my “Systems Interface Programming” clock’s state across different sessions, which initially sounded hard, but ended up being remarkably easy to implement in Visual Basic. After that, and commenting my code, I got the tutor to pass it (he made me tidy up my intentionally “as bad as possible” interface, which I could have argued against as there’s nothing in the specification that says it has to look good, but it only took about 10 seconds to do so I didn’t bother), submitted it, and was all finished – on the day it came out. This is a record for me.
  Clint and I then went for a walk down to Coles at the Ville, where I bought chocolate and apple juice. I was planning to go see my “Operating Systems” lecturer, and complain about my result, but after talking to Clint, and him saying it made sense to him, I didn’t. To me it doesn’t make sense. I received a bonus 5% for early submission, and had 15% subtracted for not maximising parallelism. I was also capped to 70% for using a cascading merge implementation. This resulted in a mark of 60%, which was upgraded to 70% when the cascading implementation cap was upped to 80%. It seems clear to me that my result was set to 70%, then 15% was subtracted and 5% added, to result in 60%. Then, when the cap was changed to 80%, my mark was changed to 80%, and the 10% was again subtracted, resulting in my current 70%. Regardless of whether this is a fair result for my assignment or not, I believe the method of working it out is wrong – that’s not how a cap should work – at least not that I’ve ever seen. My result should be calculated normally – and then capped to 80%. In this case, I would lose 15% for not maximising parallelism, giving me 85%, gain 5% for early submission, giving me 90% – and this would then be capped to 80% because I used a cascaded merge, giving me a result of 80%, not the 70% I have currently. I also find it somewhat contradictory losing marks for not maximising parallelism and using a cascading merge – isn’t that being penalised for the same thing (failing to exploit obvious opportunities for parallelism) twice? Clint, however, seemed to think it was reasonable to subtract marks from a pre-capped result, so perhaps he’s right.
  I was very tired on the train on the way home, and fell asleep several times.

Today’s Sets: Uncategorised