Re: [ontolog-forum] Webby objects

[Amanda Vizedom <amanda.vizedom@xxxxxxxxx>]

Thanks, Doug. A few comments below:

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.

AJV2:
Sorry, I wasn't clear enough there; 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).

 

AJV1 

> ...

> The *real* choice of what is acceptable is never "will halt in a finite

> amount of time" and "may not halt in a finite amount of time."

> because the former itself is not good enough for application

>  and deployment.

DF: 

I agree with all of the above.

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.

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.

 

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.

 

[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.

 

AJV2

FYI, that link did not work for me; it went to an IEEE Xplore Error Page.

In any case, though, it's a nice example, 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    (01)