I think it is interesting to hear other opinions. So here is mine:
JDP> [...] Reasoning generally refers to deduction, which involves
"JDP" == John Douglas Porter <firstname.lastname@example.org> writes:
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. So
decisions like the above enable me to do reasoning, therefore my
module is a toolbox for doing geometric reasoning.
Ok, I stop here.
JDP> Fine; but I predict that if -- no, when -- you ask about this
I would prefer to use our acronym, therefore Math::SUGR would
then be my favorite.
then be my favorite.
JDP> on email@example.com, [...]
.... 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
Thanks for reading
 see also C. Peirce.
Stephan Heuel fon: +49 228 73 2711
Institute for Photogrammetry fax: +49 228 73 2712
University of Bonn, Nussallee 15 mailto:firstname.lastname@example.org
53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve