On Mon, November 19, 2012 14:33, Amanda Vizedom wrote: (01)
> I'd like to point out, and emphasize, that whether customers find
> undecidability / the throwing up of hands acceptable depends very much on
> how the question is put to them. If abstracted from context ..., it sounds
> scary and no one wants it. But with a little bit of real explanation
> thrown in, things change. (02)
> 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. (03)
Unless the guarantee is for a result within a specified amount of time,
e.g., 12.5 microseconds. (04)
> ...
> 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. (05)
I agree with all of the above. (06)
> ... 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. (07)
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. (08)
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. (09)
[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.] (010)
> 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. (011)
+1
-- doug f (012)
> Best,
>
> Amanda
>
> On Mon, Nov 19, 2012 at 1:52 PM, Ed Barkmeyer <edbark@xxxxxxxx> wrote:
>
>>
>> [snip]
>> Everyone agrees that FOL is more expressive and potentially more useful,
>> but all of the reasoning procedures that are widely used in academia
>> either restrict the allowable FOL inputs in some way that greatly
>> reduces its expressiveness or are programmed to throw up their hands at
>> some point -- they "halt" by saying "not determinable" (in some
>> language). The problem of not knowing the relationship between input
>> data -- the sets of valid sentences -- and the "not determinable" result
>> is what causes industry to shy away from FOL reasoners.
>> [sniip] (013)
_________________________________________________________________
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 (014)
|