Design

Thursday, March 15, 2012

ABC and The Birth of Python

As I have mentioned in a previous post, I am very interested in the how and why of programming, which includes the history of different languages. One of the posters at PyCon 2012 held in Santa Clara over the past week was about the programming language ABC. There is a Youtube video that is unfortunately edited poorly and has the microphones off during the most important part of the interview here.

Guido van Rossum is often called "The Father of Python" because of his critical involvement in the development of the language. He wanted programming to be more intuitive, easier to learn, written in true English, and available to everyone. However, he did not start Python until ABC lost its funding. He also did not come up with all the basic principles on his own. Although he did work on the ABC project, he was not one of the original creators, nor is he attributed a large portion of the credit. Leo Geurts, Lambert Meertens, and Steven Pemberton are acknowledged as the leads on the ABC Project sponsored by CWI, Netherlands.

Like Python, ABC uses indentions (white space) to organize loops. ABC is also much easier to read than the programming languages of its time, BASIC, Pascal, and AWK. Tuples, lists, and strings were important in ABC, as they now are in Python. Tuples and indentations were actually utilized by SETL before they were used by ABC.

By looking at examples of SETL developed in the late 1960's, then examples of ABC from the 1980's, and finally modern Python, the progression of the structure and readability is apparent. Python is a beautiful language because of its intuitive design.

Wednesday, March 14, 2012

SICP Square Root Procedure

I haven't progressed much further in SICP. There have been so many interruptions. We traveled to Santa Clara for Pycon, where my husband, sontek, lead a tutorial on gevent, socketio, and realtime web (all things currently above my comprehension). Our son met Steve Holden, the chair of the Python Foundation, and many other developers known in the world of Python. I was hanging out in the lobby of the conference center one day so that I could see some of my husband despite the time involvement of the conference. Oddly enough, my SICP book got just as much attention as having a baby in a stroller and being female. I was more than the elephant in the room. I was a pink elephant wearing roller skates.

Continuing with SICP, I want to discuss the square root procedure example. It is excellent at demonstrating a lot of basic programming principles. Of course, Python has excellent math tools that make defining a procedure for square root unneccesary, but let's just do it for fun. First, we need to understand Newton's Method.

Let's pretend we did not know the square root of 9. We GUESS the answer is 2. But 2 squared is 4. So how do we get closer to the answer? We take the average of our GUESS and X, which is 9, divided by our most recent guess. The average would be 2.75 ( (9/2+2)/2 ). Now 2.75 becomes our new GUESS. We repeat, until guess squared is equal to 9, our x. So what does our code need to do?

make a guess -> square guess to check if good enough -> take the average of guess and x divided by guess if not good enough -> use computed average to improve guess -> square guess to check if good enough -> take the average...
An iterative procedure (repeating) until when?

Some numbers may take a very long time to solve exactly, or the square root may be a decimal with over 10 numbers beyond the decimal, so we also need to allow for some error. When we check if the square of the guess is equal to our x value, we can allow a difference less than .001, between the squared guess and the value of x, ending the iterations. We also need to define what our original guess will be. SICP uses 1.0, so let's try that. In both lisp and python, a number with a decimal allows floating numbers to be computed, while an integer without a decimal does not. Some of our definitions are modular, or reusable, so I'm going to give square, average, and abs their own definitions. I am ignoring the built-in absolute value, just so we can do more coding. I'm calling the absolute value definition abs2. I solve this problem in a different order than SICP, so I'm going to show my logic, in Python.

First, I wrote my code in Vim, so I could fix typos easily and experiment more quickly. In my terminal, I created sqrtsicp.py:

vim sqrtsicp.py

Our modular definitions mentioned previously are easy. Let's get them out of the way.
def square(x):
    return x*x

#naming absolute as abs2 to avoid built-in "abs"
def abs2(x):
    if x<0:
        return -x
   else:
        return x

def average(x,y):
   return (x+y)/2

Now for the hard part. We'll skip the first guess right now. The iterative part involves checking if our guess is good enough, then improving our guess if it is not good enough (good enough is false), only to try to determine if our improved guess is good enough.

def sqrt_iter(guess):
   if good_enough(guess):
       return guess
   else:
       return sqrt_iter(improve(guess))

Next we define how we determine if good_enough is true and how to improve our guess. Both of these need to know the value of x to compute.

def good_enough(guess,x):
   return abs2(square(guess)-x)<.001

def improve(guess,x):
    return average(guess,x/guess)

Now we have two problems. One, the x is being used for good_enough() and improve() without receiving the value of x from sqrt_iter(). Second, we need a starting guess. This is the point where I put good_enough(), improve() and sqrt_iter() all together and give it an initial guess. Our variable x is a constant and can be passed in from the overall procedure sqrt().
def sqrt(x):
    def good_enough(guess):
         return abs2(square(guess)-x)<.001
    def improve(guess):
         return average(guess,x/guess)  
    def sqrt_iter(guess):      
         if good_enough(guess):          
             return guess
         else:
             return sqrt_iter(improve(guess))
     return sqrt_iter(1.0)

