I wrote
>> A program is a design for a machine, a set of instructions
>> for assembling off-the-shelf parts into a machine that
>> performs some function. Therefore, the primary concern of
>> any programming language is to provide the ability to
>> formulate a precise set of instructions for the assembly of
>> useful machines. (01)
Sean wrote: (02)
> My perspective is that the aim of a programming language is to
> allow the human to express the problem in terms a human can understand,
> in order that they do not have to learn how to translate it into the
> assembly code that the machine understands. This job is constrained in
> two sorts of ways: firstly, the human needs to make the machine do what
> the machine can do, and secondly, if the machine can't do it, the
> translation process won't work. After that, the questions are about what
> level of complexity the translator can cope with.
>
> A symbolic assembler gives the ability to formulate a precise
> set of instructions. For portability, formula translation allowed
> programmers to use familiar arithmetic notation, while language
> implementers (compiler writers) sorted out the problem of converting the
> formulae into precise sets of assembly instructions. (03)
I think we are talking past each other. When I spoke of "precise
instructions", I wasn't thinking of assembly language as the archetype. (04)
Fortran, Ada and LISP are languages which give the programmer the
ability to precisely define the form of a machine that performs a
particular function. Functionally, the only difference between them and
assembly languages is the set of off-the-shelf components they offer the
programmer. Assembly languages offer only the hardware/firmware
components of some chip set, while these intermediate programming
languages offer some higher-level formalisms and a library of supporting
functions. Still higher-level languages, like ANSYS and Mathematica,
allow the programmer to formulate mathematical problems and provide
libraries of off-the-shelf solution techniques. But the idea of all
these languages is to allow the human to design/build a machine that
solves a particular problem. And they are all precise in their
specification of the machine to be assembled, but each supports
definition of a machine in terms of a different set of available
components. The set of components can be really primitive, as it was in
SAP in 1955 (or in C in 1974), or really powerful, as in MacLISP and
Mathematica, or somewhere between those, as in Ada. (05)
> Thus I would still assert that the primary aim of
> <i>languages</i> is for humans to understand what they want the machine
> to do, since there are other ways of getting the same result, but the
> primary <i>constraint</i> is that languages must translate into a
> precise set of instructions. (06)
I would say that the language has very little to do with the human
*understanding* what he wants the machine to do. It has everything to
do with his ability to formulate that understanding as the design of a
machine -- *how* that objective is to be achieved with a given set of
resources provided by the "language" (its compilers and libraries). (07)
My point was that the primary objective of writing a program is to
communicate the design to a machine capable of building a machine with
the function he wants. We generally speak of a "machine capable of
building a machine" as a "compiler". Since the objective is to achieve
communication of a design between a human and a "machine", the language
must be precise enough for the machine to get the intent right and
convenient enough for the human to find it relatively easy to express
his intent clearly. (08)
The world being what it is, the desired function of the new machine
tends to change over time, and it regularly becomes necessary to modify
the machine to meet the new/changed requirements. That is when the
ability of the language to provide communication with other people comes
into play. A different person is often called upon to create the
modified machine, and we don't want it to be cheaper, faster and more
reliable for him/her to start over. (09)
> Actually, the problem for languages is slightly harder than just
> formulating a precise set of instructions. What we want is that the
> program gives a precise result. Ideally, the same problem solved by two
> different computer systems should give the same result. (010)
I'm not sure what this means. In a famous example, the 1948 Berlin
airlift was a major logistics problem that was solved by professionals
with experience, seat-of-the-pants planning, and mechanical calculators.
Some 10 years later, an operations research study produced AN optimal
solution and found that it was less than 8% better than the implemented
solution. But both were "solutions" to the problem, and as any Ops
Research person knows, it is often the case that there is more than one
"optimal solution" to the same problem, that is, there may be two
significantly different solutions for which the cost/benefit values are
exactly the same or negligibly different. (011)
Most experts would say that sufficient precision in the program
specification should guarantee that a given machine or class of machine
produces a *repeatable* result. But there are algorithmic methods, e.g.
Monte Carlo sampling, that simply don't do that -- they deliberately
introduce randomness. (012)
> While this seems
> to be the case with the algorithmic languages, I'm told that the various
> logic solvers can give different results for the same set of inputs -
> say, an OWL file. I'm not sure why this is the case, but comments
> welcome. (013)
The problem is similar to the Mathematica one. You input a precise
characterization of the problem, but you don't directly specify the
approach to solution. The "compiler" then uses algorithms to determine
from the characteristics of your problem a probable path to a solution.
Different reasoning engines use different algorithms to find such a
path. And sometimes the probable path comes up empty, and they have to
try alternatives, and they typically have a point at which they stop
trying, because they no longer have a high probability of coming to any
conclusion. So the difference you observe is that one engine says the
statement is true (one of its choices of path worked) and another says
it cannot be determined (its first three hundred choices didn't). Even
when two reasoners both agree that it is true, their proofs may be
significantly different. (014)
The advantage of OWL is that there is a known method of determining
whether a statement is true, false, or undeterminable, and that method
will finish in a predictable length of time (which is dependent on the
overall size of the ontology the engine is reasoning from). BUT, not
all engines that accept OWL ontologies use that reasoning mechanism
internally, because there are MANY relatively simple ontologies on which
that mechanism does not work. (Those ontologies cannot be expressed in
OWL, but they can be expressed in other languages, and for most logic
engines, OWL was not their first language.) (015)
-Ed (016)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (017)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (018)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (019)
|