Skip to main content

Study, Day 7

Was on a roll.
Went and finished the whole geography textbook.
My brains are smoking now.

Next step, spaced repetition exercises of all the chapters for two months.

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

Did quite a bit of the course’s exercises. I realise now that I should have just downloaded the course from the Open Courseware site and worked on it at my own pace.
The MOOC is excellent, but not for me.
I keep missing all sorts of deadlines.
My life and the MOOC sadly do not get along.

Or maybe, I just do the MOOCs at my pace, knowing that there will be things I will miss, but as long as I get the learning (and I do the practice), I should be fine.

Did up to Week 4 of exercises.
Will tackle the rest next week.


French, Week 12

This was a boring week.
But I kept at it.
If I think, I have made progress, all I need to do is listen to a podcast.
And then I understand how far I still have to go.

Still at the stage where I am adding words to my basic vocabulary and doing review.
But there is steady, incremental progrgess.

Testing Nikola Native Code Highlighting

def foo(x, a): 
    """ 
    x: a positive integer argument 
    a: a positive integer argument returns an integer 
    """ 
    count = 0 
    while x >= a: 
        count += 1 
        x = x - a 
    return count


Well, there isn’t any for Lanyon, at least.
Will have to figure this out later.

Update: Chris Warrick graciously pointed out to me (in the Nikola IRC channel) that Nikola does indeed, support code highlighting via Pygments and that I just had to specify what program I was using along with my code backticks.

Like so, “ ```python ”

And here’s a shell script

#!/bin/sh # This is a comment! 
echo Hello World # This is a comment, too!

RIP, Rutger Hauer


I've, seen things, you people wouldn't believe.
Attack ships on fire, off the shoulder of Orion.
I watched C-beams, glitter in the dark near the Tannhäuser Gate.
All those, moments, will be lost, in time, like, tears, in rain.
Time, to die.

Blade Runner was the first movie I saw, that had a morally ambigous ‘hero’.
And the villain is not bad?
And he saves the hero?
This was the first movie that made me look at the world in shades of grey, in shades of acceptance.

And all that, because of the pitch perfect Roy Batty, speech.
Like Robert Caro writes,

There are sentences that are said to you in your life that are chiseled into your memory.

Tears in rain was the earliest of those for me.
Rest in peace, Rutger Hauer.
And thank you, for changing my life.

Study, Day 6

Did a little bit of french and geography.

MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

Doing compsci but no notes today, because i am busy learning.
Am going to have to revisit oop sometime again.
will make notes then

But to summarise,

  • i learnt oop
  • i learnt about generators,
    • which to me sounds like a tap on a loop.
    • instead of a bucket of water, i get it by the mug.
    • here’s a mug. here’s another mug. here’s another mug.
    • enough? then i can turn the spigot off
    • no need to fill the whole bucket (run through a whole dictionary, or carry out a huge operation) when I can just take however much I need.
  • i learnt about o notation to figure out how long code takes to run, if want to later optimise stuff
  • sorting lists with sorting algorithms
    • bubble sort
    • selection sort
    • merge sort efficient
  • i learnt how to plot using python

Have finished all the videos and will now move on to the problem sets.
I had so much fun, I actually was sad to watch Prof Grimson’s last video.
The course has given me a really good grounding on the basics.
And should help me start my journey.
While I understood the what, MIT 6.00.1x gave me a good grounding on the how and the why.

Study, Day 5

Did some geography for 12th in the morn.
Slow, steady, iterative progress there.


MITx, 6.00.1x, Introduction to Computer Science and Programming Using Python

exceptions & assertions

Exceptions

  • What happens when program execution comes across something that it did not expect?
    • like you could go beyond the bounds of a list
    • i try to reference a variable that isn’t there
    • i mix data types. (i dun dis :P 'a'/9)
  • This is basically Python telling me, ‘I don’t get this! Whatcha talkin’ bout Willis?’
  • Python has a whole host of errors, the names of kinda give me clues to what it thinks the problem is. There are
    • SyntaxError (I boo booed typing somewhere, Python does not ‘get’ me)
    • NameError (Can’t find a variable. Did I put it in? Did I call a module correctly?)
    • AttributeError (Errors with classes. Am I calling them wrong?)
    • TypeError (Am I doing string operations on numbers? Or vice versa?)
    • ValueError (Something is wrong with my results. Is it in a form the program understands?)
    • IOError (something that happens when i make boo boos with files)
What do I do with exceptions?
  • Fail silently (like fart silently and then look about innocently)
    • bad idea, though, really bad idea :)
  • Return a “error” value
    • make sure that you have code that can check for and handle the values you choose
    • makes code a little clunkier
  • Just stop execution, and signal an error condition
    • in Python that’s called raising an exception like so,
      raise Exception("Good God! You’re dividing letters with numbers?!")
Dealing with Exceptions. How do I handle them?
  • Use the try & except keywords.
  • As in you’re telling Python, ‘try’ this code. If everything works well, great!
  • But if there’s an error, jump to the ‘except’ clause, and execute what is in there
  • And then carry on with the rest of the program
  • I can then get fancy. I can have multiple except clauses.
    • one to handle typos
    • one to see if my input is valid
    • one to handle division isssue
    • and a final one as a catch all, if all else fails.
  • There is also an else that i can pair with a try
    • the else will execute code if try block it is associated works, with out any exceptions.
    • like ok, try this. all worked? then go that else block and do that thing and then carry on with the rest of the program
    • to my mind it kind of is the main program, because this is the part that always executes.
    • so as I iterate, i keep removing things from try and move them down to the mandatory else clause
  • And then there is finally
    • executed after try, except and else
    • even if they raise errors or cause a break
    • useful for cleaning up after a mess :P (close a file for e.g.)
    • like ok, here’s a booboo, but I better put everything back in it's place and undo stuff if I can
    • like do no harm.
Exceptions as control flow
  • turn the idea of exceptions on its head
  • instead of waiting for errors and catching them and then raising exceptions
  • we could check ourselves for expected values and raise our own exceptions if results don’t match expectations :)
    • like if i am unable to produce a result that is consistent with the specifications of a function
  • to do that we use raise
  • we raise exceptions
    • like raise iAmDisappointedinYouError("You should have written this better")
    • or more likely you want to raise an existing known error like raise TypeError("You need to enter a number! For the love of God, enter a number!")

Assertions

We can take the idea of proactive exception raising, to another level.
We can defensively program so that we prevent situations that lead to unexpected results.
This idea is what we call an Assertion

  • Remember those docstrings we typed where we expected a certain of inputs and guaranteed outputs?
  • you can think of assertions as the bouncers who enforce them
    • i assert that this should be true. if not, raise an exception
  • you can use the assert statement that in turn will raise an AssertionError if conditions aren’t met
    • could be on inputs (typically, mostly used here)
    • on an intermediate stage of the program
    • if i want to be really careful, i can use it to check output too
  • having these checks makes it a lot easier to locate the source of a bug
    • because if an assert fails, the bug most probably should be just before we called this function
  • Where should you use assertions?
    • so spot bugs as soon as they are introduced and clarify where they happen
    • as a supplement to testing
    • filter and check input
      • check types of arguments or values
      • check that invariants on data structures are met
      • constraints on return values are met
      • violation of constraints on procedure (no duplicates in a list, for e.g.)