On Mon, November 19, 2012 16:31, Amanda Vizedom wrote:
> Thanks, Doug. A few comments below: (01)
> AJV1:
>
> > In particular, the "decidability" of a language is only a guarantee of
> > an answer within a finite amount of time. This is not a substantial or
> > useful guarantee in a used system. *Any* usable, fielded system will
> > have to have some way of throwing up its hands, some threshold at
> > which it will throw up its hands,
> > rather than waiting for a guaranteed finite-time result.
> DF :
>
>> Unless the guarantee is for a result within a specified amount of time,
> e.g., 12.5 microseconds. (02)
> AJV2:
> Sorry, I wasn't clear enough there; (03)
Amanda, you were clear. I was adding to what you said. Evidently,
*i* was not clear. (04)
> by "a guaranteed finite-time result," I meant " a result guaranteed
> to come with an unknown, but finite, amount of time.
> That's the guarantee that comes with "decidable" and is of
> little-to-no value in deployed applications (as you know). (05)
> ....
> AJV1
>> ... There are lots of ways to design systems to either disallow
>> certain statements (IMHO, better done semantically than
>> via unusably counter-intuitive or restricted syntax), or decline to
>> process certain reasoning patters that have
>> a high rabbit-hole risk, or cut out after a certain time,
>> or use other techniques to tune performance. The line between
>> decidable and undecidable systems is not a sweet spot for this. (06)
> DF
>> This reminds me of a project on embedded knowledge-based systems
>> i worked on in Finland in the 1990s. From the abstract of one paper,
>> "Integration of Knowledge Engineering with Real-Time Control"
>>[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00336848],
>> "timing information for a knowledge engineering task is usually not well
>> known. The indeterminate timing causes problems for real-time
>> scheduling." We created a method for combining an acceptable answer,
>> calculable in a short known amount of time, with heuristic methods that
>> take a much longer, variable amount of time. We didn't care or try to
>> calculate whether the heuristic methods were decidable or not (07)
>> We devised a system that could guarantee that the combined algorithm
>> would produce a valid answer when that answer was needed (a variable
>> amount of time with a minimum value), but could normally calculate a
>> better answer through heuristic calculations. (08)
>> [FWIW, one test case was with huge mining machines with three 10
>> meter long drilling arms that would drill scores of holes in a rock wall
>> (to set explosive charges in) for tunneling purposes. When one hole
>> is drilled, the multi-component arm must move to a new location
>> (changing its shape all the time) in the fixed pattern of holes.
>> Because of variations in the rock encountered, the time
>> taken for drilling each individual hole was variable. Planning was
>> needed to ensure that each arm had a hole to move to after completion
>> of the previous hole such that it would not collide with the other arms
>> nor would it block other arms from moving to a subsequent hole. The
>> combinatorics were high and if a suboptimal plan were created, it could
>> result in idle drilling arms and thus a longer total drilling time.
>> Collision calculations between a moving and stationary arm was
>> complex due to their variable shape and dangling hydraulic hoses. (09)
> AJV2
> FYI, that link did not work for me; it went to an IEEE Xplore Error Page. (010)
?? In that case, i attach the paper. (011)
> In any case, though, it's a nice example, (012)
Thanks. (013)
-- doug f (014)
> illustrating a couple of key points:
>
> 1) Why *would* you care whether the methods were decidable? It wouldn't
> contribute one wit to determining where the methods fell in relation to a
> goal that involves finding acceptable answers within an acceptable amount
> of time. It might be of purely theoretical interest to do such an
> analysis,
> but it would be of no practical value with respect to design, development,
> evaluation, tuning, evaluation, or performance of the system.
>
> 2) A multiple-method system is often the best performer. The overwhelming
> majority of systems I see, read about, or hear about attempt to use a
> single reasoning method to solving all problems. Whatever that method is,
> it may perform well on some of the problems within the domain of use; it
> often performs poorly on many others, or even rules out addressing them at
> all. It seems to be taken for granted by many that one simply has to
> accept trade-offs at this level.
>
> Some system designers think of, and perhaps even consider, building a
> smarter system incorporating multiple reasoning methods. Such a system can
> incorporate knowledge about the kinds of problems different methods to
> better or worse on, an analysis step in which the relevant features of a
> reasoning problem are evaluated, and a best method is chosen and applied.
> However, there seems to be a general belief that such a smarter system
> will be inherently a worse performer, or to complicated to build and
> maintain. Neither is true, IME, but the belief circulates out there
> without
> support.
>
> I wonder to what extent simple lack of familiarity with smarter systems --
> that is, systems incorporating a layer in which reasoning task parameters
> and candidate methods are themselves reasoned about -- is behind much of
> the DL-centric and single-method-limited design that we see. I'm not
> talking here about the few who chose a DL-based and/or single-method
> approach for some application, understanding other options but seeing this
> as the best fit for the case. I'm talking about the apparent majority who
> never work outside of those constraints.
>
>
> AJV1
>
> > For all of these reasons, IMHO, decidability is a red herring. Worse,
> and
>>
> > to mix my metaphors, it is a red herring that has led far too many
>>
> > talented people on a wild goose chase when they could
>>
> > be doing much more useful work to advance the state of the science
>>
> > and technology in really valuable ways.
>>
>
> DF
>
>> +1
>
> -- doug f
>
>
>
> Best,
> Amanda
>
>>
>
> _________________________________________________________________
> 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
> (015)
IRTC.pdf
Description: Adobe PDF document
_________________________________________________________________
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 (01)
|