|
|
|
| Authored by: PolR on Sunday, September 02 2012 @ 12:24 PM EDT |
I would tend to agree. I didn't check lately, but based on memory the content of
these books is about how programmers should think mathematically about programs.
This is not the same as showing why the execution of a program is a mathematical
computation pursuant to an algorithm.
The part of software which is patented is its execution by the computer. The
activity and reasoning process of the programmer is not what is patented. So it
is important I think to keep the discussion focused on program execution.
[ Reply to This | Parent | # ]
|
| |
| Authored by: bprice on Monday, September 03 2012 @ 05:25 AM EDT |
I looked at a copy of Wirth online earlier today and at first
glance I did not see much to contradict
my position, but maybe I wasn't looking
hard enough. He has a lot about data structures, but his "algorithms" part is
largely confined to sorting algorithms. I will check again.
There's
an example of the problem with online vs dead-tree books: it's easy,
with physical pages to turn and leaf through, to see that only Chapter 2, pp
56..124, deals with Sorting, while subsequent chapters have to do with other
areas:
Chapter 3, Recursive Algorithms, pp 125..161;
Chapter 4,
Dynamic Information Structures, pp 162..279;
Chapter 5, Language Structures
and Compilers, pp 280..349.
The thickness of each chapter's set of pages is
quite visible in deadtree form, and useful in appreciating the work, whether
it's Wirth or any other book. I miss that visual cue.
One item that
impresses me about his Sorting chapter is that it covers the kinds of sorting
that we used for tape files, where memory does not suffice for the entirety of
the data. Wirth does not, however, deal with the radix sorting we used for
punched cards. He does come close to a punched-card algorithm I developed to
cut hours off one of my monthly tasks: instead of a 24-column alpha (radix) sort
on a sorter, use the new 1963-model high-speed collator to detect, flag and
merge existing runs in the card file until all cards are in a single
run.
Comparing the unit-record equipment, and the algorithms used there, with
early computers and then with later ones can be enlightening – it was for
me, anyway. Understanding that the nature of the algorithms did not change,
that changes in the underlying machine capabilities changed only the
engineering-level tradeoff decisions on which algorithms best fit the available
machinery, is my basic enlightenment about mathematics and mathematical
engineering (aka Computer Science).
Based on fifty years of experience, I
suggest starting with the EWD papers, rather than any of the books, however. (If
you don't want to use the link I dropped earlier, just Google EWD to find them.)
Another starting place would be the references in the Wikipedia entry for Edsger W Dijkstra.
In particular, "EWD
924: On a cultural gap" is a good attention-getter to some people. It covers
the same territory as the previous paragraph, but from the point of view of the
mathematicians and EEs involved in the original development of computers.
Another might be "EWD498: How
do we tell truths that might hurt?".
---
--Bill. NAL: question
the answers, especially mine. [ Reply to This | Parent | # ]
|
| |
| Authored by: bprice on Monday, September 03 2012 @ 06:31 AM EDT |
Many algorithms use maths and some are described using mathematical
notation. But I don't think that is the same as "software ==
maths"
My understanding, from years of study, observation, and
practice, is that all programs are written in a mathematical notation,
called a "programming language". This is independent of the purpose of the
computation the program is defining, which may also be mathematical in nature.
A program that solves a set of equations is mathematical in purpose; a program
that prints a file to a piece of paper probably does not have a mathematical
purpose. But that doesn't change the fact that each program is a mathematical
(e. g., algorithmic) exercise; in particular, it is an exercise in
mathematical engineering, the engineering of a mathematical (algorithmic!)
solution to some problem.
Let's look at an analogous situation in a
different field – a chemical plant.
The Chemical Engineer designs and
optimizes the reaction sequences, the feedstocks and environment for each
transformation in the sequence. He deals with chemistry.
The Mechanical
Engineer designs and optimizes the machinery that provides the feedstocks and
environment designed by the ChE. He deals with machinery.
The Electrical
Engineer designs and optimizes the power for the machinery. He deals with
electricity.
The Electronic and/or Hydraulic Engineer designs and
optimizes the controls for the machinery. He deals with electronics or
hydraulics, depending on the control technology most appropriate to the
processes.
The Structural Engineer designs and optimizes the supporting and
protective structures involved in the processes, assuring that everything is in
a proper three-dimensional location.
The Civil Engineer designs and
optimizes the roads and grounds upon which the structures reside.
The
Mathematical Engineer, if needed, designs and optimizes the algorithms for the
controls and monitors, should they have computers or other algorithmic
components.
Each engineering discipline involves the application of
mathematics, judgement, taste, and purpose to address some realm of
specialization, its subject matter, within the entire project. Each discipline
has a physical subject matter that defines its scope, except for only one: the
mathematical (software) engineer's subject matter is mathematical –
abstract – rather than physical.
Yes, as Michael (emmenjay) pointed out
earlier, mathematical (software) engineering involves more than mathematics in
its processes. Its subject matter, however, is strictly applied
mathematics.
That is why it's strictly true that software is (a discipline
of) mathematics.
---
--Bill. NAL: question the answers, especially
mine. [ Reply to This | Parent | # ]
|
|
|
|
|
