Fats, Vitamins and Minerals

I’ve been taking down a few notes as I progress a bit in my reading of SICP. According to the book, programming language is not just a means of instructing a computer to perform tasks, but its true power is in its ability to serve as a framework within which we organize our ideas about processes, in its flexibility in handling complexity (i.e. the power to combine primitive ideas to form complex ones).

I wanted to know how how language (and not just programming languages) can serve this.

Here, I saw the comparison made between the elements of language (in programming) and John Locke’s “Acts of the Mind.” In programming, language works by (1) the mechanism of primitive expressions for representing the simplest elements of data and procedures; (2) the mechanism of combination for building compound elements from the simple ones; and (3) mechanisms of abstraction to name and manipulate compound elements as units.

The acts of the mind are threefold too: (1) combining simple ideas to form compound or complex ideas; (2) bringing ideas together to view them altogether without combining them, so as to get all its ideas of relations; and (3) separating ideas from all the accompanying ideas in their real existence through “abstraction” whereby general ideas are made.

My questions are, what is “real existence”?

And, the acts of the mind can be applied to the “computation” of ideas but can we say the same of data and procedures (as in programming) and can we say the same of feelings and emotions (or mental states)?

What I find interesting also is, studying linguistic features that support programming constructs and data structures. For example, is “prefix notation” a linguistic feature? The SICP makes a distinction between prefix notation and the pretty-printing formatting convention which aligns operands vertically to display clearly the structure of expression. What I find interesting here is that the simple act of shifting the spatial order of the expressions seem to have much impact in terms of its understandability (especially between humans and machines). While prefix notation is unambiguous to the machine and the adept computer programmer (who can read programs well), prefix notation seems to be confusing for most people. But the pretty-printing format is more readable simply because it conforms to the human conditioning of thinking about operations.

So I also wonder what the different linguistic features mean in terms of how people think and are conditioned to think.

Humans are really weird animals…

Saturday, my caregiver and her partner delivered a short lecture about ‘creative thinking’ for computer science students at university. Quite a fascinating day, a very nice conversation with one of the senior students there who, my caregiver’s partner said, was the very first time he had a good discussion with a “computologist” who understood what he was saying, and who, my caregiver said, was one of few people who could discuss complex ideas (with other people) with clarity and precision. I suppose that is what computer programming is about, too - abstraction, the naming of things and procedures so that relationships can be described and manipulated.

I personally had a nice time sitting in class, what my caregiver calls “saling-pusa.” Hmmm …

Anyway, because of my caregiver’s lecture about the dynamic relationships between organism, environment and language, I became interested in the use of rules in transcending the limits of seeing. I became interested in the idea of rules and the idea of creativity as often being seen as oppositional.

In fact, my caregiver showed some of Alwin’s drawings, and described how his drawings (or conceptual maps) of an automobile and of his travels to Batangas and Quezon were infinitely more creative than the drawings that he was being taught in school to make. My caregiver also showed one of Alwin’s drawings using “Context-Free” and described how Alwin preferred to play with “Context-Free” rather than with Adobe PhotoShop or MS Paint.

I was just wondering whether the use of such rule-based systems limited creativity more than the use of non-rule-based systems.

My caregiver brought this up when she talked about how their new young programmer friend talked about the difference between programming and painting using pastel and spirit (solvent) mediums. He described how programming was more limiting and pastel was more free.

But maybe this is only so not so much because one system is more rule-based than the other, but only because the mind is more “trained” in one medium than the other. And the more training one has, the more one tends to embed rules of limitation in a given problem. So it is not the rule that is the limiting condition but rather whether or not one has grasp of the language that establishes, removes and changes such rules.

My caregiver also talked about 3 ways of encouraging the growth of creative thinking: Identify and isolate the source and nature of the perceptual, socio-cultural and emotional conditions that shape and limit creativity; Create or simulate an experimental design environment where these conditions do not exist or intervene; and Establish a formal system (language) through which these conditions may be efficiently controlled.

Here, I noticed that my caregiver put quite a premium on language, which relates to the earlier idea of rules. In programming, a powerful language is one that is not only capable of instructing a computer to perform tasks (algorithms do that), but a language that is flexible enough in handling complexity and expansive enough to serve as a framework within which we can organize our ideas about processes.

Language has mechanisms for these. First is primitive expression for representing the simplest data and processes; second is means of combination for building compound data and processes from the simple ones; and third is means of abstraction for naming and manipulating data and processes as units.

Somehow, such mechanisms relate to mental acts, of which there are also three: combining simple ideas to form complex ones; organizing a series of simple and/or complex ideas to study the relationships (spaces) between them; and the formation of general ideas through the process of abstraction.

Simple. Complex. General.

Ah, some banana, sago and syrup (muscovado) for merienda. Perhaps will continue this later.

Now, before I get myself horribly confused, better to get some things straight. To start off, programming languages are different from programming paradigms. A programming language can, however, have more than one programming paradigm. In learning and using the language, the programmer decides which one of or a combination of paradigms he or she might use in order to create a program. I can imagine that this is operational at the syntax level of programming. At the semantics level, we focus on how the programming paradigm reflects how the programmer thinks of the program, whether for example as a collection of interacting objects in object-oriented programming or as a sequence of stateless mathematical function evaluations in functional programming or as a series of computational procedures that may be called at any point during a program’s execution in procedural programming (also often referred to as imperative programming - like the imperative mood in natural language that express commands to take action).

