Design Considerations - Simple Vector Class

[3trQN]

I had a curious thought while writing a simple program that involved writing my own vector class (as in a mathematical representation of a displacement in n-dimensional space).

I was wondering which way would be best to design the vector class ( language is C++ ).

The first method was to build a vector class with functions/methods built into it for handling the required vector operations (such as the scalar/vector product and normalisation/scaling transformations). Then to also include operator overloading and polar/cartesian/other coordinate system conversions etc.

The other idea was to just to use a simple vector (possibly even a struct or the bare minimum) and have the vector maths and operations handled seperatley, as possibly global functions operating on the vectors.

The first method has advantages in that it follows OOP methods and doesn't break the encapsulation rules. It would seem to be a safer and more complete design. However it may also be restrictive in some way, in the future.
Whereas the latter method is more open.

So i was wondering, if anyone has any experience with kind of thing, could offer and insight or suggestions.

 

[nmtim]

I was wondering which way would be best to design the vector class ( language is C++ ).

For what application? If there was one vector class that could solve most problems well, it'd be in the standard library.

I distrust classes that try solve all problems. For example, a Cartesian vector might have some common interface elements (magnitude(), dot(), cross()) to a spherical vector, but a different implementation for all of those. That indicates that you may be dealing with more than one class, perhaps related by a common ancestor (inheritance) or specializations of a common template. In addition, each class may have uncommon interface elements (the Cart. vector might have x(), y(), z() accessors, the spher. might have r(), theta(), phi()). This makes me think of a mix-in base class, perhaps a policy class. But can I afford the cost of virtual functions?

You can't answer these questions independently of the context in which the class will be used: What in your code is using vectors? What interface do clients require? What performance is required? Do you need more exotic coordinate systems? And so on.

Just a few thoughts. Good luck,
Tim

 

[0rthodontist]

I had a curious thought while writing a simple program that involved writing my own vector class (as in a mathematical representation of a displacement in n-dimensional space).

I was wondering which way would be best to design the vector class ( language is C++ ).

The first method was to build a vector class with functions/methods built into it for handling the required vector operations (such as the scalar/vector product and normalisation/scaling transformations). Then to also include operator overloading and polar/cartesian/other coordinate system conversions etc.

The other idea was to just to use a simple vector (possibly even a struct or the bare minimum) and have the vector maths and operations handled seperatley, as possibly global functions operating on the vectors.

The first method has advantages in that it follows OOP methods and doesn't break the encapsulation rules. It would seem to be a safer and more complete design. However it may also be restrictive in some way, in the future.
Whereas the latter method is more open.

So i was wondering, if anyone has any experience with kind of thing, could offer and insight or suggestions.

OOP is usually better but in this case you just want a function library for dealing with vectors. Vectors have a fixed number of dimensions so you can just use arrays instead of formally making a struct, and then make a library containing dot product, normalization, etc. operations on arrays.

 

[Hurkyl]

I would typically be inclined to think of a vector as a data type, not as an object.

The first method has advantages in that it follows OOP methods and doesn't break the encapsulation rules.

But that doesn't mean you have to break the encapsulation "rules". I would expect all of the data in a vector to be private, and that it would just have the basic access functions... vector operations (including overloaded arithmetic operators) would be global.

What in your code is using vectors? What interface do clients require? What performance is required?

But, of course, this is good advice. You really need to make sure you choose a solution that can accomplish your goals, and then worry about aesthetics.

 

[mgiddy911]

My knowledge comes from java so correct me if I am way off, but isn't a data type essentially an object?

 

[Hurkyl]

I'm speaking more in the conceptual sense, rather than the syntactic sense.

 

[JoAuSc]

OOP is usually better but in this case you just want a function library for dealing with vectors. Vectors have a fixed number of dimensions so you can just use arrays instead of formally making a struct, and then make a library containing dot product, normalization, etc. operations on arrays.

The advantage of making vectors objects, though, is that arrays of vector objects look much simpler. If I have an ensemble of particles arranged in a 2D array in 3D space, then to contain all the data I'd either have to do
double position[][][] = new double[numXRow][numYRow][3]

or

Vector position[][] = new Vector[numXRow][numYRow].

I think the second way is less confusing. On the other hand, a few days ago I was making a Particle object in java which contained methods to calculate the force it felt from another Particle and to update the Particle's position and velocity (also contained in the object) to respond to this force. I did the vector calculations by creating a separate VectorMethods class which contained methods for manipulating double arrays, doing just what you suggested. In that case, I didn't need the extra simplicity of a Vector method because the vector calculations were all done inside of the Particle classes, so that accessing the x-component of a certain particle's position meant doing something like

Particle[][] particle = new Particle[numXRow][numYRow];
(initialize particle data here)
System.out.println( particle[2][4].getXPosition() );

rather than

double[][][] position = new double[numXRow][numYRow][3];
(initialize positions)
System.out.println( position[2][4][0] );

I had a curious thought while writing a simple program that involved writing my own vector class (as in a mathematical representation of a displacement in n-dimensional space).

I was wondering which way would be best to design the vector class ( language is C++ ).

The first method was to build a vector class with functions/methods built into it for handling the required vector operations (such as the scalar/vector product and normalisation/scaling transformations). Then to also include operator overloading and polar/cartesian/other coordinate system conversions etc.

The other idea was to just to use a simple vector (possibly even a struct or the bare minimum) and have the vector maths and operations handled seperatley, as possibly global functions operating on the vectors.

The first method has advantages in that it follows OOP methods and doesn't break the encapsulation rules. It would seem to be a safer and more complete design. However it may also be restrictive in some way, in the future.
Whereas the latter method is more open.

So i was wondering, if anyone has any experience with kind of thing, could offer and insight or suggestions.

As mentioned above, I used a separate class to contain the vector methods because I didn't use a custom Vector class. I suppose, though, that if I were more interested in dealing with the individual vectors rather than doing operations on Particle objects, I'd create a Vector class with the methods contained inside. That way you wouldn't have to worry about compiling a second class whenever you're compiling your Vector class. You might want to make those methods static, though I'm not sure what difference it'd make memory-wise.

One final consideration would be whether to have separate variables in your Vector class for spherical, cylindrical, etc. coordinates. If you use these alternate representations often (without changing the vector) it might save on calculation time, but then again if you change this data often you'd have to change twice or three times as much data as you would for a simple cartesian vector object. I opted for having just the cartesian position info in my Particle class because I planned on changing the positions and velocities often.