[Fwd: [Fwd: fallacy in Rosen's arguments is a straw man]]

Don Mikulecky (mikuleck@HSC.VCU.EDU)
Thu, 24 Jun 1999 13:02:09 -0400


This is a multi-part message in MIME format.
--------------F1BF49E4E1C5656006B5CF9A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

F.Y.I.

--------------F1BF49E4E1C5656006B5CF9A
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <3772505C.F05EB784@hsc.vcu.edu>
Date: Thu, 24 Jun 1999 11:35:56 -0400
From: Don Mikulecky <mikuleck@hsc.vcu.edu>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: NE Complex Systems Institute <NECSI@HOME.EASE.LSOFT.COM>
CC: w b dress <wbd@ornl.gov>
Subject: Re: [Fwd: fallacy in Rosen's arguments is a straw man]
References: <199906240329.UAA05158@proxy4.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The reason I said that this is a straw man resides not in the ability to
partition
hardware into software or not. It resides in the consequences of that on the
argument. I'm still not clear on which argument has been even touched by that
point.

Let's review the argument I am concerned with, which never brings the
hardware/software partition into play. First a definition which separates simple
mechanism or simple system from a complex (real) system. A simple system is one
which is compatible with ALL we care about being modeled successfully by the
Newtonian Paradigm on the right hand side of the modeling relation. As soon as
we
find ways of interacting with that system which are in need of a distinct (not
derivable from it) formalism, we have entered the realm of the complex. There
is a
list of parallel dichotomies which accompany this. They include: (yes or no
applies
to simple system, opposite to complex system)
1) Largest model-yes
2)simulatable-yes
3)capoable of being formalized(captured entirely by algorithms)-yes
4)analytic models=synthetic models -yes
5)causes seperable-yes
6)contains Russel's viscous circles, 'impredicativities" - no

there are more but I think you can see that Brian's and your discussion is in no
way
central to our thesis. Now what has come up in this is the way we talk about
the
computability issue. The purpose for the Turing machine argument, as an example
of
a "mathematical machine" which is a subclass of the "simple systems" in the
dichotomy above, is to spell out the problem with causality. The upshot of that
argument is that the machine is not closed to efficient cause. Again I ask how
does
yours or Brian's point influence that conclusion?

Now to go to the Turing machine itself. What is hardware? It is the device
which
reads the tape and punches the tape and advances it. What is software? it is
the
program on the tape. I see no ambiguity here as we define this abstract
machine.
Now, as I understand it you claim that because we can encode this all in another
tape on another machine it erases the distinction between hardware and software
on
this machine? Please explain this to me?

My real example to you on another post may help us get to the root. I can,
using
software on the machine I am now working on, SIMULATE an artificial neural
network.
In that SIMULATION will be a simulation of the hardware with which I can
actually
construct the ANN. Does that obscure for you the partition of hardware into
software?

Let's look at causality because that is the crux of Rosen's argument. He says
the
following in "Life Itself" page 193:
"Now comes the crucial observation. An algorithm, or a Turing machine's reading
head, constitutes HARDWARE (his emphasis). It thus constitutes the inferential
machinery that ENTAILS words from other words. The words themselves, on which
this
machinery operates, are SOFTWARE. In particular, the PROGRAM U is SOFTWARE.
The
simulation of a map G by a map F thus requires an expression of G, or a
description
of G, as software, as INPUT."

Let me pause to ask if these definitions do not accomodate your examples AT EACH
STAGE OF THE OPERATION and allthough they clearly distinguish hardware from
software
operationally at any stage, they allow for them to be operationally redefined at
any
other stage? Once again, I see this whole thing as a straw man!

I skip some..then he says: "But in simulation, the HARDWARE of the simulator
needs
to have nothing to do with the HARDWARE of what it simulates."
Is that not exactly what you are saying?
he goes on:
"In causal terms, simulation involves the conversion of efficient cause, the
hardware of that being simulated, into material cause in the simulator. In
essence
this means that one can learn nothing about entailment by looking at
simulation."

The section that Brian was misinterpreting refers back to this as its beginning.

I feel the equivalent of a "feeding frenzy" is going on right now and I'll do my
best to show that you are drawing no blood here. The story is not that fragile
and
it is a bit presumptuous that a work like Rosen's is that frail.

Your analogy about logic completely ignores the portrayal of this work i give
in
the review http://views.vcu.edu/~mikuleck/rosrev.html which explains that this
is
NOT that type of linear argument, but a mosaic or weave of intertwining
threads...much more like a parallel distributed process. Your model of a serial
machine failing if one link is broken is not even applicable here.

