🚀 go-pugleaf

In article <1992Nov16.160806.29351@cv.ruu.nl> rvloon@cv.ruu.nl (Ronald van Loon) writes:

   [... two ways of handling point_3d and
    point_3d_with_coordinate_system so that the test for equal
    coordinate system can be bypassed ...]
   -- 
   +--- Ronald van Loon ---+ 
   |  (rvloon@cv.ruu.nl)   | 
   |  3DCV Group, Utrecht  |
   +--- The Netherlands ---+ This part of .signature intentionally left blank.

How about just one class with two sets of operations?  One set has the
test for equal coordinate systems.  The other does not.  The functions
in the second set all assume a precondition that the coordinate
systems are be equal.  If coordinate systems are unequal, the results
are undefined (even if something is dutifully computed).

Also, here is a discussion of how coordinate system organization.
This is not directly applicable to your question, but pretty much is
the general starting point for deriving more specialized coordinate
system implementations.  A point with coordinate system is
conceptually a pair:

[abstract point (p in P), coordinate system (S : P => R^n)].

Notice, 
 O a coordinate systems is a mapping
 O there is no explicit vector of coefficients.  However, such a
   vector can still be obtained as S(p) (or S().apply(p) in C++).
 O the coordinate system frame can be obtained from the tuple of
   abstract points:
   [S.inverse().apply([0 0 0])
    S.inverse().apply([1 0 0])
    S.inverse().apply([0 1 0])
    S.inverse().apply([0 0 1))].

Other important objects are:

 O coordinate transformations, such as
   T = S1.inverse().compose(S2) : R^n1 => R^n2
 O mappings between abstract spaces, such a M : P1 => P2
 O associated coordinate mappings, such as
   T = S1.inverse().compose(M).compose(S2) : R^n1 => R^n2
 O network (or set) of mapping between abstract spaces and coordinate
   transformations/mappings.

All operations on points with coordinate systems eventually decompose
into operations on points in R^n which themselves decompose into
operations on things like arrays of floats.  The multitude of design
choices include:

 O going straight to representations of things like arrays of floats
   and making all the rest implicit.  Within certain scopes of a
   graphics application (e.g. inside a graphics server, a graphics
   engine, or a third party graphics routine) this can be manditory.
 O disallowing all user access to the abstract point objects or even
   the coordinate system objects, so they needn't be explicit in the
   final software design
 O caching intermediate interesting information.  Caching the
   coordinate tuple (S(p)) or an array of floats on the
   point_3d_with_coordinate_system is the most common type of cache.
   Another type caches composed coordinate transformations on the
   network object or in some local variable.

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------