|
|
|
| Authored by: PolR on Sunday, September 02 2012 @ 12:15 PM EDT |
The wish to prove software == maths is, I assume, so as to say
therefore
software is abstract and thus cannot be patented.
While abstract
definitions of algorithm and maths can be found that support that
idea, these
definitions are far removed from what most real life software
engineers actually
do.
As far as I know, the activity of a software engineer is not
what is patented. The patent covers that activity of the computer, ie its work
processing bits. "Software is math" is just a slogan. It is not a statement that
the work of a computer programmer is the work of a mathematician. Such a
statement would be both false and irrelevant to the subject matter of the
patent. The real statement that the work of a computer running software is a
mathematical computation pursuant to an algorithm in the sense of computation
theory. This statement is the one that relates to what is patented in software
and it also happens to be scientifically correct.
So the wish is not to say
software == math in a broad unconditional manner. The slogan "software is math"
is a very short phrase capturing the notion that execution is the aspect of
software which is patented and execution is always algorithms.
[ Reply to This | Parent | # ]
|
| |
| Authored by: bprice on Sunday, September 02 2012 @ 09:11 PM EDT |
Designing a CPU is a task for a hardware engineer, not a programmer.
Now a programmer may also have skills as a hardware engineer (and many other
skills besides) but when a person designs a CPU, they are exercising their
hardware skills.
A CPU likely contains software and
whoever writes that software is clearly a programmer, but programming skills
alone will be insufficient to design a CPU.
tl;dr: the only
separability between programming skills and hardware skills is not real but
artificial and illusory.
My experience differs from your ideas. I found,
from experience, that there is no useful place to draw a line between
programming and CPU design. Those skills that are not common up and down the
lines cross any boundary that can be proposed: skill A may be most useful at
some levels, and skill B at others, but the overlaps are such that no efficient
boundary can be drawn. All along the spectrum, we have elements such as
algorithms (composition), whether time-multiplexed (programming, including CISC
firmware), spatially separated (e. g., processing pipelines), both, or
otherwise;
data and functional structures;
tradeoffs among various
approaches, whether at the same level of discourse (e, g. multiplication
by Wallace or Dadda tree vs binary/two-bit/4-bit iteration) or across
multiple levels (self-identifying peripherals à la plug and play
vs external info sources for peripheral type);
partitioning into
buildable units (including, of course, the interfacery that allows the
partitioning to work);
expression in processable form, in a programming
language, HDL, or some non-textual form;
compatibility with other levels of
discourse (aka syntactic and semantic correctness).
Individual people have
their individual tastes and preferences; organizations draw boundaries between
budgetary units, and separate their people that way. The people are drawn to
the organizational units that fit their tastes and abilities. Each
organizational (budgetary) unit wants a piece of the action, and insists that
their specialization gets at least their "fair share" of the project
budget.
Some people thrive in such highly structured budgetary regimes. I
never did, and I was lucky enough to have the less restrictive environments that
were so natural to me. We solved hardware problems with software, and software
problems with hardware, whenever "cross-disciplinary" solutions seemed
appropriate.
---
--Bill. NAL: question the answers, especially mine. [ Reply to This | Parent | # ]
|
|
|
|
|
