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 3D, euclidean points in 3D 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 typeless implementation, everything seems ok unless by distraction supplying a dimension(3) array for a 3D entity or a dimension(2) array for 2D 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, hpoints, and one could go even deeper separating 2D TYPEs from 3D. 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 3D, euclidean points > in 3D 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 typeless implementation, everything seems ok unless by distraction > supplying a dimension(3) array for a 3D entity or a dimension(2) array for > 2D 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, hpoints, and one could go even > deeper separating 2D TYPEs from 3D. 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 