Re: Mathematical model of inertia


MobyDikc wrote:
PD wrote:
MobyDikc wrote:
PD wrote:
MobyDikc wrote:
PD :
MobyDikc wrote:

<snip>
Can you show how to use "F = ma = 0" and describe the state of the
system at 3 seconds, using only mathematics.

<snip>
The math is merely concrete shorthand for longer statements involving
terms with definite meanings.


Would you agree with this then:

The F = ma statement is not a model. It's a statement, descriptive one,
about a model, one that contains much more than just the mathematics.
It contains:

For example, we need to define a "system", we need to define
"interaction", and we need to define "objects" and we need to link the
properties of those objects that we have to keep track of in the
context of the interactions that may occur between them. For example,
if we are only concerned about the linear motion of the objects, then
we don't have to worry about their extended dimensions or the
distribution of mass around their centers, but if we're concerned about
their rotation, then those properties are important.


Since it seems pretty obvious that many different models can be built
based on F=ma, then F=ma is not an actual model itself.

Agreed?

Yes, I would agree with that.

Good news.



Now take a look at my algorithm:

* Set the initial conditions =======================================

* The parameters are X, Y, Z, dX, dY, dZ, and mass
local aObjects[3]
aObjects[1] = create("Matter", 0, 0, 0, 1, 1, 0, 20)
aObjects[2] = create("Matter", 24, 24, 0, 0, 0, 0, 5)
aObjects[3] = create("Matter", 76, 20, 0, -1, 1, 0, 20)


* The laws of motion ==============================================

******do while .t. && alternate mode of running
for t = 1 to 40

* Look at every object
for each oP in aObjects

* In motion stays in motion
* At rest stays at rest
oP.X = oP.X + oP.dX
oP.Y = oP.Y + oP.dY
oP.Z = oP.Z + oP.dZ

* Look at every other object
for each oP2 in aObjects
if oP <> oP2

* Find its distance
nX = oP.X - oP2.X
nY = oP.Y - oP2.Y
nZ = oP.Z - oP2.Z
nD = SQRT( nX^2 + nY^2 + nZ^2 )

* See if we rammed into it
if nD < 1

* If so, swap momenta
nMX = oP.Mass * oP.dX
nMY = oP.Mass * oP.dY
nMZ = oP.Mass * oP.dZ

oP.dX = (oP2.Mass * oP2.dX) / oP.Mass
oP.dY = (oP2.Mass * oP2.dY) / oP.Mass
oP.dZ = (oP2.Mass * oP2.dZ) / oP.Mass

oP2.dX = nMX / oP2.Mass
oP2.dY = nMY / oP2.Mass
oP2.dZ = nMZ / oP2.Mass

else

* Find the force of gravity, then accelerate
nG = 6.67300 * 10^-11 * ((oP.Mass * oP2.Mass) / nD^2)
nG = nG / oP2.Mass

nX = nX * (nG / nD)
nY = nY * (nG / nD)
nZ = nZ * (nG / nD)

oP2.dX = oP2.dX + nX
oP2.dY = oP2.dY + nY
oP2.dZ = oP2.dZ + nZ

endif
endif
endfor
endfor
******enddo
endfor



* Print the final state of the model ===============================

for ni = 1 to alen(aObjects)
?"Object " + tran(ni)
?"X = " + tran(aObjects[ni].X) + space(5) + ;
"Y = " + tran(aObjects[ni].Y) + space(5) + ;
"Z = " + tran(aObjects[ni].Z)
?"dX = " + tran(aObjects[ni].dX) + space(5) + ;
"dY = " + tran(aObjects[ni].dY) + space(5) + ;
"dZ = " + tran(aObjects[ni].dZ)
endfor



* Object Structure for Matter ======================================

define class Matter as Custom
X = 0
Y = 0
Z = 0
dX = 0
dY = 0
dZ = 0
Mass = 0

function init
lparameters x, y, z, dx, dy, dz, mass
with this
.X = x
.Y = y
.Z = z
.dX = dx
.dY = dy
.dZ = dz
.Mass = mass
endwith
return

enddefine

* End of File ======================================================


I would say, that this algorithm explictly defines a system, and it
explictly defines the structure of an object (the DEFINE CLASS part at
the bottom). It also explictly defines the interactions between them:

if there distance is very close, they collide and impart momenta, if
not, they attract each other with the force of gravity.

But its defines them without English. It defines them with computer
code.

