FAQ
Hi there,

I'm a PhD student working in the field of computer vision and recently
used Perl for doing my research and am asking for an appropriate name
for my Perl module(s).

I implemented a geometrical toolbox called SUGR[1] for constructing
and testing points, lines, planes and transformations in 2D and 3D.
The toolbox is based on projective geometry and a simple but effective
uncertainty model, though one can use the tool without statistics,
too. See BACKGROUND section in this post for more details.

So, the question of my post is: what name should be used for this Perl
module? Currently, SUGR is not categorized to any toplevel name. IMHO there
are several possibilities, I could categorize it to some computational geometry
related field (Math::Geometry::SUGR) or some statistical field (Statistics::SUGR).

Since I cannot decide for one option or the other, I'd like to use
AI::SUGR since this toolbox can be used for reasoning with
uncertain geometric objects as you could do reasoning with logical
statements (plane \$A is orthogonal to line \$L, which in turn contains
point \$X, without "choosing the epsilon", see BACKGROUND section).

So, what's the opinion of the community?

There is already a preview version of my library, it also
includes a special shell (based on the pdlshell) and a simple markup
language for offline computations. This is available from
http://www.ipb.uni-bonn.de/SUGR.html

-Stephan

Footnotes:
[1] SUGR is an acronym for "Statistically Uncertain Geometric
Reasoning"

############
# Details: #
############

BACKGROUND
----------

The (scientific) contribution of this work is the fact that the
geometrical toolbox uses simple statistical description (second
moments). This is helpful if you are not 100% sure about the exact
values of your points, lines and planes. For example if you
measure the length of your notebook with a simple ruler, you will
never know the length in - say - Angstrom (=1 hundred-millionth of
a centimeter), so you will always have some uncertainty about the
correct length.

Using simple statistics has several advantages: (i) you can propagate
the uncertainty to new geometrical objects. (ii) you get rid of the
"choosing-the-epsilon-problem"[2] when testing geometrical relations
such as "Does point X lie on the 3D-line L?". (iii) you can do a
weighted least-squares estimation to do _any_ kind of constructions
involving points, lines and planes in 2D and 3D.

Footnotes:
[2] The "Choosing-the-epsilon-problem" appears for example when you
want to test whether a number is zero. It is usually not really
zero, but close to it - so you choose a special small number
called epsilon and test if your number is smaller than epsilon.

INTERFACE
---------

# create a new 3D point, with an homogeneous 4-vector and
# a homogeneous 4x4 covariance matrix
\$X = new SUGR::Point([0,1,1,1],
[[0.01,0 ,0 ,0],
[0 ,0.01,0 ,0],
[0 ,0 ,0.01,0],
[0 ,0 ,0 ,0]]);

# create two other points with
# the same covariance matrix as the first point
\$Y = new SUGR::Point([0,2,3,1],\$X->cov);
\$Z = new SUGR::Point([2,2,0,1],\$X->cov);

# construct a new 3D line using \$X and \$Y,
# including error propagation
\$L = new SUGR::Line(\$X,\$Y);

# and a plane with the third point \$Z
\$A = new SUGR::Plane(\$L,\$Z);

# create a projective camera \$P with given
# projection center \$X0 (as a SUGR point!),
# rotation matrix \$R and focal length \$c with its
# variance \$c_var
\$X0 = new SUGR::Point([10,10,10,1],\$X->cov);
\$R = new PDL::Matrix([[0,1,0],[1,0,0],[0,0,1]]);
\$P = sugr_ProjectiveCamera({ "X0" => \$X0,
"R" => \$R,
"c" => 1,
"c_var" => 0.001,
});

# construct a new 2D point as an image of \$X with
# the projective camera \$P
\$x = new SUGR::Point2d(\$X,\$P);

# test if two points \$X and \$Y are identical
\$X == \$Y

# test if a line \$L is parallel to a plane \$A in 3D
Parallel(\$A,\$L)

--
Stephan Heuel fon: +49 228 73 2711
Institute for Photogrammetry fax: +49 228 73 2712
University of Bonn, Nussallee 15 mailto:stephan@heuel.org
53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve

## Search Discussions

•  at Jan 7, 2002 at 6:20 pm ⇧

Stephan Heuel wrote:
So, the question of my post is: what name should be used for this Perl
module? ... I could categorize it to some computational geometry
related field (Math::Geometry::SUGR) or some statistical field
(Statistics::SUGR).

Since I cannot decide for one option or the other, I'd like to use
AI::SUGR since this toolbox can be used for reasoning with
uncertain geometric objects ...

SUGR is an acronym for "Statistically Uncertain Geometric Reasoning"
This module does not seem to do what is normally meant by "reasoning".
And it certainly could be used in domains other than AI.
Therefore those should not be part of the name.

I would recommend something like Math::FuzzyGeometry.
(Third-level names for standalone modules are generally not encouraged.)

--
John Douglas Porter
•  at Jan 8, 2002 at 2:40 pm ⇧
John, thanks for the input.
"JDP" == John Douglas Porter <jdporter@min.net> writes:
JDP> Stephan Heuel wrote:
So, the question of my post is: what name should be used for this
Perl module? [...] SUGR is an acronym for "Statistically Uncertain
Geometric Reasoning"
JDP> This module does not seem to do what is normally meant by
JDP> "reasoning". And it certainly could be used in domains other
JDP> than AI. [...]

While I agree with your second point to some extent, I wonder what AI
people normally mean by the term "reasoning". IMHO reasoning is the
process of performing deduction or induction given some
information. And this information can surely be geometric information.

Kapur and Mundy published a book [1] about geometric reasoning and
they argue that geometry played a big role in AI with respect to
theorem proving as early as in the 50's and 60's. Applications for
such things are robotics and motion planning, machine vision and solid
modeling, clearly all AI applications.

My point can be explained by an example: a robot must be able to deal
with uncertainty since it knows its position and the position of other
objects only up to some error, so it is not certain about its
position. Dealing with uncertainy means to (i) represent these errors,
(ii) propagate these errors when doing new movements and (iii) taking
them into account when making decisions, such as "Am I pointing to the
red button? Will I miss the button when I try to push it?". My module
tries to provide means to accomplish these tasks taking uncertainty
into account [2].

JDP> I would recommend something like Math::FuzzyGeometry. [...]

Well, pure statisticians generally don't like fuzzy words like fuzzy
[logic], though it's a nice buzz word. I would prefer to use our
acronym, therefore

Math::SUGR

would then be my favorite. Or maybe the Math::UncertainGeometry
(probably too long).

-Stephan

Footnotes:

[1] Not that I want you to know these guys, but here is the reference
to their book: "Geometric Reasoning", edited by Kapur, D. and Mundy,
J.L.; MIT Press 1989

[2] I have to add that I have not applied my module to this field
but to the field of machine vision.

--
Stephan Heuel fon: +49 228 73 2711
Institute for Photogrammetry fax: +49 228 73 2712
University of Bonn, Nussallee 15 mailto:stephan@heuel.org
53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve
•  at Jan 8, 2002 at 6:37 pm ⇧

Stephan Heuel wrote:
JDP> This module does not seem to do what is normally meant by
JDP> "reasoning". And it certainly could be used in domains other
JDP> than AI. [...]

While I agree with your second point to some extent, I wonder what AI
people normally mean by the term "reasoning". IMHO reasoning is the
process of performing deduction or induction given some
information. And this information can surely be geometric information.
Reasoning generally refers to deduction, which involves processes of
generalization, specialization, and ontological pattern matching.

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

Deciding whether a point is inside or outside the region, with some
special statistical handling for the borderline case, is not reasoning.
Deciding whether x > 1.5 is not reasoning, whether it incorporates
fuzziness or not.

But even though I disagree with the use of "reasoning" in this way,
"geometric reasoning" seems to be more or less established as a name
by the academics; so, go with that. There is value is using a name
with which other users might already be familiar.

I would prefer to use our acronym, therefore
Math::SUGR
would then be my favorite.
modules@perl.org, you will find that acronyms are generally deprecated
in module names. And for good reason. When someone is looking for
a module to do, say, GA in perl, they don't search for "OPEAL". ;-)