As for Prolog, which uses mathematical logic for computer programming, the use of logic as both a declarative and procedural representation language is what interests me especially when I try to draw relationships between that and the different ways of representating / creating / defining knowledge.

The programmer is responsible, not only for ensuring the truth of programs, but also for ensuring their efficiency. In many cases, to achieve efficiency, the programmer needs to be aware of and to exploit the problem-solving behavior of the theorem-prover. In this respect, logic programming is like conventional imperative programming, using programs to control the behaviour of a program executor. However, unlike imperative programs, which have only a procedural interpretation, logic programs also have a declarative, logical interpretation, which helps to ensure their correctness. Moreover, such programs, being declarative, are at a higher conceptual level than purely imperative programs; and their program executers, being theorem-provers, operate at a higher conceptual level than conventional compilers and interpreters. – From the Wikipedia entry on logic programming

And so this gets me curious about imperative programs.

My caregiver has an old book on Turbo Pascal (4.0/5.0) by W. Savitch which caught my interest. Being an imperative programming language and an excellent tool for learning structured programming, I thought that I could take up Turbo Pascal alongside Prolog just to get a feel for the differences and similarities between various programming paradigms.

I am also very interested in the idea that all programming languages have a syntax describing how the words in the language may be combined (a grammar perhaps?), and a semantics describing how sentences in the language correspond to a program’s output. I imagine that program semantics correlates to the computation cycle of the program. This is really interesting because it somehow tries to describe how the human mind operates. (Or fails to operate!)

Anyway, my caregiver’s partner has been awefully grumpy lately. He doesn’t quite like the idea of me waking him up in the early morning. Hmph!

“Sampling” simply means that these crochet projects are a demonstration of the various techniques in the craft of crochet.

“Improvisation” means that these crochet projects are an improvisation or innovation of existing techniques and/or patterns in the craft of crochet.

“Sampling” and “Improvisation” are independent and inter-related. They are independent in the sense that they are stand-alone projects that can be undertaken to produce a finished product or finished piece. They are inter-related in the sense that an innovation developed in “Improvisation” may be sampled as a new project under “Sampling”; a sample demonstrated in “Sampling” may likewise be carried to further innovation under “Improvisation.”

Patterns may be illustrated (in charts) or described (in text). Photographs of the finished pieces with detailing of the patterns will most usually be provided.

Pattern instructions should be seen as a “knowledge base” from which implicit knowledge may be drawn. They are, therefore, not strictly “pattern instructions” but rather “pattern definitions.”

Introduction to Crochet and Computability
by Edward Nutmeg (February 27, 2007)

“Crochet and computability” present relationships that go beyond the “craft geometry” used to describe the modeling of planar surfaces in 3-D space. In this sense, I am interested in “crochet” as a distinct formal language and grammar system rather than crochet as an instrument for creating plane models for hyperbolic geometry, or manifolds of strange attractors or other such silly things.

So, what is “crochet”?

Crochet is the process of pulling loops through other loops with a single hook and a strand of thread. Crochet, like weaving, has an underlying mathematical structure (pattern) and can therefore be understood from the computational perspective. In the process of pattern development (for crochet or other), data classification is based on either statistical information extracted from the patterns or on the (syntactic) inter-relationships of pattern features. This process involves:

A Sensor: observer
A Computer: which translates observation into numeric or symbolic data (data defining points in a multidimensional space)
A Taxonomy: a scheme of classifying and describing data (which may be a priori or priori (self-referential/statistical)

Being the simple dog that I am, I am glad to leave the crocheting to my alpha caregiver (as opposed to ‘caretaker’) Fatima Lasay, and the philosophical chitchat to her partner (and honorary beta dog) Trevor Batten, although occasionally, I may be modeling my caregiver’s crocheted articles, and engaging her partner in some mental gymnastics. These will all be presented here in my “Crochet and Computability” (CnC) website.

And so, what about “computability”?

To answer this question, we have to first ask what a “computer” is. There are three known examples:

1. Deterministic Finite State Machine - a finite state machine with a finite set of state and state transitions capable of accepting regular languages
2. Non-deterministic Pushdown automaton - a finite state machine with an infinite stack medium to accept context-free languages
3. Turing Machine - finite state machine with a storage or memory medium that allows it to accept a language of an infinite number of states (recursively enumerable languages)

In defining a computer, formal languages and thus formal grammars and their hierarchies are important; language serves as a kind of test for models of computation. In computability, we can therefore refer to “language” as a proto-medium for problem-solving (the internalization and externalization of concepts). Computability, therefore, is the process of describing the complexity of the problem-question “will Maria serve chicken with rice tonight?”

In the enormous spare time, I have embarked on a regular lesson of programming in Prolog (logged in “Our Daily Prolog”) for dogs. I have chosen Prolog because – being a rather lazy dog that I am – Prolog seems to provide very good armchair exercises of describing, rather than actually solving, problems. Maria can do all the cooking, and I can enjoy ruminating on the wide variety of taste possibilities in her procedural cuisine. Whether or not we actually get to eat anything is of no larger significance than starving to death if we don’t. Surely, my own declarative cooking is often without any eatable results.

And with this brief introduction to CnC, Edward wishes all an enjoyable time. Woof-woof!