| Home | About | Subscribe | Search | Member Area |
Humanist Discussion Group, Vol. 34, No. 100.
Department of Digital Humanities, King's College London
Hosted by King's Digital Lab
www.dhhumanist.org
Submit to: humanist@dhhumanist.org
[1] From: C. M. Sperberg-McQueen
Subject: Re: [Humanist] 34.93: notation, software and mathematics (42)
[2] From: Bill Benzon
Subject: Software, mathematics, and the machine (106)
--[1]------------------------------------------------------------------------
Date: 2020-06-11 06:44:39+00:00
From: C. M. Sperberg-McQueen
Subject: Re: [Humanist] 34.93: notation, software and mathematics
> On 9,Jun2020, in Humanist 34.93, Peter Robinson wrote:
> …
> [In OCP] You could output (as I did) a concordance of the Merchant of Venice
> which located every word according to its speaker, scene and act AND
> according to the page of the edition.
Page numbers for the Merchant of Venice? A bit unconventional,
perhaps; one would expect no less from Peter. Most concordances to
Shakespeare only use play, act, scene, and line. I wonder why that is?
> You can (as Michael will tell you) indeed do the same with
> XQuery. But it is an order of magnitude more difficult in XQuery etc.
An interesting proposition. In a conventional TEI encoding of the play,
I would expect a reference to the current act number to take a form like
ancestor::tei:div[@type=‘act’]/@n
while a reference to the current page would take the form
preceding::tei:pb[1]/@n
In both cases, the expression has the form axis + name + predicate +
attribute reference. What measure of complexity would allow the
conclusion that the second expression is an order of magnitude more
complex than the first? I don’t see a ten-fold increase in complexity
here; what am I missing?
My heretical suggestion for the day is that facts are wonderful things
and can be used to test the truth of statements about how complex
things are to do in a particular programming language (or a given markup
language). I recommend them!
********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
--[2]------------------------------------------------------------------------
Date: 2020-06-10 13:56:23+00:00
From: Bill Benzon
Subject: Software, mathematics, and the machine
Fellow Humanists,
I've just come across (via Steven Strogatz on Twitter) and March 2008 paper by
Laszlo Lovasz that's relevant to our ongoing discussion of software,
mathematics, and the machine: Trends in Mathematics: How they could Change
Education? Here's the link:
https://web.cs.elte.hu/~lovasz/lisbon.pdf
I'm copying some paragraphs from section 5.1, Algorithms and programming.
> The traditional 2500 year old paradigm of mathematical research is defining
> notions, stating theorems and proving them. Perhaps less recognized, but almost
> this old, is algorithm design (think of the Euclidean Algorithm or Newton's
> Method). While different, these two ways of doing mathematics are strongly
> interconnected (see [6]). It is also obvious that computers have increased the
> visibility and respectability of algorithm design substantially.
>
>> Algorithmic mathematics (put into focus by computers, but existent and
> importantway before their development!) is not the antithesis of the
> 'theorem-proof' type classical mathematics, which we call here structural.
> Rather, it enriches several classical branches of mathematics with new insight,
> new kinds of problems, and new approaches to solve these. So: not algorithmic or
> structural mathematics, but algorithmic and structural mathematics!
So, we've got a distinction between algorithmic and structural mathematics.
[And remember, 'algorithm' is derived from the name of a mathematician,
al-Khwārizmī.]
Moving on:
> The beginning of learning 'algorithmics' is to learn to design, rather
> than execute, algorithms [8]. The euclidean algorithm, for example, is one that
> can be 'discovered' by students in class. In time, a collection of
> 'algorithm design problems' will arise (just as there are large collections
> of problems and exercises in algebraic identities, geometric constructions or
> elementary proofs in geometry). Along with these concrete algorithms,the
> students should get familiar with basic notions of the theory of algorithms:
> input-output, correctness and its proof, analysis of running time and space,
> etc.
Here, notice the distinction between designing algorithms and executing them.
And now we come to the computer:
> One should distinguish between an algorithm and its implementation as a
> computer program. The algorithm itself is a mathematical object; the program
> depends on the machine and/or on the programming language. It is of course
> necessary that the students see how an algorithm leads to a program that runs on
> a computer; but it is not necessary that every algorithm they learn about or
> they design be implemented. The situation is analogous to that of geometric
> constructions with ruler and compass: some constructions have to be carried out
> on paper, but for some more, it may be enough to give the mathematical solution
> (since the point is not to learn to draw but to provide afield of applications
> for a variety of geometric notions and results).
So, an algorithm is to be distinguished from its implementation. A given
algorithm could be implemented using a variety of programming languages, with
some being more hospitable than others. And the same is true for the underlying
hardware. In particular, some algorithms may benefit from a parallel
architecture, while others may not.
I present three more paragraphs without comment:
> Let me insert a warning about the shortcomings of algorithmic language. There
> is no generally accepted form of presenting an algorithm, even in the research
> literature (and as far as I see, computer science text books for secondary
> schools are even less standardized and often even more extravagant in handling
> this problem.) The practice ranges froman entirely informal description to
> programs in specific programming languages. There are good arguments in favor of
> both solutions; I am leaning towards informality, since I feel that
> implementation details often cover up the mathematical essence. For example, an
> algorithm may contain a step 'Select any element of set S'. In an
> implementation, we have to specify which element to choose, so this step
> necessarily becomes something like 'Select the first element of set S'. But
> there may be another algorithm, where it is important the we select the first
> element; turning both algorithms into programs hides this important detail. Or
> it may turn out that there is some advantage in selecting the last element of S.
> Giving an informal description leaves this option open, while turning the
> algorithm into a program forbids it.
>
> On the other hand, the main problem with the informal presentation of
> algorithms is that the 'running time' or 'number of steps' are difficult
> to define; this depends on the details of implementation, down to a level below
> the programming language; it depends on the data representation and data
> structures used.
>
> The route from the mathematical idea of an algorithm to a computer program is
> long. It takes the careful design of the algorithm; analysis and improvements
> of run-ning time and space requirements; selection of (sometimes mathematically
> very involved) data structures; and programming. In college, to follow this
> route is very instructive for the students. But even in secondary school
> mathematics, at least the mathematics andimplementation of an algorithm should
> be distinguished.
Bill Benzon
bbenzon@mindspring.com
917-717-9841
http://new-savanna.blogspot.com/
http://www.flickr.com/photos/stc4blues/
https://independent.academia.edu/BillBenzon
http://www.bergenarches.com
_______________________________________________
Unsubscribe at: http://dhhumanist.org/Restricted
List posts to: humanist@dhhumanist.org
List info and archives at at: http://dhhumanist.org
Listmember interface at: http://dhhumanist.org/Restricted/
Subscribe at: http://dhhumanist.org/membership_form.php
Editor: Willard McCarty (King's College London, U.K.; Western Sydney University, Australia)
Software designer: Malgosia Askanas (Mind-Crafts)
This site is maintained under a service level agreement by King's Digital Lab.