Now, just for the sake of fairness and civility, you chastise quite readily when
someone skips over part of a post of yours. I suggest that to believe you have
unravelled the newtwork ideas this very bright man wove in a lifetime with
something
as trivial as reading into his writing that his definition of hardware and
software
was not OPERATIONAL when it quite easily acommodes your examples is a bit
sloppy.
Respectfully,
Don Mikulecky
Christopher J. Phoenix wrote:

> Don, I have an MSCS/AI concentration from Stanford. You must realize that
> what you wrote about hardware vs. software looks as surprising and wrong as
> if you'd said, "Of course, there's nothing wrong with the set of all sets,"
> or "It's easy to trisect an angle with a compass and straightedge." I am
> not dismissing your statement (yet), but I find it extraordinary.
>
> You said that in a Turing type machine, hardware and software are distinct.
> I assume you mean that you can in theory look at a Turing machine and say
> what is the hardware and what is the software. That's what you mean by
> superimposing "a partition into hardware and software", yes?
>
> But this is theoretically impossible for some Turing machine/tape
> combinations. You give me any Turing machine and tape, and I'll give you
> another one that encodes the machine-and-tape on tape. In all machines that
> I'll give back, the state diagram will be the same--only the tape will be
> different. It looks to me like I've taken hardware and converted it into
> software. The result of the converted machine will be the same information
> as in the original, but the causality is different by your usage of causality.
>
> Now don't forget the Halting Problem which says that there are some programs
> where you can't tell what they'll do--whether they'll return eventually or
> not. I can take any machine-encoded-on-tape and give you another machine
> which I claim will produce the same result--but without knowing how I did
> the transform, you have _no way_ to verify my claim. You will have no idea
> what that third machine does. You will have no way to distinguish a machine
> that does produce the same result from one that does not.
>
> To put it another way, you give me any machine or machine-plus-tape which
> produces a result. I will give you two machines with identical state
> diagrams. One machine will produce the same result as your machine. The
> other will never produce any result. You have _no way to tell_ from looking
> at the tape which is which--this is provable by simple logic. So how can
> you partition into hardware and software? How can you discuss causes?
>
> Now let's go in the other direction. You give me a computer with a program
> in its memory. I'll give you another computer with a completely blank
> memory and a box-full of diodes (semiconductor devices) that encodes the
> program in hardware. That second computer will produce exactly the same
> result (pattern in memory) as the first computer. This is possible for any
> program.
>
> So I don't see how you can say that software and hardware are different.
> Any partitioning method you can use, that looks at a system and says "this
> is hardware and that is software", will fail when looking at another system
> that produces the same result but a different partition.
>
> A few words about arguments, refutation thereof. If you present me with an
> argument that says "A implies B and B implies C and C implies D", then if I
> prove A is false, then B, C, and D have _no_ support whatsoever. If you
> present me with a procedure that says, "First you have to do A, and then you
> can do B and C and D," then if I prove that A is impossible, then B, C, and
> D are also _impossible_. It sounds from your writing like the ability to
> make hardware/software distinctions for any Turing-type machine is heavily
> used by Rosen. Any argument that depends on that ability will be left
> unsupported, and any procedure that requires that ability will be
> _impossible_, if that ability is proven to be impossible for some machines.
>
> Of course, you may be willing to concede that there are some Turing-type
> machines that you can't partition. But I suspect this will leave some
> things un-classifyable, which would severely weaken Rosen's categories, yes?
> And anyway, I claim that "hardware" and "software" are interchangeable, so a
> "partition into hardware vs. software" is meaningless. But first let's see
> what you think of my attempt to prove that there are some machines you can't
> partition, and what you think of its consequences if it's true.
>
> Chris
>
> At 08:51 AM 6/23/99 -0400, Don Mikulecky wrote:
> >Let's see what you claimed......you claimed that the section of the book was
a
> >"fallacy in Rosen's argument. You then said that all that follows is his
> and my
> >arguments is invalid. that is really humorous! I'll not comment on the
> >arrogance.
> >
> >you have been around long enough to know what it takes to refute an argument.
> >You first need to identify exactly which argument you proport to refute. You
> >simply claim ALL arguments then fail to even give a refutation. Now let's
deal
> >with what the book says and what arguments you claim to have refuted?
> >
> >Brian Josephson wrote:
> >
> >> --On Tue, Jun 22, 1999 10:43 -0400 "Don Mikulecky" <mikuleck@hsc.vcu.edu>
> >> wrote:
> >>
> >> > Ah Brian
> >> > I think you still do not get the picture that the machines, or simple
> >> systems we
> >> > talk about are "formal systems" on the right hand side of the modeling
> >> relation
> >> > into which natural systems are encoded. In other words they are things
> >> > scientists created in their minds. When you see a "machine" out in the
> >> real
> >> > world, it is a complex system. It fits all the OPPOSITE criterea from a
> >> simple
> >> > system! You have confused the two and think your confusion leads to a
> >> fallacy
> >> > in Rosen!
> >> >
> >> > You have still another straw man. Rosen's discussion of software and
> >> hardware
> >> > is not as you portray it nor does his argument rest on that portrayal.
> >> What
> >> > defines a michine is the following.
> >> > 1)the existence of largest models
> >> > 2)analytic models= synthetic models
> >> > 3)causalities are sepate
> >> > 4)they are fragmentable
> >> > 5)they are simulable
> >> > 6)they are poor in entailment
> >> > 7)they have a efficient cause from outside
> >> > 8)and many more
> >> > In each and every case the organism has opposite qualities. This is a
> >> whole
> >> > definition. I'll come back to the misinterpretation you make about
> >> hardware and
> >> > software later if you wish, but you attribute words to us that are not
> >> ours once
> >> > again.
> >>
> >> Don,
> >>
> >> On p.229 of _my_ copy of 'Life Itself' at any rate, after a
> >> discussion of 'mechanism' the text continues:
> >>
> >> "The situation is different if we are dealing with a machine. In this
case,
> >> we superimpose on a general mechanism the partition into hardware and
> >> software, which as we have seen, reflects itself in a corresponding
> >> partition of mechanism states into separate blocks".
> >>
> >> Are we reading the same book? Mine says at the front '(c) 1991 Columbia
> >> University Press'. Should I ignore the statement I quote, which seems
> >> absolutely clear cut to me, and accept that as you suggest that if I read
> >> the book in its entirety I will see that it does not mean that at all? I
> >> can't say I have ever come across a book written in that way before.
> >>
> >> Perhaps you are right to say that machines and "machines" are different.
> >
> >No...look at the language more carefully. There are a number of distinctions
> >made. The most obvious is between simple systems and complex systems. Then
> >WITHIN simple systems are machines. The Turing machine is used as an example
> >for the purpose of dealing with formalisms that are algorithmic. The
> >demonstration in the book is meant to focus on Turing type machines because
of
> >the widespread belief that the Universal Turing machine is the
> dsemonstration of
> >Church's Thesis. In Turing type machines there is a clear distinction
between
> >hardware and software. Why is this important? Because of the difference in
> >CAUSAL relations. This difference in CAUSAL relations is what is at issue
> >here. When we go back to the general case THAT is what we carry back. Rosen
> >spends a lot of time elsewhere on these same issues. There are many places
in
> >Life Itself where he assumes you have done your homework and read what came
> >before.
> >
> >What puzzles me is that you are so struck by the fact that in the example
> of the
> >machine among simple systems, namely the Turing Machine, that you generalize
> >from the example to the entire work. What is your problem with the idea
> that in
> >computers hardware and software are distinct?
> >
> >> This difference seems not to be referred to in Rosen. Or perhaps, to
> >> confuse us all, you are using different terminology to him? You list a
> >> definition of a machine in your letter, but it is hard to recognise Rosen
as
> >> saying the same. And the question is whether if machines are formal
systems
> >> that scientists create this has anything at all to do with the world of the
> >> informal scientific theory. I am wondering if all this apparent talking in
> >> riddles is serving any useful purpose, and we should stick to the informal
> >> understanding of these things that many of us appear to have.
> >
> >I think we are not talking in riddles, but in different worlds. I've long
ago
> >adopted Rosen's epistemology and find what follows self-consistent. Your
> >failure to recognize the list of traits that distinguishes simple systems
from
> >complex systems says that you have not followed Rosen very well. He does say
> >all those things and in that book. If you like I'll cite chapter and verse.
> >
> >>
> >>
> >> Brian
> >>
> >> * * * * * * * Prof. Brian D. Josephson :::::::: bdj10@cam.ac.uk
> >> * Mind-Matter * Cavendish Lab., Madingley Rd, Cambridge CB3 0HE, U.K.
> >> * Unification * voice: +44(0)1223 337260/337200 fax: +44(0)1223 337356
> >> * Project * WWW: http://www.tcm.phy.cam.ac.uk/~bdj10
> >> * * * * * * *
> >
> > My intuition tells me that we are not going to resolve our differences. I
> >would hope that you would be more careful before claiming to have destroyed a
> >man's life's work. My reading is that you do not understand the work and are
> >prone to focus on one detail or another out of context in order to find a
> way to
> >discount something that is contrary to your beliefs. It is not honest to
> >disguise that as a refutation of anything. If I am wrong, please correct
> me. I
> >also do want know the significance to you that Rosen shows that in Turing
type
> >machines, hardware and software are separate.
> >Respectfully,
> >Don Mikulecky
> >
> >
> --
> Chris Phoenix cphoenix@best.com http://www.best.com/~cphoenix
> Work (Reading Research Council): http://www.dyslexia.com
> Is your paradigm shift automatic or stick?

--------------F1BF49E4E1C5656006B5CF9A--