Grokbase Groups Perl ai January 2002
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

  • John Douglas Porter 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
  • Stephan Heuel 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).

    Thanks for reading this.
    -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
  • John Douglas Porter 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.
    Fine; but I predict that if -- no, when -- you ask about this on
    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
  • Paris Sinclair 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
  • John Douglas Porter 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
    meanings in industry/academia.

    --
    John Douglas Porter
  • Paris Sinclair 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
    meanings in industry/academia.
    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
  • Ken Williams 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
  • Stephan Heuel 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> Fine; but I predict that if -- no, when -- you ask about this
    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.

    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:stephan@heuel.org
    53115 Bonn - GERMANY http://www.ipb.uni-bonn.de/~steve
  • Lee Goddard 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
  • John Douglas Porter 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
  • Pete Sergeant 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 Navigation
viewthread | post
Discussion Overview
groupai @
categoriesperl
postedJan 7, '02 at 5:26p
activeJan 9, '02 at 3:03p
posts12
users6
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase