On 5 apr, 12:27, Nikolaus Rath
rath.org> wrote:>
>> 2. linpack/sqrsl.f ( plus dependencies )
>> gams: D2a1, D9a1
>> for: applies the output of (linpack/sqrdc) to compute coordinate
>> transformations, projections, and least squares solutions
>> prec: single
>> Score: 99%%
>
>> may be what you are after.
>
> I will take a look at it, thanks for the link!
>
>> But what you call vector algebra, I would call coordinate
>> transformations. I found the above looking for "coordinate".
>> The search terms "vector algebra" bring up a lot of
>> implementations of linear algebra algorithms.
>
>> I am curious as to what kind of problems you are trying to
>> solve, as your terminology seems to be so different from
>> mine.
>
> At the moment I am trying to simulate (rotating) x-ray diffraction of
> crystal structures. The crystal lattice is best constructed in
> cartesian coordinates, but for determining the interference pattern
> and rotating the crystal it is much easier to switch to cylindrical or
> spherical coordinates.
>
>> Many of the operations described in the Mathematica documentation
>> you refer to seem to be implementable in just a few lines of code.
>
> Yes, that's true. I was just wondering if no one has yet collected all
> these simple functions into a nice package. After all, even if they're
> not difficult to write it's still a waste of time if everyone who needs
> them has to write them again. But maybe I'm just to much used to CPAN
> and Java where there is always a module for everything :-)
>
> Best,
>
> -Nikolaus
>
> --
> Nikol...@
rath.org | College Ring 6, 28759 Bremen, Germany
> Class of 2008 - Physics | Jacobs University Bremen
>
> »My opinions may have changed, but not the fact that I am right.«
That is partly cultural, I guess :). There are a lot of Fortran
modules,
packages, libraries, ... out there for a wide variety of problems.
Netlib
is a good source for such packages.
I am getting the picture now. I can imagine it is easier to specify
the computations
you need in sperical or cylindrical coordinates, but ultimately the
computations
themselves will have to be done using cartesian.
(My guess is that in the end working with cartesian coordinates
directly turns
out to be faster, but that is just a guess)
Just musing here:
You could define a derived type like this:
type coord3d
logical :: up_to_date ! Are the spherical coordinates up
to date?
real :: x, y, z
real :: rad, phi, theta
end type
(The type represents a point in 3D space in _both_ cartesian and
spherical coordinates,
so that switching back and forth is hidden and done only when needed).
Then define suitable operations:
interface operator(+)
module procedure add_3d_points
end interface
interface operator(.rot.)
module procedure rotate_3d_point
end interface
type(coord3d) function add_3d_points( p1, p2 )
type(coord3d) :: p1, p2
add_3d_points%%x = p1%%x + p2%%x
add_3d_points%%y = p1%%x + p2%%y
add_3d_points%%z = p1%%x + p2%%z
add_3d_points%%up_to_date = .false.
end function add_3d_points
type(coord3d) function rotate( p1, p2 )
type(coord3d) :: p1, p2
type(coord3d) :: sp1, sp2
sp1 = updated(p1) ! Make sure the spherical representation is
correct
sp2 = updated(p2)
rotate%%phi = sp1%%phi + sp2%%phi
rotate%%theta = sp1%%theta + sp2%%theta ! Assuming such rotation is
okay
rotate%%up_to_date = .true.
end function rotate
etc...
Regards,
Arjen
