differences in executable vs. passive math notations

[kirby urner]

I'm recalling Kenneth Iverson's mantra, that math notations come in two flavors:  executable (machine-runnable) and not. [1] 

Naturally, we'd expect some in-betweens, so those would be the ends of a spectrum. 

A given presentation may contain a combination of runnable and not-runnable parts, or if we choose, we might say "not-runnable" might still be "brain runnable" i.e. meaningful to human readers. 

I don't dispute we have this choice.

The analogy with musical ensembles is clear:  machine recordings and playback devices mix with live performance and improv. 

Or maybe the show is entirely delivered by robots, as in a Disney exhibit (audio-animatronics)? 

Following the performance, appreciating its logic, depends on a mix of spontaneous delivery and automation, in most scenarios.

Along those lines, a hallmark of the non-executable math languages is they assign names to quantities in a meta language, usually in a prose of some kind, as in word / story problems. 

"Let x be the number of sheep in Farmer J's yard."  This is done to get the ball rolling, a gentleman's agreement of sorts (a lawyer thing, a contract) to just agree on some terms ("... let us use X and J to denote...").

In contrast, in executable languages (the ones robots might follow), the act of assignment is so deeply important that the equal sign (=) has actually been re-purposed in a lot of them, turned into an operator (!). 

Binding names to objects is so critical, so intrinsic to the math!

In Python for example, we have like post-its (like sticky paper, names thereon), and objects "on the heap" (picture a pile of broken jars or something -- better if not broken :-D).   When I go...

X = 3

...I'm at that moment in time (when this statement "runs") affixing a post-it with the letter 'X' on it, a legal "name", to some "object in memory" which we also name 3, literally (but somewhat confusingly, as 3 = X is disallowed).

It's a little as if we as gods (seeing from above), actually have two names for some Platonic invisibility:  both X (the new name) and 3.  Both refer back to the "meaning" of the symbol "3" (don't get me started on how I disagree with that mental model.... Wittgenstein and blah blah).

In any case, as far as Python is concerned, X = 3 is providing us with future use of X like a "remote controller" (picture a TV remote) of some object (3) on the heap.

X is the name whereby the object may be made to do its tricks, whatever they may be. 

With TV remote X, you go X.on (so-called "dot notation") to turn it on, and X.off to turn it off.  You can even go:  X.change_channel(n) although with integer objects that's not an option.  Different types come with different abilities.

To reiterate:

this_remote = TV( )  # <--- gives birth to a new TV object and name it 

Calling the type (or class) triggers the birth of an instance.  TV is the "Platonic factory" (oxymoron?) for special case TVs (more breakable). 

number = int( )

is the same idea, with int being the mother of all ints (integers).  It's able to understand inputs from different bases e.g.  number = int("101001010", 2) or number = int("AFFF", 16). 330 and 45055 respectively (in base 10).

Again, in non-executable math notations, object creation and naming is not that big a deal as we handle it in English or Russian or Italian or whatever, before launching into our symbolic manipulations (our algorithmics, our algebra, applying whatever laws of equality or other "magic" to "solve for X" or whatever the objective).

But in executable languages, naming is an operation within the math notation itself, of primordial importance, that cannot be left to some "English" or other set of human constructs. 

Running in computer memory (an energetic act) the executable math notatation ("MN" -- Iverson) must take care of naming as a mechanical act, an act no less primordial than addition or subtraction, or string concatenation.

*   *   *

Which brings me to a segue to another topic, for another time:  another hallmark of the computer maths is they take string manipulation as seriously or more so than number crunching. 

Those coming from an arithmetic background (typical in K-12 US), are surprised to discover that computers are so much more "word processy" than "number crunchy", because computer math has from the beginning always worked with strings (in the sense of letters, not "string theory" strings). 

That emphasis on string operations, treating "A" as an equal to 3 as a "math primitive" is a kind of culture shock for K-12 US math teachers, so groomed to think of math as arithmetic, as number based (much as our segments on functions as a set theory concept suggest this emphasis is unnecessary).

To have to see "regular expressions" i.e. "pattern matchers" (regexps) as "mathematics" is like future shock or something to some faculties.  Good thing no one has to treat them that way or go to jail i.e. it's not "the law" to treat them that way, just a best practice by some standards. 

No lawyers need involve themselves in these matters of STEM terminology as of course regexes, whatever they are, are part of STEM, regardless of how trivially we care to pigeon-hole. 

