Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP
id AA1428 ; Tue, 23 Feb 93 14:41:29 EST
Newsgroups: comp.unix.bsd,comp.os.386bsd.development
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sun-barr!cs.utexas.edu!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: [386bsd] Error Theory
Message-ID: <1993Feb17.091158.27775@netcom.com>
Keywords: Error theory device driver computer theory
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Wed, 17 Feb 1993 09:11:58 GMT
Lines: 135
The following is message I sent to William Jolitz a while back.
---------------------------------------
=======================================
RE: Error Theory/Error bit
Dear Bill, 03:10:44 Mon 01-04-1993
In my most recent efforts to rewrite the FDC code in use
for 386BSD, I have been unable to find a correct paradigim in
which recovery for an insatanciated error can be salvaged in a
concise manner. Before giving you my thoughs I must share some
fundamental Ideas I think that we can agree on.
1) At present we measure time as decay.
ie. decay of the the sun rising, a clock ticking
the half life of Uranimum
2) An Error is and embedded or integral process.
An Error can be removed from a process.
3) An Error can cause failure.
4) A Failure is not an Error, it is a response to an
Error.
My thoughts have been that the premise for my algorithm
is incorrect. That is most code is written with the thought
that the code will run correctly most all of the time, this
part is correct for efficient and active code, but treatment
of errors is limited at the present to traps. Traps being an
enclosure or encapsulation of the data recovery process, with
most if not all data being information that the unit must
digest.
Because the Error Process is feed or contains data
extranious to the Instanciated Error, a recovery calls for
sifting through data that is completely unassociated with the
current. Current being the time flow which speaks to the process
or error (not either or both for the process and the error are
integrated irregardless of the discrete state of the whole
process.).
In my recent readings I have found that the Egyptians
may have considered "Erra" a way of life. Carl B. Boyer writes
in "A History of Mathematics", that the Ahmes Papyrus considered
the unit fraction 3/5 to be 1/3+1/5+1/15. They used a method of
derivation that used the "natural fractions", namely 1/2,1/3 &
2/3. Boyer and others drew no conclusion from these inferences,
but it is somewhat obvious that they have taken the route of
"least reflected" errors. This is easily seen with the example
given. With no precision method of calibration, and we and
they knew this to be true, they resorted to a method which could
easily be explained and logically be derived.
3/5 is a number, which if taken from a whole item (such
as an apple) is difficult to conceive. If on the other hand I
said give yourself 1/2+1/5+1/15 you might have a better
estimate. You may say, "Well, What if I cut 1/5 and triple
that?". Consider the error! Your magnitude of error is now the
larger part of the error times 3. If, however, you use
1/2+1/5+1/15, your magnitude of error is reduced in sequence by
the magnitude of the partial size of the parts, respectively.
That is the magnitude of your error is no larger than:
n(A + 2/3A + 4/9A ...)
or n(A + 1/2A + 1/4A ...)
or n(A + 1/3A + 1/6A ...)
VS.
n(A + A + A ...)
if you cut your apple in 1/5 parts.
This being the case "Erra" can be seen as something
always known. Definitely we are told Adam and Eve created the
First Error of/for mankind.
When I preposed this idea to an associate, he said it
had been done and what I might conceive would be a waste of
time. Further, he stated that since it had been done I would,
with all probability have nothing new to add or insight. I had
to point out that like music theroy, the Ideas came first,
theory is a description of It.
It sounds a bit ludicrous that one might consider what I
prepose as a science, but in fact if the development is not
considered, my personal feeling is that computational science
will not evolve as we dream/hope.
A strong point in my favor is that computer science in
most levels of higher education is an extension of the
Electronic Engineering Department, when in fact the software is
really exclusively a branch of logic and error decection.
Another major factor is the misnomer that software development
is always behind hardware development. This is altogther
incorrect, we know what we want to do, we are confinded by EE's
with dillusions of being the next Shocky.
Aristotle and the Greeks called it "Logos eritakos",
in English, quibble. We might call it "Eritalogics".
How can this be implemented in 386BSD you ask?(maybe)
I am not quite sure, but I can see major parts in my
mind, not the whole.
Will this require major hardware redesign?
No, but to work in all efficency the CPU must have a
Hardware & Software ERROR Bit. In the IBM BIOS, that runs most
ATs, the system service call rely heavily on the "carry bit" to
double as an "error bit". This tells us that real time single
operator Operating Systems have recognition of what we need to do.
I have other thoughts about 386BSD they will follow in
other letters.
Jesse Monroy Jr.
jmonroy@netcom.com