[Top] [All Lists]

Re: [ontolog-forum] HOL decidability [Was:using SKOSforcontrolledvalues

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 15 Oct 2010 13:59:33 -0700
Message-id: <20101015205936.CF8A3138D09@xxxxxxxxxxxxxxxxx>

Then why are you posting?



Rich Cooper


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.  





Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>