Try to increase the complexity and confusion all you like, try to conflate
the issues all you like, use negative words all you'd like. That doesn't change
the fact you have failed to show a physical embodiment of
software.
You use negative wording such as in your use
of the word pejorative. Definition:
Expressing contempt or
disapproval.
Sorry, when I'm describing a model of an invention - like a blueprint - there's nothing
contemptive or disapproving in my use of it. Nor is there anything contemptive
or disapproving in the context of whether software is abstract or can be
embodied in physical form.
I don't know if the word "pejorative" has a
special legal meaning and you're using it in that context.
the
pejorative term model
You'll have to clarify that point. The
common dictionary use is certainly an incorrect application of the
word.
You use conflation when you choose to
A:
Misrepresent what I said
B: Conflate the physical with the
abstract
Misrepresentation:
They can even duplicate the pattern of
expected behavior via numerous abstract methods such as mental tracing of the
diagram.
You apparently altered that to:
I agree, paper
analysis can not make an FPGA application.
My bolding. I
don't know how you view that as agreeing. Let me rephrase that and be explicit
with my position:
Paper analysis can make an FPGA
application.
An FPGA application is another abstract term/concept
used for software. Specifically software focused on FPGA functionality. Once
upon a time developers used to use sheets of paper to author out their COBOL
code. They'd be required to lay it all out, then run through the mental
analysis of "debugging it on paper". This was during a time when Mainframes
where the primary computers everyone used and computing cycles were expensive.
The associating departments were financially billed for the computing cycles
they used.
The fact that computing cycles have become less expensive so
we can author out our code in our own little sandbox environment and run/debug
it live in our little environment doesn't change the reality that we
could author out our software on paper and debug it there. In fact, when
I'm working on a particularly elusive bug I sometimes get a printout of the
subset of code where I've traced the bug down to and work on it in
transit.
Paper analysis can also be used to create the blueprint for the
physical
FPGA:
Field-programmable gate arrays (FPGAs) are reprogrammable
silicon chips.
Obviously the physical FPGA should not be confused
with the abstract FPGA application.
So we certainly do not agree as you
indicate.
All that's left is the increased complexity in
your authoring. When you get through all that (multiple occurances of the above
strategies). You're still using the same logic without actually pointing to a
single physical embodiment of software (whether or not you want to use the term
software or a more niche term such as FPGA application). The logic
being:
The physical can be modeled in the abstract, the abstract is highly
useful (concrete), therefore the abstract must be physical!
Sorry, You
still fail.
A steaming cup of coffee can be modeled by a good artist with
a pencil and paper. But no matter how you try to insist - you will get no
caffeine out of that drawing. The paper is physical. The lead is physical.
How we interpret that drawing is still abstract.
RAS[ Reply to This | Parent | # ]
| 
