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 <[EMAIL PROTECTED]> 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 information. 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 [EMAIL PROTECTED], [...] .... 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 -Stephan Footnotes: [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 mailto:[EMAIL PROTECTED] 53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve
