Then why are you posting?
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Christopher Menzel
Sent: Friday, October 15, 2010
12:58 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] HOL
decidability [Was:using SKOSforcontrolledvalues for controlledvocabulary]
I think Ron Wheeler's point was that, just as your personal notion of
iteration is irrelevant to Gödel's theorem, so its relevance to Ontology
Engineering is, at best, less than clear. If I am reading him correctly
(and perhaps I'm not), he was questioning whether continued discussion of your
notion is a good use of ontolog bandwidth.
On Oct 15, 2010, at 9:40 AM, Ron Wheeler wrote:
On 15/10/2010 10:23 AM, Rich Cooper wrote:
Carries from bit to bit within a fixed word length use a constant
amount of
space and time because the clock rate on the computer is set to work
with
even a full set of carries across the entire word length. In
practice, this
makes my kind of iterator constant in its use of space and time.
Asynchronous computer arithmetic has proven to be impractical in actual
use.
Great forum for those who miss the 1960's and 1970's.
Anyone have a comment on implementing the caching of hard-drive data?
Was replacing RDBMS with SQL a good thing?
How far can we go in the guise of Ontology repository requirements?
On Oct 15, 2010, at 1:30 PM, Rich Cooper wrote:
Yes John Bottoms, I agree with your position.
Ron Wheeler, for entirely practical considerations,
I require an iterator that has a fixed number of storage locations, and which
performs its function in a fixed amount of time, regardless of the value being
iterated. Also for practical purposes, I consider addition to be
processed in one machine cycle, regardless of whether it’s a small amount
longer for asynchronous designs. One add, with this caveat, consumes as
much as another.
You are certainly welcome to look inside the word
and postulate a long (N bit) asynchronous word being incremented from 2^N-1 to
overflow, but I wouldn't choose that representation. I stand by my
requirement that the function should use a (nearly) constant amount of time and
space, the same time and space consumed for each iteration regardless of the
type being iterated. If you want short and long carries to be considered
different consumption of time, that is your right, but I don't subscribe to
that representation. No insight is gained by delving that deeply inside
the ALU.
For practical considerations again, there is no
point in being concerned with algorithms that delve into the carry level of
timing. An "iterator" in my terms has a role to play which
requires it to be approximately constant in time and space.
Clearly, every person on this list could postulate
yet another kind of consideration for iterators, but I have stated mine.
|