I'm not entirely certain that I missed your point here. A good
example of a non-deterministic "program" is
Select the element of array A having the greatest value
But that's cheating! Or is it? I may not know which array element is
the largest, but of all the actions involving selection of a single
array element (at least) one will involve choosing the largest one,
so this is a perfectly good non-deterministic program (more than one
array element can have the same value). Of course, a "real" program
might be
Get the value of the first element and store it as X
Get the largest element of the array obtained by removing the first
element and store it as Y
If X >Y return X, otherwise return Y
That's a real (deterministic) algorithm. The point here, of course,
is that the non-determinism masks a recursive solution.
If I were going to implement the first solution, I might write a
function get(i) that gets the value of the ith element of A, then my
program would be something like
big = get(magic())
where magic() just happens to pick the right index for me (I don't
know how).
To draw a geometric analogy, get() is local and magic() is global. I
may not know about the global topology of the problem, but perhaps I
can put together pieces involving only local knowledge that somehow
fit together into a global solution. But, of course, my pieces don't
"know" how they will be used. More precisely *I* have to create
pieces that may be used in unpredictable ways, knowing full well that
I can't say in advance what will happen to them.
But is this non-determinism? A good question. What I've attempted to
do here is suggest that the more theoretical notion of non-
determinism does actually fit well with the more practical notion of
unpredictability.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."
-- Antoine de Saint-Exupery
On Jul 12, 2005, at 7:54 PM, Richard G. DAVIS wrote:
Well, the paraphrase is apt, but misses my fundamental point. You
raise an
important behavior of complex systems that leads into the subject of
"emergent properties"--a matter for beyond the scope of this
discussion.
The "master" program and the program developer do not know anything
about
the 'message' process. That process is fully, completely
hidden--encapsulated. Thus, reading the Master Program phrase that
invoked
another program does NOT tell the reader what will happen when the
invocation is acted upon by some final recipient program. The
invocation in
OOP is truly indeterminate, or at lease may be so. That is what
makes it
hard for me to discuss this with others. At best, the reader of an
OOP
Master program may develop a belief about what may happen, an
conjecture at
best. Consider an example--the effects of inheritance can not be
known by
the reader of a Master Program in an OOP system based on the invoking
phrase--the call is indeterminate.
Some notes:
Message paths can ramify, they are not restricted to single thread.
The message process is where inheritance rules are implemented.
Some message processing may be driven by things like: which
hardware capable
of acting on the message is least busy?
Because the message path can ramify, I prefer to speak about the
"message
switch" mechanism that mediates between Master Programs and invoked
programs. The term "message agent" comes into use here with a broader
semantic that message switch.
Regards,
Richard.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
