Re: [Phys-L] treating force as a vector ... consistently

[John Denker <jsd@av8n.com>]

On 09/15/2016 06:01 PM, Philip Keller conjectured:

> A force is a vector.

I agree.

> It has magnitude and direction.

I agree.

> I am not ready to ask if it has a "point of application".

Ditto.

> (I believe that the point of application exists.  I just don't know
> that it is a property of the force.)

Exactly.  Well said.

>  So I guess my question is: can a force have ANY other property or
> information assigned to it other than magnitude and direction?  It's a
> vector, but is that all it is?  In particular, where does the information
> exist that tells us which object a particular force is acting on?

Here's how I think about it:  There needs to be a higher-order construct.
There are several good ways of doing it:

1) If you want to be really mathematical about it, consider a set of ordered
pairs, where the abscissa is the name of the particle, and the ordinate
is the total force acting on that particle.  This defines a /function/,
which we can call FindForce.  Given the name of the particle, the function
tells us the total force.

Similarly we define a FindPosition function.  Given the name of a particle,
this tells us the location.  Since it's a pointlike particle, this must
be the point of application of the aforementioned force.

Similarly we define a FindMomentum function.

> In particular, where does the information exist

In the three functions.  There are three sets of ordered pairs.  The
sets contain information:
  { (name, force)    for all particles }
  { (name, position) for all particles }
  { (name, momentum) for all particles }

Each function can be tabulated.  For example:

        name		force (coordinates in some basis)
        ------		---------------------------------
	Buffy		( 1,  1,  1)
	Kendra		( 1,  1, -2)
	Faith		(-1, -1,  0)


======================================

2) Another way of thinking about the exact same idea, in the language of
computer programming.

  class particle {
  public:
    vec3 force;
    vec3 position;
    vec3 momentum;
  };

  particle Buffy;		// Buffy is an instance of the particle class
  particle Kendra;
  particle Faith;
  Buffy.force = vec3(1, 1, 1);	// initialize a vector in terms of components
  Kendra.force = vec3(1, 1, -2);
  Faith.force = crossproduct(Buffy.force, Kendra.force) / 3;

The idea is the same:  given a name, the compiler can help you find the
corresponding force.  It's also easy to find the position and momentum.

Let's be clear about the contrast:
 -- The Buffy object is an instance of the /particle/ class.
  It is a higher-order abstraction.  It has a position as well as a force.
 -- The Buffy.force object is an instance of the /vec3/ class.  It is a vector.
  We let this particular vector represent a force.

  A vector, per se, has magnitude and direction but *not* location.
  Given the value of the force, e.g. vec3(1, 1, 1), you cannot reliably
  tell what particle it belongs to.  There could be multiple particles 
  subject to the same force, so the mapping from force to particle is
  generally not a function.

=======================================

Newton's laws, as usually stated, apply most naturally to pointlike particles.

If necessary, larger objects (i.e. extended objects) can be represented as a
collection of pointlike particles.  An extended object can have different
forces acting on different points.

In most applications, very soon it becomes not worth the trouble to keep track
of force and point of application, and to think instead in terms of /force/
and /torque/.  This is especially true when you are considering net effect of
multiple interactions.

For extended objects, there are other complications, but let's not worry about
this just now.

> If this seems angel-on-pin, feel free to ignore.

IMHO this is fundamental and essential.  If we're going to talk about forces, we
ought to have a reasonably solid understanding of what they are.