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.