# How-to carry out a set of operations on a large set of three-dimensional vectors in most efficient manner?

Problem description

Essentially, I am trying to carry out a set of operations on a significantly large set of coordinate data. The coordinates in the data set represent a uniformly distributed set of points within some complex geometry on per geometry entity basis. I know how to carry out some operations necessary to achieve what, ideally, would be my objective. However, I ran into difficulties putting different components of the algorithm together. This can be described by insufficient knowledge of programming in Mathematica at current time.

Below is a narrowed down example of what I am trying to achieve:

Input data [example]

origins = {{-2.87985, 0.27489, 1.2342}, {-2.8102, 0.2323,
1.1111}, {-3.2728, -0.1247, 0.0023}, {-3.1846, -0.2364,
1.2206}, {-3.0209, -0.2992, 0.6696}};
destinations = {{6.2662, 16.3095, 0.8657}, {4.2532, 14.7594,
3.5271}, {5.5305, 5.35983, 3.61508}, {4.48381, 15.74443,
0.3802}, {6.6048, 10.1849, 1.4391}};
offset = {#[], #[]+6, #[]} & /@ origins;


Output [incomplete]

Graphics3D[{
(*Origin*)
Cylinder[{{-3, 0, 0}, {-3, 0, 2}}, 0.3],
{PointSize[0.1], Red, Point@#1},
(*Offset*)
{PointSize[0.05], Green, Point@#2},
(*Rotation*)
Tooltip[{PointSize[0.05], Blue,
GeometricTransformation[Point@#2,
RotationTransform[Pi/2, {0, 0, 1}, #1]]}, "Rotation: \[Pi]"]
},
Axes -> True,
AxesLabel -> {"x", "y", "z"}] &[origins[], offset[]]


Following is a set of steps which I would like to be able to carry out on the above data set:

1. Offset each vectors 'y' coordinate value by some number;
2. Rotate the offset products around their associated origins in {Pi/2, Pi, 3 Pi/2, 2 Pi}
3. Upon each rotation of the offset components, calculate the distance between the new coordinates of the associated vector and ALL coordinates in the destinations set.

Issues

In the above output example, I have applied the GeometricTransformation in a form of RotationTransformation and I was able to rotate the Point around the origin as it was intended. However, in this example, I have specified the rotation axes manually. Given that I am working with a complex geometry, would there be a way how to achieve the axe selection automatically?

It is my current understanding in order to achieve the distance calculation I could use inbuild functions such as Outer and EuclideanDistance. What I strugle with is formulating the algorithm to carry out all of the above in the most efficient manner.

I would appreciate any input on the subject matter and hope to learn from this activity.

EDIT 1: Clarification

In order to visualize the relation between the origin and the offset coordinates, please see table below:

# Additionally, the rotation axis must be {0,1,0} for vertically positioned cylinders and {0,0,1} for horizontally positioned Cylinder.

I have also found a flow in my initial design. The flow is releted to the offset coordinates. As with rotation axis, the offset must commence based on Cylinder position (vertical -> {0,1,0}, horizontal -> {0,0,1})

• Re: "would there be a way how to achieve the axe selection automatically" ... what is the criteria for the axis "selection" – Dr. belisarius Nov 19 '15 at 0:41
• The geometry is based around simple geometric entities, mostly cylinders. Given cylinder signature requires min, max coordinates to be passed as parameters, perhaps, based on the difference in min, max values I could identify the correct axis. I would welcome any suggestions. It is worth noting, most cylinders are either vertical or horizontal. – e.doroskevic Nov 19 '15 at 0:52
• Your question could benefit by some clarifications. For instance, in step 2 what is an associated origin and about what axis is a product to be rotated. In step 3, what is the associated vector, and what is the destinations? By the way, step 1 can be accomplished by offset = (# + {0, 0, n}) & /@ origins or MapAt[(# + n) &, origins, {All, 3}], where n is some number. – bbgodfrey Nov 19 '15 at 1:23
• @bbgodfrey, thank you for you comments. They have been very valuable. I have addressed the comments you've left and commited an edit to my original post. In terms of solutions proposed for calculating the offset, I decided to maintain currently implemented code since it shows little or no difference in AbsoluteTiming. – e.doroskevic Nov 19 '15 at 8:32