Natural Science Forum / Physics / Research / May 2008

In article
<2ee95a6f-2ed3-4370-862d-b3e81e4354a7@w8g2000prd.googlegroups.com>,
pioneer1 <1pioneer1@gmail.com> writes:

Number.

The idea of proportionality is closer.  In fact, this is essentially the
definition of intertial mass (the proportionality constant between force
and acceleration).  Depending on the context, one could substitute F for
ma; after all, they are equal.

I think no-one yet really understands what your question is, though.

You question suggests you think that physics theories already have a
natural computer language representation, but the best hope is to model
some only aspects.

No: F is a physically measurable quantity. By fixing a unit of force
u_F, disregarding the direction that force may have, F can be measured
using a number r, as in
  F = r*u_F
In theoretical physical theories, r is modeled as a real number (needing
differential equations), and in practical measurements, an approximation
thereof.

The formally correct version of this equation is
  F = k m a
where k is a dimension-less constant depending only on the units chosen
for measuring the physical quantities force, mass and acceleration; by
suitable choice of measurements units, it can be chosen to be equal to 1.

  Hans

Wandering a bit from the OP's question, but I'd think that
units are more fundamental than numbers.  Just because
there are many different/equivalent "representations"
(e.g., theoretical units), doesn't mean units aren't
fundamental.  On the other hand, there are no directly measurable
numbers, per se, in nature (though there are dimensionless ratios).
You can't measure "one", just one apple, one erg, etc.

Numbers, at least vis-a-vis physics, are a completely human
construction (despite Kronecker's claim that "God invented the
integers").  We find numbers very useful to describe measurements,
but maybe that's just because we first found numbers useful to calibrate
our measuring instruments in the first place.  And then we find numbers
useful to formulate theories correlating our already-numerical measurements.
    Now, I agree there are many holes in the above reasoning,
and I have zero idea how physics might be done without numbers.
But maybe that's just how human brains work.  To that extent, we're all
trapped in Whorf's "conceptual boat" (lots of google hits for that).

By looking for numeric-like data types that are physically fundamental,
I think the OP was mistakenly elevating numeric-like entities to a
foundational level they don't really occupy.  For a recent discussion
vaguely along these lines (though they aren't, as far as I can tell,
actually trying to do away with numbers), try
http://arxiv.org/abs/0803.0417/

In article
<afeec54e-fa8c-4303-b02e-e2ed7cc4f1c5@a5g2000prg.googlegroups.com>,
pioneer1 <1pioneer1@gmail.com> writes:

It is type number, not string.

Yes, in programming languages, there are various data types, some of
which correspond to numbers and some of which correspond to strings.

I tried to answer, as best I can, what I think you've been asking
(both here and in your parallel thread) in the comp.theory ng.
So I'll reproduce that answer (modulo a few typos) below...

Well, yes, that's kind of correct and I think it answers the
question you were originally asking.  Context is important,
but it's a little more complicated than I think you're suggesting.
    Consider your F=ma and alsp consider the
electrostatic force F=qE on a charge q in an electric field E.
That's two different contexts for F, in the following way.
    F=ma is kind of "definitional".  If you see a mass m
with an acceleration a, then you infer that there must be
some force F=ma somewhere, somehow, of some sort, acting on m.
But you have no clue what F is or where it comes from.
In this sense F might be called a "label" (like you said
in a previous comp.theory post) in the F=ma context.
    F=qE is a "quantity" (like you said in that same post).
If you put a charge q in an electric field E, then that
charge q will experience an electrostatic force F=qE.
( Now, if that charge q also has mass m, then you'll
see an acceleration given by F=ma=qE so a=(q/m)E. )

Note that the physical units of F (force) are the same
regardless of "context" (in the above sense).  But your
"data type" might not be invariant.  That makes it
difficult for me to see what purpose it might serve.

OK, here's an attempted answer to the original question from someone
who is a C++ expert, but also knows a reasonable amount about
maths and physics...
-----------------------------------
By "string", I assume you mean "array of char" or "array of byte".
Yes, this is of different "type" than (say) int, float, etc.

Force, mass, acceleration are all distinct types. In C++, one might
represent them like this (sketch only) :

class Force;   // Forward declaration.

enum Units { SI, NATURAL, ..... };

class Acceleration
{
       float    my_val;
       Units   my_units;
   public:
      // constructor(s), etc, .....
};

class Mass
{
       float   my_val;
       Units  my_units;
   public:
       // constructor(s), etc, .....

    Force    operator*(Acceleration const &  a const;
                 { return  Force(....construct from <my_val>
                                           times <a.my_val>, and
                                           correct for respective
units....);
                 }
};

class Force
{
         ... similar....
};

Then one can write stuff like
Mass   m(....);
Acceleration  a(....);
Force  f = m * a;   // Initialization.

or

if (f == m*a)
{
  .....
}
else
{
   .....
}

One can of course make all this
far more sophisticated.
--------------------------

The important thing is to maintain a clear distinction
between the abstract mathematical type (e.g., real number,
sequence of octet, Lie algebra generator, Group element,
vector space, dual vector space, etc, ....) and the respective
concrete representations in terms of programming
structures. The abstract algebras/relationships in which
the abstract types may (or may not) participate in can then
be expressed in your program via C++ types and
operator overloading, etc.

Hope that helps.

On Apr 12, 9:30am, Bossavit <bossa...@lgep.supelec.removethis.fr>
wrote:

Thanks for the references. Unfortunately, except for the first one I
couldn't find them online. Do you know if they exist online?