So I say, that my alogorithm, which is not codified in equations, is a
model, because you don't need English instructions and definitions to
use the algorithm to produce results.

What do you think?

I think it suffers from the same problem as the mathematical equations.
<snip>


At first we were saying that F=ma is not a model of inertia, but
something that a model of inertia could be based on.

No. The opposite. A model of a physical system might *include* F=ma,
but the model is based on things that are prior to that, and which are
the things I alluded to.


Ok, good.


Is this the problem you are refering to?

Because I think my algorithm is one of the model's you could build
based on F=ma and fG=G(m1*m2)/d^2

I don't see how it would suffer from the problem of not being a model.

It lacks the things the model needs in *addition* to the physical laws.


I disagree. I'll show you why below:


You do give many reasons why it is a poor model of Newtonian physics,
that is true. And I'll admit that. The algorithm is a failed attempt at
correctly modeling Newton's universe.

But it is still a model.

But not any more complete than F=ma, which is also not a good model.
As I said, your model makes no distinction whether the interaction
between the objects is elastic or inelastic or something in between,
and neither does F=ma. This is just one example of why both your code
and F=ma would fail as decent physical models of this system.



But my model does. Here are the relevant statements in the part of the
algorithm where it is comparing two objects, oP and oP2:

* Find its distance
nX = oP.X - oP2.X
nY = oP.Y - oP2.Y
nZ = oP.Z - oP2.Z
nD = SQRT( nX^2 + nY^2 + nZ^2 )

* See if we rammed into it
if nD < 1

* If so, swap momenta
nMX = oP.Mass * oP.dX
nMY = oP.Mass * oP.dY
nMZ = oP.Mass * oP.dZ

oP.dX = (oP2.Mass * oP2.dX) / oP.Mass
oP.dY = (oP2.Mass * oP2.dY) / oP.Mass
oP.dZ = (oP2.Mass * oP2.dZ) / oP.Mass

oP2.dX = nMX / oP2.Mass
oP2.dY = nMY / oP2.Mass
oP2.dZ = nMZ / oP2.Mass


This model explictly describes an elastic collision (right?) when two
objects are the same place.

No. Momentum is swapped in inelastic collisions as well. Moreover,
their being in the "same place" does not constitute an elastic
collision for a couple of reasons: 1) inelastic collisions also occur
when the two objects are in the "same place"; 2) both elastic and
inelastic collisions can occur when two objects approach but do not
actually make contact. An example of the latter is electron-electron
scattering or, for that matter, gravitational scattering of two massive
objects. I also note that you *assume* the two objects do not interact
until their separation is less than an arbitrary value of 1.

I'd say you have to have a broader grip on what a collision is, what
kinds of interaction there are, and what the difference between elastic
and inelastic collisions are.




A model of a physical system includes a number of statements that
declare which system properties are pertinent to the observation that
is intended to be predicted and measured, as well as those that are to
be ignored, not to mention carefully distinguishing whether you are
predicting the observable properties of the system or the observable
properties of the *parts* of the system. You have to lay down the
description first, even before you can decide which laws of physics you
will apply in understanding the behavior of that system, whether you
apply those laws with code or with mathematical symbolism.

And again, I think that my algorithm does that for itself.

It contains a class definition of the structure of matter that contains
all the observable properties. Position, change in position per
iteration of the program (taken to be a second), and mass.

Note you are taking the objects to be defined by the positions of their
centers only. You take no note of internal structure and whether any
energy can be absorbed (or delivered) from that structure. You have no
labels indicating rotational coordinates of the objects, implying but
not saying that rotation is irrelevant to the parameters you want to
use to describe the system. You assume that the two bodies do not
interact at all until they are within some impact parameter of each
other. Do you see all the assumptions that you make that you have *not*
demanded be true of the system in general?


Absolutely.

More perfectly good reasons why this is a poor model.

But the accuracy of my model was not what we were talking about.

We were talking about where or not it is a model.

Have I persauded you that though my model is poor, it is a model?

That's an extremely weak statement. A circle painted blue is a model of
the Earth. That doesn't mean that it is a useful model for the purpose
that it was built for. This is my point. *After* you have established
what it is you are trying to describe, then you can build a model that
will serve that purpose. Calling something a model without defining the
purpose of the model is essentially a useless label.

PD



define class Matter as Custom
X = 0
Y = 0
Z = 0
dX = 0
dY = 0
dZ = 0
Mass = 0
enddefine

.

Quantcast