Clarity vs. code reuse/generality

[wwwayne]

On Fri, 03 Jul 2009 14:34:58 GMT, Alan G Isaac <alan.isaac at gmail.com>
wrote:

>On 7/3/2009 10:05 AM kj apparently wrote:

=== 8< ===

>2.
>from scipy.optimize import bisect
>def _binary_search(lo, hi, func, target, epsilon):
>    def f(x): return func(x) - target
>    return bisect(f, lo, high, xtol=epsilon)
>
>3. If you don't want to use SciPy (why?), have them
>implement http://en.wikipedia.org/wiki/Bisection_method#Pseudo-code
>to produce their own `bisect` function.

Of course this isn't really pseudo-code, it's VB code with quite poor
comments: 

    'Bisection Method
 
   'Start loop
    Do While (abs(right - left) > 2*epsilon)
 
      'Calculate midpoint of domain
      midpoint = (right + left) / 2
 
      'Find f(midpoint)
      If ((f(left) * f(midpoint)) > 0) Then
        'Throw away left half
        left = midpoint
      Else
        'Throw away right half
        right = midpoint
      End If
    Loop
    Return (right + left) / 2

and even just throwing away the VB code and leaving the comments does
not give a good algorithm:

    'Bisection Method
 
    'Start loop
 
      'Calculate midpoint of domain
 
      'Find f(midpoint)

        'Throw away left half

        'Throw away right half

A much  better approach to teaching introductory programming in any
language at almost any level is to incorporate some "top down problem
solving", including writing a method of solution (algorithm) in some
reasonably well-defined pseudo-code that can be easily elaborated and
translated into one's target language (and, peferably, some
reasonable-sized subset of related languages). This pseudo-code should
then become comments (or equivalent) for the students to convert to
real code, as in:

Algorithm bisect (f, left, right, epsilon):

# Bisection Method to find a root of a real continuous function f(x):
#    Assume f(x) changes sign between f(left) and f(right) and
#       we want a value not further than epsilon from a real root.
#    Begin with the domain left...right.

# While the absolute value of (left - right) exceeds 2*epsilon:

	# Calculate the midpoint, mid,  of the domain.

	# If the product of f(left) and f(mid) is positive:

		# Set left to mid;

	# Otherwise:

		# Set right to mid.

# Return the midpoint of left...right.

===
And adapting this approach to kj's case is straightforward.

Of course, what consitutes a suitable vocabulary and syntax for an
algorithm pseudo-code language depends upon the target language(s),
the tastes of the instructor, and the point in the lesson or course.
My choice is for python+COBOL (as above) initially, soon incorporating
the usual arithmetic and relational operators (and how soon and how
many at once depends upon the level of the students: for an
introductory university/college course in Computer Science or
equivalent, where everyone should have a reasonable background in
mathemtics notation as a prerequisite, this should be very soon and
quite fast), arrays and subscripting, etc.

But if we were to write this algorithm or kj's in python-like
pseudo-code it would already *be* python codeor very close to
it--which is why we should teach intorductory programming in python.
Very soon students would be writing algorithms that required very
little elaboration to be programs.

But without including suitable problem solving and psudo-code
algorithm writing there will soon come a time or an example where
students are trying to think in code instead of in their natural
language and don't have the experience and repertoire to be able to do
that well.

I hope that's not too pedantic or AR?

wayne

>hth,
>Alan Isaac