It's good structuring to have all your definitions before your actions. The final line is the return function that causes the dominos to fall. sqrt_iter() calls itself on the new guess if our latest guess was not good enough. "Calling itself" is known as recursion. Now just make it a program. Within my file, I define the main procedure (not sure of the programmers vernacular)where my program is going to ask what to take the square root of. I want the input to be any positive number, including decimals. I want to use exception handling to ask for a floating number if the user inputs a string. I'm also going to define the decimal places for the output of the square root procedure to 3 digits past the decimal. If a negative number is entered, I ask for a positive number and attempt the program again. If a string is entered, I say "Oops, that's not a number" before calling the program again.

def main():
    try:
        x=float(raw_input("What number do you want to find the square root of? "))
        answer = sqrt(x)
        print("The answer is \n%.3f") %answer
    except:
        print("Oops, that is not a number")
        main()

if __name__=="__main__":
    main()

Those three pieces combined are a completed program. In my terminal, I can run it by typing:
python sqrtsicp.py

Playing with it, I attempt to find the square root of -9, 874, .04, and L. All my results are what I expect. This may be a good candidate for selenium testing or a unit test in more complicated programs. For another example of exception handling, view my Caesar's Shift. For more information of float from wikipedia, read this article. You can also refresh your math tools knowledge, including absolute value here.

Friday, March 9, 2012

Applicative Order Versus Normal Order Interpreter

How would you solve for c in the following problem? Ignore computer programming languages for just a minute.
b=(a+2)*(a+1) c=a*b a=3
Choice 1:
c=(3)*(3+2)*(3+1)
c=3*5*4
c=60
Choice 2:
c= (3)*((3+2)*(3+1))
c=(3)*(5*4)
c=(3)*(20)
c=60

They look very similar and yield the same result, however they act differently. In choice 1, the numbers are substituted and evaluated at the end. In Choice 2, the intermediate step (solving for b) is completed before evaluating for c. Choice 2 is applicative order, or strict evaluation. Choice 1 is normal order, also known as lazy evaluation because it only calls what is needed. The Lisp interpreter acts like Choice 2.

Knowing that lisp is applicative-order, we can now theorize the results of the somewhat famous Ben Bitdiddle Test, exercise 1.5 in SICP.I attempted to predict the outcome yesterday when I did not have access to my computer. I'm still bitter about it. First is the example written in lisp. Second is the test translated into Python. Do you think lisp and python act the same? What will they do when tested?
(define (p) (p))
(define (test x y)
(if (= x 0)
0
y))

(test 0 (p))
Or in Python
def p():
return p()

def test(x, y):
return 0 if x==0 else y

test(0, p())

I spent about 45 minutes irritated, thinking there was no way lisp would return either 0 or y, because the p would be looping forever, I was able to get on a computer. I WAS RIGHT! Applicative order interpreters cannot evaluate the test, because they are too concerned with the definition of p. "Lazy" or normal order interpreters only apply the needed information, so they are able to return 0. According to this test, Python is also a strict interpreter, using applicative order like lisp. I expect the differences between normal order and applicative order will be relevant again in further reading of SICP.

Saturday, March 3, 2012

Getting Back Into It

It has been awhile since I have posted anything for two reasons. First, I got stuck. Python came easy for me, but programming requires much more than knowing one language. For that reason, I have decided to resume my learning with more elementary programming concepts. Some people learn by doing, but I learn by dissecting. I need to know how and why things work the way they do. Which programming languages came first? How does a program evaluate a complex math problem with variables? What are the strengths and weaknesses of each of the languages? What are interpreters and how do they work? How does code become a website? My second reason for my absence is that I had a baby. Now 8 months old, he is a little less demanding of my attention and energy than he was before he was capable of sitting up on his own.

I am currently reading Structure and Interpretation of Computer Programs. SICP and Little Schemer are used to teach generalized computer programming principles, utilizing the languages of LISP and Scheme for examples. Both books were created at MIT for computer programmers. Lisp is the second oldest programming language still in use. Reddit.com was written in Lisp before it was converted to Python. Unlike how Python is organized by white space, Lisp uses parenthesis. A ridiculous amount of parenthesis. I have not yet attempted to write code in Lisp, but I am anticipating customizing a VIM configuration for using only with Lisp will be beneficial. I am enjoying the conciseness and organization of Lisp, compared to Python. Below is an example of the same mathematical expression in the two languages.

Python
3 * a + 7 + b
Lisp
(+ (* 3 a) 7 b)

I'll be discussing any "Eureka" revelations here on the blog, though it may take me a couple weeks to get through SICP.