Grokbase Groups Perl ai January 2002
Ok, I'll shortly dive into the philosophical discussion, just because
I think it is interesting to hear other opinions. So here is mine:
"JDP" == John Douglas Porter <> writes:
JDP> [...] Reasoning generally refers to deduction, which involves
JDP> processes of generalization, specialization, and ontological
JDP> pattern matching.

True, but to be honest the term "ontological pattern matching" is new
to me; to satisfy my curiosity, do you have a pointer for it at hand?

IMHO reasoning may also be characterized by stating that it uses
_symbolic_ information, in contrast to (possibly digitized) "smooth"
information. As an example: I can represent an image by a matrix of
grey-values (which is a digitized version of an ideal smooth image) or
I may represent it by a list of edges, which is symbolical

JDP> Not all decision-making should be called reasoning, unless you
JDP> believe that an ant reasons when it decides which direction to
JDP> go to find that dropped lollipop.

But someone could build an robot-ant which finds the lollipop by
reasoning. You are right, most likely a real ant does not do
symbolical processing, but maybe something like tracking. This
tracking would be similar to a robot that can push the red button
using tracking techniques (e.g. Kalman filter); similarly, such a
robot does not do reasoning. But as soon as it uses symbolic
information, it may go through a sequence of logical inferences to
reach its goal.

JDP> [...] Deciding whether x > 1.5 is not reasoning, whether it
JDP> incorporates fuzziness or not.

"Fuzziness" is not really the issue. If I decide that x > 1.5 then I
may be (or may be not) entitled to say that I'm still too far from the
lollipop resp. red button. This is an abduction, therefore a method of
reasoning by which one infers to an (the best) explanation[1]. So
decisions like the above enable me to do reasoning, therefore my
module is a toolbox for doing geometric reasoning.

Ok, I stop here.
I would prefer to use our acronym, therefore Math::SUGR would
then be my favorite.
JDP> Fine; but I predict that if -- no, when -- you ask about this
JDP> on, [...]

.... of course I do ...

JDP> [...] you will find that acronyms are generally deprecated in
JDP> module names. And for good reason. When someone is looking for a
JDP> module to do, say, GA in perl, they don't search for "OPEAL". ;-)

To be honest, at a first glance, the module name AI::GA does not look
nice or informative either ;-)

But I really would like to keep my acronym since I have used it in too
many places. So I will propose either SUGR or Math::SUGR.

Mmmh, technical question: on source code level, is there a general,
nice way to have an alias for a module name? Then
Math::UncertainGeometry would be okay, or even better
Math::UncertainProjectiveGeometry. Maybe I will ask this in an
appropriate newsgroup.

Thanks for reading

[1] see also C. Peirce.

Stephan Heuel fon: +49 228 73 2711
Institute for Photogrammetry fax: +49 228 73 2712
University of Bonn, Nussallee 15
53115 Bonn - GERMANY

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 12 | next ›
Discussion Overview
groupai @
postedJan 7, '02 at 5:26p
activeJan 9, '02 at 3:03p



site design / logo © 2021 Grokbase