ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] C and Ada

To: "Barker, Sean (UK)" <Sean.Barker@xxxxxxxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, 13 Nov 2007 15:27:01 -0500
Message-id: <473A0895.1070908@xxxxxxxx>

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)

<Prev in Thread] Current Thread [Next in Thread>