--
John Douglas Porter
•  at Jan 8, 2002 at 6:48 pm ⇧

On Tue, 8 Jan 2002, John Douglas Porter wrote:

Not all decision-making should be called reasoning, unless you believe
that an ant reasons when it decides which direction to go to find that
dropped lollipop.
And even those of us who aren't ants and don't know if they reason,
may not consider all decision making to be reasoning.

Perhaps "reasoning" requires the migration of a decision making process
from one problem domain, to another.

--
Paris
•  at Jan 8, 2002 at 7:01 pm ⇧

Paris Sinclair wrote:
Perhaps "reasoning" requires the migration of a decision making process
from one problem domain, to another.
Well, maybe, but, avoiding a deep philosophical discussion,
I think it's a good idea to use names for their widely accepted

--
John Douglas Porter
•  at Jan 8, 2002 at 7:06 pm ⇧

On Tue, 8 Jan 2002, John Douglas Porter wrote:

Perhaps "reasoning" requires the migration of a decision making process
from one problem domain, to another.
Well, maybe, but, avoiding a deep philosophical discussion,
I think it's a good idea to use names for their widely accepted
What is the purpose of writing AI if you're going to avoid philosophy and
maintain the status quo? Is the implication that AI is already seen as a
largely completed or successfull field?

--
Paris
•  at Jan 8, 2002 at 10:20 pm ⇧

On Tuesday, January 8, 2002, at 01:06 PM, Paris Sinclair wrote:
What is the purpose of writing AI if you're going to avoid philosophy
and
maintain the status quo? Is the implication that AI is already seen as a
largely completed or successfull field?
Certainly not - but there have been great strides in AI research, and
most of these results are totally unrepresented as Perl code. If we
want AI people to be conversant in Perl and vice versa, I think it
behooves us to use the standard terminology.

Besides, people doing AI research are (rightfully) leery of anything
that smells like crackpot code or pie-in-the-sky, and using non-standard
terminology is one way to alienate yourself from "serious" researchers.
Once you establish yourself as someone with some credibility you can
start using whatever terms you like.

It's been discussed briefly on this list before, but I'll mention it
again: for a good introduction to ML topics/terms, check out Tom
Mitchell's excellent book "Machine Learning".

-Ken
•  at Jan 9, 2002 at 2:07 pm ⇧
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 <jdporter@min.net> 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> on modules@perl.org, [...]

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

-Stephan

Footnotes:

--
Stephan Heuel fon: +49 228 73 2711
Institute for Photogrammetry fax: +49 228 73 2712
University of Bonn, Nussallee 15 mailto:stephan@heuel.org
53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve
•  at Jan 9, 2002 at 2:13 pm ⇧

At 15:07 09/01/02 +0100, Stephan Heuel wrote:
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.
Sorry to interject with ignorance, but not having followed this thread
I'm a bit confused - what does SUGR stand for?

....lee
•  at Jan 9, 2002 at 2:58 pm ⇧

Lee Goddard wrote:
Sorry to interject with ignorance, but not having followed this thread
I'm a bit confused - what does SUGR stand for?
Exactly my point.

--
John Douglas Porter
•  at Jan 9, 2002 at 3:03 pm ⇧

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". ;-)
The man is very right ... I can't get the namespace of a module
(URI::Sequin) that's been floating around for some time assigned to me,
because it's an acronym.

*sigh*

+Pete

-Just-Another-Perl-Hacker--pete@grou.ch-
;;(\$_='Yw_xUabcdtefgdijktljkotiersjkUzxT
yvlkbfdtcierstajogvPruntRshackRJelov')=~
y&/RTUv;wxYz\$&/ ~'/;\$=();\$&&&eval&&print

## Related Discussions

Discussion Overview
 group ai categories perl posted Jan 7, '02 at 5:26p active Jan 9, '02 at 3:03p posts 12 users 6 website perl.org

### 6 users in discussion

Content

People

Support

Translate

site design / logo © 2021 Grokbase