[FRIAM] naive question

Steve Smith sasmyth at swcp.com
Fri Oct 21 12:24:00 EDT 2022


Frank -

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.

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.

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.

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.

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".

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?

If Owen is listening in here, I think he was there for more than a 
little of this from inside Apple/Sun?

- Steve

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...

On 10/20/22 6:19 PM, Frank Wimberly wrote:
> 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?
>
> Frank
>
> ---
> Frank C. Wimberly
> 140 Calle Ojo Feliz,
> Santa Fe, NM 87505
>
> 505 670-9918
> Santa Fe, NM
>
> On Thu, Oct 20, 2022, 3:52 PM glen <gepropella at gmail.com> wrote:
>
>     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.
>
>     [⛧] 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.
>
>
>     On 10/20/22 13:27, Prof David West wrote:
>     >
>     > Marcus and glen (and others on occasion) have posted frequently
>     on the "algorithmic "equivalent" of [some feature] of
>     consciousness, human emotion, etc.
>     >
>     > 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?
>     >
>     > 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'.
>     >
>     > 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."
>     >
>     > 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.
>     >
>     > Is it the case that whatever means used by A and B to detect
>     fit, it is _*/merely/*_ the equivalent of such an algorithm?
>     >
>     > 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.
>     >
>     > /Tactilizing Processor
>     > /
>     > /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.”/
>     >
>     > Hormones and enzymes, probably/possibly, lack the ability to
>     compute (execute algorithms), so, at most, the black box
>     equivalence might be used here.
>     >
>     > [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.]
>     >
>     > 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'?
>     >
>     > 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.
>     >
>     > davew
>
>     -- 
>     ꙮ Mɥǝu ǝlǝdɥɐuʇs ɟᴉƃɥʇ' ʇɥǝ ƃɹɐss snɟɟǝɹs˙ ꙮ
>
>     -. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
>     FRIAM Applied Complexity Group listserv
>     Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoom
>     https://bit.ly/virtualfriam
>     to (un)subscribe http://redfish.com/mailman/listinfo/friam_redfish.com
>     FRIAM-COMIC http://friam-comic.blogspot.com/
>     archives:  5/2017 thru present
>     https://redfish.com/pipermail/friam_redfish.com/
>       1/2003 thru 6/2021 http://friam.383.s1.nabble.com/
>
>
> -. --- - / ...- .- .-.. .. -.. / -- --- .-. ... . / -.-. --- -.. .
> FRIAM Applied Complexity Group listserv
> Fridays 9a-12p Friday St. Johns Cafe   /   Thursdays 9a-12p Zoomhttps://bit.ly/virtualfriam
> to (un)subscribehttp://redfish.com/mailman/listinfo/friam_redfish.com
> FRIAM-COMIChttp://friam-comic.blogspot.com/
> archives:  5/2017 thru presenthttps://redfish.com/pipermail/friam_redfish.com/
>    1/2003 thru 6/2021http://friam.383.s1.nabble.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20221021/5fa3743e/attachment.html>


More information about the Friam mailing list