59 views

Skip to first unread message

Nov 7, 2021, 6:51:51 AM11/7/21

to

Dear Fortraneers,

I'am writing a geometry package somewhat oriented to CAD-CAM. It's a

pet project, rewriting and hopefully extending what I did for work

(sheet metal) some 30 years ago (in C, because C was on the "cool" side

those days - and I do not have the sources).

The point is that in surface/solid modeling 3-D is a must, whereas for

sheet metal 2-D is all what is needed. So I started writing some code

around separate types for 2d and 3d, say

type Point_2d

real :: x, y

..

and

type Point_3d

real :: x, y, z

..

Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

Now, I'm realizing I'm writing a lot of repetitive code for the 2

separate types (or 4 when including rationals) - that should be tested, too.

I would like to avoid this. Goal is to keep expressivity minimizing code.

Other possibilities

type, extends(Point_2d) :: Point_3d

real z

and similar extensions for 2d and 3d rationals

or

type Point

real x, y, z with z always present, and may be set to a guard

value, say zero, to warn that it's 2-d

or

type Point

real :: coordinates(3) ! 1 is x, 2 is y 3 is z set to zero to mark 2d

or

type Point

real, allocatable :: coordinates(:)

with size(coordinates) discriminating between 2d and 3d (but what

happens when there are 2d rationals and 3d "normal" - size is always 3)

Mantyla in its text on solid modeling simply uses a dimension(4) array

for vector/point coordinates.

Piegl et al in their NURBS book use always 3d rationals with guard

values to discriminate 2d and non-rational case.

De Boor in its B-spline package stores curve control points in arrays,

one for each coordinate, and similar approach is in the code

accompanying the Farin's book.

May be there are many other possibilities I do not see at this moment.

Do you have suggestions in order to minimize code repetition ?

Thanks in advance

Gigi

I'am writing a geometry package somewhat oriented to CAD-CAM. It's a

pet project, rewriting and hopefully extending what I did for work

(sheet metal) some 30 years ago (in C, because C was on the "cool" side

those days - and I do not have the sources).

The point is that in surface/solid modeling 3-D is a must, whereas for

sheet metal 2-D is all what is needed. So I started writing some code

around separate types for 2d and 3d, say

type Point_2d

real :: x, y

..

and

type Point_3d

real :: x, y, z

..

Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

Now, I'm realizing I'm writing a lot of repetitive code for the 2

separate types (or 4 when including rationals) - that should be tested, too.

I would like to avoid this. Goal is to keep expressivity minimizing code.

Other possibilities

type, extends(Point_2d) :: Point_3d

real z

and similar extensions for 2d and 3d rationals

or

type Point

real x, y, z with z always present, and may be set to a guard

value, say zero, to warn that it's 2-d

or

type Point

real :: coordinates(3) ! 1 is x, 2 is y 3 is z set to zero to mark 2d

or

type Point

real, allocatable :: coordinates(:)

with size(coordinates) discriminating between 2d and 3d (but what

happens when there are 2d rationals and 3d "normal" - size is always 3)

Mantyla in its text on solid modeling simply uses a dimension(4) array

for vector/point coordinates.

Piegl et al in their NURBS book use always 3d rationals with guard

values to discriminate 2d and non-rational case.

De Boor in its B-spline package stores curve control points in arrays,

one for each coordinate, and similar approach is in the code

accompanying the Farin's book.

May be there are many other possibilities I do not see at this moment.

Do you have suggestions in order to minimize code repetition ?

Thanks in advance

Gigi

Nov 7, 2021, 7:38:47 AM11/7/21

to

Alternatively, a four-dimensional space is often used to turn affine operations (rotation, reflection, translation) into a matrix operation. The fourth coordinate is set to 1, so that it plays a role in the translation part. For 2D applications you could set the third coordinate to 1 as well and let the entries in the transformation matrix follow an analoguous pattern.

Just a few suggestions, mind you.

Regards,

Arjen

Nov 8, 2021, 5:15:03 AM11/8/21

to

On 07/11/21 13:38, Arjen Markus wrote:

> On Sunday, November 7, 2021 at 12:51:51 PM UTC+1, GianLuigi Piacentini wrote:

>> Dear Fortraneers,

>>

>> I'am writing a geometry package somewhat oriented to CAD-CAM. It's a

>> pet project, rewriting and hopefully extending what I did for work

>> (sheet metal) some 30 years ago (in C, because C was on the "cool" side

>> those days - and I do not have the sources).

>> The point is that in surface/solid modeling 3-D is a must, whereas for

>> sheet metal 2-D is all what is needed. So I started writing some code

>> around separate types for 2d and 3d, say

>> type Point_2d

>> real :: x, y

>> ..

>> and

>> type Point_3d

>> real :: x, y, z

>> ..

>> Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

>>

>> Now, I'm realizing I'm writing a lot of repetitive code for the 2

>> separate types (or 4 when including rationals) - that should be tested, too.

>> I would like to avoid this. Goal is to keep expressivity minimizing code.

>>

>> ...
> On Sunday, November 7, 2021 at 12:51:51 PM UTC+1, GianLuigi Piacentini wrote:

>> Dear Fortraneers,

>>

>> I'am writing a geometry package somewhat oriented to CAD-CAM. It's a

>> pet project, rewriting and hopefully extending what I did for work

>> (sheet metal) some 30 years ago (in C, because C was on the "cool" side

>> those days - and I do not have the sources).

>> The point is that in surface/solid modeling 3-D is a must, whereas for

>> sheet metal 2-D is all what is needed. So I started writing some code

>> around separate types for 2d and 3d, say

>> type Point_2d

>> real :: x, y

>> ..

>> and

>> type Point_3d

>> real :: x, y, z

>> ..

>> Then, there are rational point (real :: x, y, w and real :: x, y, z, w)

>>

>> Now, I'm realizing I'm writing a lot of repetitive code for the 2

>> separate types (or 4 when including rationals) - that should be tested, too.

>> I would like to avoid this. Goal is to keep expressivity minimizing code.

>>

> Instead of a component coordinates(3) or an allocatable component, you may consider to use parametrised types. Then a len parameter can set the dimension.

Could you please elaborate more on this subject ?
My objective is to write and test less code is possible (so for example,

write (and test) a single procedure instead of, may be

"project_2d_point_onto_2d_line", and "project_3d_point_onto_3d_line").

>

> Alternatively, a four-dimensional space is often used to turn affine operations (rotation, reflection, translation) into a matrix operation. The fourth coordinate is set to 1, so that it plays a role in the translation part. For 2D applications you could set the third coordinate to 1 as well and let the entries in the transformation matrix follow an analoguous pattern.

internally did when transforming entities.

>

> Just a few suggestions, mind you.

>

> Regards,

>

> Arjen

>

Thanks
> Just a few suggestions, mind you.

>

> Regards,

>

> Arjen

>

Gigi

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu