Prev: gfortran/g95 differences
Next: Best way for integer division
From: GianLuigi Piacentini on 15 Mar 2010 15:06
Dear Sirs,

I am revising a library I wrote some time ago (enough to forget all that was
not explicitly stated in its docs), dealing with geometry.
At its foundation is a module implementing vectors in 3-D, euclidean points
in 3-D and homogeneous coordinates points (as mapping of an euclidean point
into homogeneous coords). I implemented all as dimension (4) arrays as
vector = (/ vx, vy, vz, 0 /)
point = (/ px, py, pz, 1 /)
hpoint = (/ px*w, py*w, pz*w, w /)
In such type-less implementation, everything seems ok unless by distraction
supplying a dimension(3) array for a 3-D entity or a dimension(2) array for
2-D entity (which may be more 'intuitive').
I could be more OO making a TYPE for such a dimension(4) array, or even
making separate TYPEs for vector, points, h-points, and one could go even
deeper separating 2-D TYPEs from 3-D. I fear that such many types would
become a mess.
I would like your suggestion on this subject.

Apologizing for my english, thanks in advance for your patience.

G.L. Piacentini

From: Arjen Markus on 16 Mar 2010 09:46
On 15 mrt, 20:06, GianLuigi Piacentini <ggpi...(a)tin.it> wrote:
> Dear Sirs,
>
> I am revising a library I wrote some time ago (enough to forget all that was
> not explicitly stated in its docs), dealing with geometry.
> At its foundation is a module implementing vectors in 3-D,  euclidean points
> in 3-D and homogeneous coordinates points (as mapping of an euclidean point
> into homogeneous coords).  I implemented all as dimension (4) arrays as
> vector = (/ vx, vy, vz, 0 /)
> point  = (/ px, py, pz, 1 /)
> hpoint = (/ px*w, py*w, pz*w, w /)
> In such type-less implementation, everything seems ok unless by distraction
> supplying a dimension(3) array for a 3-D entity or a dimension(2) array for
> 2-D entity (which may be more 'intuitive').  
> I could be more OO making a TYPE for such a dimension(4) array, or even
> making separate TYPEs for vector, points, h-points, and one could go even
> deeper separating 2-D TYPEs from 3-D.  I fear that such many types would
> become a mess.
> I would like your suggestion on this subject.
>
> Apologizing for my english, thanks in advance for your patience.
>
> G.L. Piacentini

You could define derived types and operations on these types so that
the compiler takes care of all the awkward details.

For instance:

module homogeneous_coordinates

type vector
real, dimension(4) :: coords
end type

interface operator(+)
module procedure add_vector
end interface

contains

type(vector) function add( v1, v2 )
type(vector), intent(in) :: v1, v2

add%coords = v1%coords + v2%coords
end function add
end module

etc.

Then you can use code like:

type(vector) :: v1, v2, resultant
v1 = ..
v2 = ..
resultant = v1 + v2

(You can find more elaborate examples, like automatic differentiation,
in my Flibs
project - http://flibs.sf.net)

Regards,

Arjen
 | 
Pages: 1
Prev: gfortran/g95 differences
Next: Best way for integer division