Showing posts with label Chapter 2. Show all posts
Showing posts with label Chapter 2. Show all posts
Friday, September 18, 2009
Chapter 2 -- Page 81 -- Problems 2.2,2.3,2.4
The problems say to use a parameter called n. It probably makes more sense to use r or perhaps radius.
Chapter 2 -- Page 81 -- Problem 2.5
The equation given in this problem is missing constants. It should read:
16 arctan(1/5) - 4 arctan(1/239)
Wednesday, August 26, 2009
Chapter 2 -- Page 82 -- Problem 2.9
This problem may use a notation that is hard to follow. Basically what this approximation method does is use a previous "guess" to compute a "new guess" for the square root of a number called n. The previous is the kth and the next is the k+1st. We assume that the first guess (called the zeroith) is 1.
So, to compute the "next guess", we take 1/2 times the sum of the "previous guess" and n divided by the "previous guess". That new guess becomes the old guess on the next try. The number of tries is referred to as the number of terms.
So, to compute the "next guess", we take 1/2 times the sum of the "previous guess" and n divided by the "previous guess". That new guess becomes the old guess on the next try. The number of tries is referred to as the number of terms.
Chapter 2 -- Page 59 -- last line
Again, these initializations can simply be 1 and 2 since the division performed will automatically return floating point.
The correction should be made to lines 2 and 3 of Listing 2.4 as well.
The correction should be made to lines 2 and 3 of Listing 2.4 as well.
Chapter 2 -- Page 54 -- Problem 2.6
In this problem we are testing the archimedes function to see how many sides are required to get the same result as that provided by the math library (math.pi).
Instead of "How many repetitions..." the question should ask "How many sides..."
Also, the values may never be equal. When are they "close enough" to call them equal?
Instead of "How many repetitions..." the question should ask "How many sides..."
Also, the values may never be equal. When are they "close enough" to call them equal?
Chapter 2 -- Page 47 -- Second line and Session 2.1
This line of text refers to floating point division and states that it is necessary for one of the operands to be a floating point number. This is NOT necessary. Division ("single slash") in Python 3 is always assumed to be floating point. So 22/7 will yield the correct result.
22.0, 355.0, and 9801.0 can simply be 22, 355, and 9801 in Session 2.1
22.0, 355.0, and 9801.0 can simply be 22, 355, and 9801 in Session 2.1
Friday, February 20, 2009
Chapter 2 -- Page 52 -- Listing 2.2
This code, as it evolved in Section 2.4.1, is not wrong but it does have an unfortunate use of identifier names. The name sideS is meant to refer to the length of side S in the triangle shown. However, the parameter, sides, refers to the number of sides in the polygon being used for the approximation. Since Python is case sensitive, these are two different names. But they can easily be confused as seen in Line 12. It would certainly have been better to name the parameter something like numSides.
Thursday, January 29, 2009
Chapter 2 -- Page 78 -- Listing 2.6
The variable numdarts in line 5 and line 23 should be numDarts (camelcase).
Chapter 2 -- Page 75 -- Problem 2.38
This problem asks you to create a boolean function called inCircle that returns True if the point is in the circle, False otherwise. Unfortunately, there is a local variable in the montePi function already called inCircle. For clarity, use a different name for the boolean function...perhaps isInCircle or pointInCircle.
Subscribe to:
Posts (Atom)