If we're serious about STEM, we'll teach them, and not just to code schoolers.  SQL too. 

It's about "how things work" and therefore important to generic literacy.  Call it math or don't, but don't expect other schools to play dumb either way.

Students will be getting into good code schools and snagging good jobs on the basis of their regex skills (in addition, not entirely), not just for their basic algebra or calculus knowledge. 

In some states, we'll say that's because they're "better at math" whereas in other states we'll expect some different taxonomy, i.e. they'll say "discrete math" is really "computer science".  Stay tuned.

Kirby

[1]  actually that's not quite what he says, but then lets remember all the Mathematica literature explaining how typography is too ambiguous and context-dependent to satisfy the needs of machine learning.  In typography we may create the convention that ABC is three numbers multiplied, A B and C, because all names are one letter and multiplication is implied.  But in a computer language, one doesn't undertake to obey such a loose dependence on legal agreements.  Consistency is more important.  If multiplication is intended, use the operator.  If naming is meant, use assignment etc.  Shortcuts for convenience are not so cavalier though "syntactic sugar" remains a possibility.  http://www.jsoftware.com/papers/camn.htm

[Christian Baune]

Hi,

It wouldn't be that hard to make a computer understand that "ABC" stands for "A*B*C"
when each variable is in his symbol table but "ABC" itself.

It is not done because human wouldn't be able to follow! It is a human limitation.

Some languages have inconsistencies because the original authors tough it would be "more natural" and "expressive".

And when you face those languages, you simply say NO. (COBOL)

These languages are easy to understand at first and quickly become your nightmare when you star to do advanced things.

Other languages like APL (http://tryapl.org/) are closer to a compact mathematical notation and is highly consistent.

These language are intimidating, with a steep learning curve and become easy when you start to do advanced things.

You have CAS also, like : http://mathstud.io/

And some use "standard" notation.

Here is a COBOL program (copied from http://www.csis.ul.ie/cobol/examples/Conditn/IterIf.htm)

      $ SET SOURCEFORMAT"FREE"
IDENTIFICATION DIVISION.
PROGRAM-ID.  Iteration-If.
AUTHOR.  Michael Coughlan.

DATA DIVISION.
WORKING-STORAGE SECTION.
01  Num1           PIC 9  VALUE ZEROS.
01  Num2           PIC 9  VALUE ZEROS.
01  Result         PIC 99 VALUE ZEROS.
01  Operator       PIC X  VALUE SPACE.

PROCEDURE DIVISION.
Calculator.
    PERFORM 3 TIMES
       DISPLAY "Enter First Number      : " WITH NO ADVANCING
       ACCEPT Num1
       DISPLAY "Enter Second Number     : " WITH NO ADVANCING
       ACCEPT Num2
       DISPLAY "Enter operator (+ or *) : " WITH NO ADVANCING
       ACCEPT Operator
       IF Operator = "+" THEN
          ADD Num1, Num2 GIVING Result
       END-IF
       IF Operator = "*" THEN
          MULTIPLY Num1 BY Num2 GIVING Result
       END-IF
       DISPLAY "Result is = ", Result
    END-PERFORM.
    STOP RUN.

Admittingly, this is very "prosodic" :-)

One line is even a full English sentece : "MULTIPLY Num1 BY Num2 GIVING Result"

With the rise of GAI, what is today called "non executable maths" will be executable. We constantly say "we can't" or "that's the bound"
and later we admit that we didn't had the perspective required, that we hasted to conclusions.

I am not telling something very new, people did before me : http://www.pcworld.com/article/2044181/computer-make-me-a-program-researchers-find-a-way-to-code-using-plain-english.html

And conversational computing try to exist since decades.

So, the "non executable mathematics" won't stay long!

Wolfram is a good example : 
https://www.wolframalpha.com/input/?i=volume+of+a+sphere+of+radius+3

https://www.wolframalpha.com/input/?i=product+of+the+ten+first+square 

This concept of "non executable maths" will surely die sooner than later :-p

So, GAI improve and knowledge about our own brain evolves too : http://phys.org/news/2015-12-brain.html

Kind regards,

Christian

--
You received this message because you are subscribed to the Google Groups "MathFuture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathfuture+...@googlegroups.com.
To post to this group, send email to mathf...@googlegroups.com.
Visit this group at https://groups.google.com/group/mathfuture.
For more options, visit https://groups.google.com/d/optout.