diff --git a/_episodes/01-numpy.md b/_episodes/01-numpy.md index 8ea599514..5d440ffc6 100644 --- a/_episodes/01-numpy.md +++ b/_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. diff --git a/_episodes/06-func.md b/_episodes/06-func.md index c07188a68..c18a1f0a8 100644 --- a/_episodes/06-func.md +++ b/_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) diff --git a/_episodes/08-defensive.md b/_episodes/08-defensive.md index 443a39969..d9d329a48 100644 --- a/_episodes/08-defensive.md +++ b/_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: diff --git a/_extras/discuss.md b/_extras/discuss.md index 1859429d6..9e3d2d094 100644 --- a/_extras/discuss.md +++ b/_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,18 +61,18 @@ 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, @@ -80,7 +80,7 @@ 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. diff --git a/fig/python-function.png b/fig/python-function.png new file mode 100644 index 000000000..509d27ce8 Binary files /dev/null and b/fig/python-function.png differ