<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Frank -</p>
<p>This is all up to the incremental differences between
SH/CSH/BASH/*SH for example of course. The (more) general
purpose language families such as those growing out of "C" for
example (I know little about "A" and "B" except that the preceded
"C" during a very short period of evolution/development). I
remember the *SH family being very explicitly backwards
compatible, but the *C* family being a little less so and the
F(ortran/IV/77/...) being even less so. <br>
</p>
<p>This may be a total red herring, but I know we have enough
computer-language wonks here that there are probably some who can
speak to whether this plays a role.</p>
<p>In the late 80s I was entangled in the "PostScript Wars" where
Apple's LaserWriter engine was treated as the de-facto reference
implementation for PS while IBM, Kodak and Xerox were each
building their own PS interpreters to front-end their high-speed
printer line which we were trying to integrate into LANL's
high-speed printing/film-recording ecology. We also had the NeXT
machine's software RIP as well as (later) Sun's NeWS/DisplayPS
software interpreters/renderers.</p>
<p>There were small but significant incompatibilities amongst those
variants and each development/commercialization team insisted
*their* version was the righteous one, dismissing the Adobe/Apple
one(s) as "flawed" against their own written standard. It was a
point of pride to implement the standard to precise spec even
though the practical "standard" Was the Adobe/Apple
implementation in the Laserwriters.</p>
<p>The differences were often as "trivial" as the precise method
used for line rasterization and dithering and the *artifacts*
generated. It was fair (though inconvenient) for a physicist who
might print out a page in their office at 300 dpi to then seek a
1200dpi print or a 35mm slide or a large format printer and expect
the rendering artifacts to be the same. As the guy that got the
call at 3AM when a 120ppm printer shut down every time a
particular PS file got fed to it, it was more than fair to ask the
providers of $200K printers to offer a "Laserwriter Compatibility
Mode" that interpreted and rendered to that de facto standard even
if it was "wrong".</p>
<p>As a counter-example, we ran film recorders whose "guts" were
built by Ed Fredkin's Information International company and were
built to the spec of Dec PDP-11 (I think 11?) and it was
anecdotally agreed among the user community (of a few thousand
delivered units in the world?) that these PDP-clones *never*
failed to execute the code identically to the machines they were
patterned after. I don't remember the details of implementation
of these 70's era hardware designs, but I understood that they III
designed their own PCBs but (obviously?) used the same CPU
chips... I don't know about all the other support components...
A likely answer to this pondering is that these machines did not
run a general purpose OS and the III software/system people
probably made up for any differences in Software/Timing/Error
Handling?<br>
</p>
<p>If Owen is listening in here, I think he was there for more than
a little of this from inside Apple/Sun?</p>
<p>- Steve <br>
</p>
<p>PS. To concede/confront glen's sentiment that: " 'Metaphor' is
an evil word, used only by manipulators and gaslighters", I
would offer that the use of *conceptual metaphor* is to thinking
as noise is to simulated annealing, and his point about "tighter
or looser equivalence" might well be the best argument *for* the
use of metaphorical thinking? I can't believe I'm
stirring/kicking this can of worm-hornets down the street again...<br>
</p>
<div class="moz-cite-prefix">On 10/20/22 6:19 PM, Frank Wimberly
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA5dAfpNMk_59uq-O-Gr2SqMR2BV1XqQC_pnn30mzSiLphBihA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Back in the 80s I wrote many Unix shell scripts.
For my purposes they ran identically on various workstations
whether Sun, SG, or, eventually, Vax (running Unix). The
software existed in my mind/brain, in files in the various
filesystems, or on paper listings. What's wrong with my
thinking?
<div dir="auto"><br>
</div>
<div dir="auto">Frank<br>
<br>
<div data-smartmail="gmail_signature" dir="auto">---<br>
Frank C. Wimberly<br>
140 Calle Ojo Feliz, <br>
Santa Fe, NM 87505<br>
<br>
505 670-9918<br>
Santa Fe, NM</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 20, 2022, 3:52 PM
glen <<a href="mailto:gepropella@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">gepropella@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I can't
speak for anyone else. I'm a simulationist. Everything I do is
in terms of analogy [⛧]. But there is no such thing as a fully
transparent or opaque box. And there is no such thing as
"software". All processes are executed by some material
mechanism. So if by "computational metaphor", you mean the
tossing out of the differences between any 2 machines
executing the same code, then I'm right there with you in
rejecting it. No 2 machines can execute the same (identical)
code. But if you define an analogy well, then you can replace
one machine with another machine, up to some similarity
criterion. Equivalence is defined by that similarity
criterion. By your use of the qualifier "merely" in "merely
the equivalent", I infer you think there's something *other*
than equivalence, something other than simulation. I reject
that. It's all equivalence, just some tighter and some looser.<br>
<br>
[⛧] Everyone's welcome to replace "analogy" with "metaphor" if
they so choose. But, to me, "metaphor" tends to wipe away or
purposefully ignore the pragmatics involved in distinguishing
any 2 members of an equivalence class. The literary concept of
"metaphor" has it right. It's a rhetorical, manipulative trick
to help us ignore actual difference, whereas "analogy" helps
us remember and account for differences and similarities.
"Metaphor" is an evil word, a crucial tool in the toolkit for
manipulators and gaslighters.<br>
<br>
<br>
On 10/20/22 13:27, Prof David West wrote:<br>
> <br>
> Marcus and glen (and others on occasion) have posted
frequently on the "algorithmic "equivalent" of [some feature]
of consciousness, human emotion, etc.<br>
> <br>
> I am always confronted with the question of of "how
equivalent?" I am almost certain that they are not saying
anything close to absolute equivalence - i.e., that the
brain/mind is executing the same algorithm albeit in, perhaps,
a different programming language. But, are their assertions
meant to be "analogous to," "a metaphor for," or some other
semi/pseudo equivalence?<br>
> <br>
> Perhaps all that is being said is we have two black boxes
into which we put the same inputs and arrive at the same
outputs. Voila! We expose the contents of one black box, an
algorithm executing on silicon. From that we conclude it does
not matter what is happening inside the other black
box—whatever it is, our, now, white box is an 'equivalent'.<br>
> <br>
> Put another way: If I have two objects, A and B, each
with an (ir)regular edge. in this case the irregular edge of A
is an inverse match to that of B—when put together there are
no gaps between the two edges. They "fit."<br>
> <br>
> Assume that A and B have some means to detect if they
"fit" together. I can think of algorithms that could determine
fit, a simplistic iteration across all points to see if there
was a gap between it and its neighbor, to some kind of
collision detection.<br>
> <br>
> Is it the case that whatever means used by A and B to
detect fit, it is _*/merely/*_ the equivalent of such an
algorithm?<br>
> <br>
> The roots of this question go back to my first two
published papers, in _AI Magazine_ (then the 'journal of
record' for AI research); one critical of the computational
metaphor, the second a set of alternative metaphors of mind.
An excerpt relevant to the above example of fit.<br>
> <br>
> /Tactilizing Processor<br>
> /<br>
> /Conrad draws his inspiration from the ability of an
enzyme to combine with a substrate on the basis of the
physical congruency of their respective shapes
(topography). This is a generalized version of the
lock-and-key mechanism as the hormone-receptor matching
discussed by Bergland. When the topographic shape of an
enzyme (hormone) matches that of a substrate
(receptor), a simple recognize- by-touch mechanism (like
two pieces of a puzzle fitting together) allows a
simple decision, binary state change, or process to
take place, hence the label “tactilizing processor.”/<br>
> <br>
> Hormones and enzymes, probably/possibly, lack the ability
to compute (execute algorithms), so, at most, the black box
equivalence might be used here.<br>
> <br>
> [BTW, tactilizing processors were built, but were
extremely slow (speed of chemical reactions) but had some
advantages derived from parallelism. Similar 'shape matching'
computation was explored in DNA computing as well.]<br>
> <br>
> My interest in the issue is the (naive) question about
how our understanding of mind/consciousness is fatally impeded
by putting all our research eggs into the simplistic
'algorithm box'?<br>
> <br>
> It seems to me that we have the CS/AI/ML equivalent of
the quantum physics world where everyone is told to "shut up
and compute" instead of actually trying to understand the
domain and the theory.<br>
> <br>
> davew<br>
<br>
-- <br>
ꙮ Mɥǝu ǝlǝdɥɐuʇs ɟᴉƃɥʇ' ʇɥǝ ƃɹɐss snɟɟǝɹs˙ ꙮ<br>
<br>
-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. ---
-.. .<br>
FRIAM Applied Complexity Group listserv<br>
Fridays 9a-12p Friday St. Johns Cafe / Thursdays 9a-12p
Zoom <a href="https://bit.ly/virtualfriam" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://bit.ly/virtualfriam</a><br>
to (un)subscribe <a
href="http://redfish.com/mailman/listinfo/friam_redfish.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://redfish.com/mailman/listinfo/friam_redfish.com</a><br>
FRIAM-COMIC <a href="http://friam-comic.blogspot.com/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">http://friam-comic.blogspot.com/</a><br>
archives: 5/2017 thru present <a
href="https://redfish.com/pipermail/friam_redfish.com/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://redfish.com/pipermail/friam_redfish.com/</a><br>
1/2003 thru 6/2021 <a
href="http://friam.383.s1.nabble.com/" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://friam.383.s1.nabble.com/</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">-. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
FRIAM Applied Complexity Group listserv
Fridays 9a-12p Friday St. Johns Cafe / Thursdays 9a-12p Zoom <a class="moz-txt-link-freetext" href="https://bit.ly/virtualfriam">https://bit.ly/virtualfriam</a>
to (un)subscribe <a class="moz-txt-link-freetext" href="http://redfish.com/mailman/listinfo/friam_redfish.com">http://redfish.com/mailman/listinfo/friam_redfish.com</a>
FRIAM-COMIC <a class="moz-txt-link-freetext" href="http://friam-comic.blogspot.com/">http://friam-comic.blogspot.com/</a>
archives: 5/2017 thru present <a class="moz-txt-link-freetext" href="https://redfish.com/pipermail/friam_redfish.com/">https://redfish.com/pipermail/friam_redfish.com/</a>
1/2003 thru 6/2021 <a class="moz-txt-link-freetext" href="http://friam.383.s1.nabble.com/">http://friam.383.s1.nabble.com/</a>
</pre>
</blockquote>
</body>
</html>