Update markdown references from relative SVG to PNG

_episodes/01-numpy.md

@@ -156,7 +156,7 @@ weight in kilograms is now: 57.5
 If we imagine the variable as a sticky note with a name written on it,
 assignment is like putting the sticky note on a particular value:
 
-![Variables as Sticky Notes](../fig/python-sticky-note-variables-01.svg)
+![Variables as Sticky Notes](../fig/python-sticky-note-variables-01.png)
 
 This means that assigning a value to one variable does *not* change the values of other variables.
 For example,
@@ -173,7 +173,7 @@ weight in kilograms: 57.5 and in pounds: 126.5
 ~~~
 {: .output}
 
-![Creating Another Variable](../fig/python-sticky-note-variables-02.svg)
+![Creating Another Variable](../fig/python-sticky-note-variables-02.png)
 
 and then change `weight_kg`:
 
@@ -188,7 +188,7 @@ weight in kilograms is now: 100.0 and weight in pounds is still: 126.5
 ~~~
 {: .output}
 
-![Updating a Variable](../fig/python-sticky-note-variables-03.svg)
+![Updating a Variable](../fig/python-sticky-note-variables-03.png)
 
 Since `weight_lb` doesn't "remember" where its value came from,
 it isn't automatically updated when `weight_kg` changes.

_episodes/06-func.md

@@ -50,7 +50,7 @@ def fahr_to_kelvin(temp):
 ~~~
 {: .python}
 
-![The Blueprint for a Python Function](../fig/python-function.svg)
+![The Blueprint for a Python Function](../fig/python-function.png)
 
 <!--- see https://gist.github.com/wd15/2b4ffbe5ce0d0ddb8a5b to
 regenerate the above figure --->

_episodes/08-defensive.md

@@ -263,7 +263,7 @@ The range of each time series is represented as a pair of numbers,
 which are the time the interval started and ended.
 The output is the largest range that they all include:
 
-![Overlapping Ranges](../fig/python-overlapping-ranges.svg)
+![Overlapping Ranges](../fig/python-overlapping-ranges.png)
 
 Most novice programmers would solve this problem like this:
 

_extras/discuss.md

@@ -33,7 +33,7 @@ final = fahr_to_celsius(original)
 
 The diagram below shows what memory looks like after the first line has been executed:
 
-![Call Stack (Initial State)](../fig/python-call-stack-01.svg)
+![Call Stack (Initial State)](../fig/python-call-stack-01.png)
 
 When we call `fahr_to_celsius`,
 Python *doesn't* create the variable `temp` right away.
@@ -43,12 +43,12 @@ to keep track of the variables defined by `fahr_to_kelvin`.
 Initially,
 this stack frame only holds the value of `temp`:
 
-![Call Stack Immediately After First Function Call](../fig/python-call-stack-02.svg)
+![Call Stack Immediately After First Function Call](../fig/python-call-stack-02.png)
 
 When we call `fahr_to_kelvin` inside `fahr_to_celsius`,
 Python creates another stack frame to hold `fahr_to_kelvin`'s variables:
 
-![Call Stack During First Nested Function Call](../fig/python-call-stack-03.svg)
+![Call Stack During First Nested Function Call](../fig/python-call-stack-03.png)
 
 It does this because there are now two variables in play called `temp`:
 the parameter to `fahr_to_celsius`,
@@ -61,26 +61,26 @@ When the call to `fahr_to_kelvin` returns a value,
 Python throws away `fahr_to_kelvin`'s stack frame
 and creates a new variable in the stack frame for `fahr_to_celsius` to hold the temperature in Kelvin:
 
-![Call Stack After Return From First Nested Function Call](../fig/python-call-stack-04.svg)
+![Call Stack After Return From First Nested Function Call](../fig/python-call-stack-04.png)
 
 It then calls `kelvin_to_celsius`,
 which means it creates a stack frame to hold that function's variables:
 
-![Call Stack During Call to Second Nested Function](../fig/python-call-stack-05.svg)
+![Call Stack During Call to Second Nested Function](../fig/python-call-stack-05.png)
 
 Once again,
 Python throws away that stack frame when `kelvin_to_celsius` is done
 and creates the variable `result` in the stack frame for `fahr_to_celsius`:
 
-![Call Stack After Second Nested Function Returns](../fig/python-call-stack-06.svg)
+![Call Stack After Second Nested Function Returns](../fig/python-call-stack-06.png)
 
 Finally,
 when `fahr_to_celsius` is done,
 Python throws away *its* stack frame
 and puts its result in a new variable called `final`
 that lives in the stack frame we started with:
 
-![Call Stack After All Functions Have Finished](../fig/python-call-stack-07.svg)
+![Call Stack After All Functions Have Finished](../fig/python-call-stack-07.png)
 
 This final stack frame is always there;
 it holds the variables we defined outside the functions in our code.