'''The scientific method expressed in Python syntax.

There is a study that suggests "programmers use pseudo-code and pen and paper to
reduce the cognitive complexity of the programming task." (Rachel Bellamy,
article behind ACM-paywall.) And if you do a Google search on "pseudo-code," you
will find a lot of hits that echo this sentiment.

I agree with this sentiment. In fact, as a generalist, with knowledge in many 
areas of math, science, engineering, and programming, I would like to have a 
"common language" that I can use to express myself in any technical area. Is 
this possible? 

If it is, IMHO, Python may come closest to fitting the bill. It is an expressive
language at multiple levels.

(Of course this would not be a true statement for someone unfamiliar with 
Python. They would have the added cognitive complexity of figuring out the 
language's tokens, grammer, syntax, and idiom. And what is the purpose of a
"common language" if nobody else can understand you? It seems I may have the
burden of helping to make Python popular for such a usage.)

There are other approaches like MathCad, that try to preserve the two
dimensional nature of usual mathematical notation and various common symbology.
But I guess I am not tied to tradition just for its own sake.

In programming design, the key issue is not so much to reduce complexity -- but
to contain it. The ability of object-oriented languages to contain complexity
behind an interface IMHO explains the popularity of object oriented languages.
Python's object model is a very simple one and so would seem ideal to serve
as the basis of a general pupose pseudo-code.

Another issue almost as important is elegance. A pseudo-language has to be 
usable -- to allow complexity at a high and abstract level to be expressed in a
simple and efficient manner. 

Elegance can be styled by defining clear paradigm shifts at object interfaces.
Sometimes the pseudo-language itself has elegant ways of expressing commonly
encountered complexities. For example, NumPy's handling of arrays seems easy
to understand and simple to use. So once again Python suggests itself as a good
technical pseudo-language candidate. 

(BTW, these issues are the main reasons I have never found flow-charts or UML 
diagrams very useful for software design. Documenting the design maybe -- but 
not for creating it. Every UML document I have ever produced has always come
AFTER I have decided upon the software's design and fundamental algorithms. The
only other benefit to UML I have experienced is to brainstorm with peers at a 
whiteboard. And there I usually just start making up notation and being sloppy 
just to speed the creative process along.)

So as an example of using Python as a high-level, all-round technical pseudo-
code, consider the scientific method. My personal philosophical viewpoint is 
that the scientific method is not so much a search for objective truth about 
Nature as it is an iterative exercise in predictive computation about Nature. 
Can I express this very abstract notion simply and unambiguously in pseudo-code
using Python syntax?


# Everything always has a context. Here we presuppose the current level of
# scientific knowledge.
from ScientificKnowledge import Theory, Experiment

# One would think that the scientific method would just be part of
# ScientificKnowledge. But let's pretend it's not.
def scientific_method(theory_id, lab_id):
    '''Perform the scientific method.
    theory_id = theory name or identifier
    lab_id = identifier of place and people performing the method.
    # Every "lab" has their own view of any particular scientific theory:
    my_theories = Theory(lab_id)
    # Each lab has their own experimental capabilities:
    my_experiments = Experiment(lab_id)
    # Iteratively perform the method as long as relevant to increasing our
    # overall state of scientific knowledge and practical.
    while my_theories.relevant(theory_id):
        # What was my belief in the theory before defining and performing
        # the experiment?
        prior_belief = my_theories.belief_intensity(theory_id)
        # What experiment will test the theory optimally?
        # What will be the predicted result?
        experiment, prediction = my_theories.generate(
                theory_id, my_experiments)
        if experiment == None:
            return # testing theory no longer practical
        # Perform the experiment.    
        result = experiment.perform()
        # Determine if the results of the experiment were significant.
        # Considering all possible theories, how plausible was this result?
        plausibility = my_theories.plausibility(experiment, result)
        # How likely was this result?
        likelyhood = prediction.belief_intensity / plausibility
        # How does this experiment change my beliefs in this theory?
        posterior_belief = prior_belief * likelyhood
        # Update my theories to reflect this new knowledge:
        my_theories.abduction(experiment, result, posterior_belief)
# Note how the shortcomings become glaring. There is no IV&V. (I guess this
# could be remedied with a try statement. Unlike most other languages, Python
# style is to use exceptions for non-ideal workflow as well as "extreme"
# exceptions.) Also, there is no mechanism for publishing experimental results
# to others. All this is good since how to improve the description is obvious.

No comments:

Post a Comment