Re: thought: "traditional" vs "programmer" math?...
- From: "BGB / cr88192" <cr88192@xxxxxxxxxxx>
- Date: Tue, 15 Dec 2009 09:49:31 -0700
"Achava Nakhash, the Loving Snake" <achava@xxxxxxxxxxx> wrote in message
news:1428ad89-7c65-46a7-90cd-1f0b6c79422b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'll give you a quick reply since I am quite busy.
On Dec 12, 2:03 pm, "BGB / cr88192" <cr88...@xxxxxxxxxxx> wrote:
after some recent exposure (to having taken a physics class), I have noted
a
few things, and wonder if maybe they can be commented on.
in particular, I am left thinking that, although both make use of math,
the
math of programming and the math of more traditional fields (such as
physics, and in math classes, ...) are different...
I am not claiming there to be any significant implications of any of this,
more just personal observations / thoughts.
<--
Always of interest, especially to those who teach, how people react to
what they are learning, so by all means, give us your thoughts.
-->
yep.
first observation:
traditional math seems to like to inline everything, producing potentially
big hairy expressions / ... and then either "simplify" or "solve" the
results (manipulating quite possibly a large collection of seemingly
unrelated "ideas" or "concepts" all in a single process).
<--
I was once the purest of pure mathematicians in terms of my research,
not in terms of my inabliity to wear any number of hats. I now make
my living as a programmer of sorts. I know perfectly well what an
inline function in C++ is, but it is not clear to me at all what you
mean by your remark. I would have to say that you are something of
beginner in physics and not yet even a beginner at what people who
actually do mathematics would call mathematics. There is nothing
wrong with this, of course. Everyone has to start somewhere, and
almost no one has a need to learn the spirit of mathematics as used by
a mathematical researcher, professional or otherwise. Mahtematics is
very different in spirit from the way you are taught algebra,
calculus, differential equations, and linear algebra, although all of
these can be looked and are looked at in the real spirit of
mathematics. It is just that a student's first exposure to these
subjects is just about never in that spirit.
-->
well, I don't claim to be really that much into mathematics here, mostly I
just think:
as a programmer I may often end up using math (in the sense of operations
and calculations) to solve problems.
nevermind whether or not one understands it as such, or tends to grab most
answers to math-related problems by doing web-searches for a relevant
answer...
I personally beat together a rigid-body physics engine mostly through the
powers of Wikipedia, Google, and trial and error...
granted, admittedly, it is not a very good physics engine...
an example would be a system consisting of several rigid bodies attached
via
strings. in this methodology, one would combine them all into a single
mass
of expressions encompassing both the ridig bodies and the strings, as well
as possibly whatever "inclined plane"/... the happen to be resting on.
however, in the usual programmer strategy, one would break the system down
into more fundamental parts (individual operations / functions), and then
connect these parts together, and the overall result will tend to be
"emergent".
for example, one creates a few functions for the behavioral interactions
between the body and the incline, between the string and whatever it is
connected to, ... and it all works no matter how one positions the bodies
or
connects them together.
<--
You are talking about physics here, and seem to be comparing it to the
object-oriented programming paradigm. I think you are quite wrong in
what you are saying above. I know a rather minimal amount of physics,
but when I was taught things like balls rolling down an inclined plane
or combinations of oscillating springs, or whatever, I learned a
relatively small number of basic principles and a few rules of thumb
for combining them, mostly derived from common sense rather than from
the sort of axiomatic approach we mathematicians tend to favor. The
first principles were two of Newton's laws - F = ma and every action
has an equal and opposite reaction. That was followed by the
principle of supersition (vector additivity of forces), how to break
forces into a pair (or triple) of forces in perpendicular directions,
some ways to deal with string tension and whatnot. Then there were
the descriptions of forces for a variety of situations like gravity
near Earth, gravity in general, springs, frictino, etc. These
relatively few principles could solve a huge number of problems. This
is somewhat analogous to your idea of creating a few functions and
ways of connecting them. I don't know what you mean by emergent, so I
am guessing. It looks to me as if you mean you plug in a bunch of
inputs and get an output. In physics problems you can often derive
closed form expressions for kinds of systems dependent on a small
number of parameters through the use of the above principles. That is
considerably superior when it happens to simply having particular
solutinos emerge from particular starting conditions.
-->
I took a physics class, and the teacher spent a large part of this writing
out stuff using predicate logic, set theory, ... and going on about proofs,
....
most of the tests didn't expect one to actually calculate anything, but were
more like:
here is a setup and some criteria, prove or disprove that this is the case.
I was a bit screwed over, as I had figured before hand that it would be all
more about combining prior-learned expressions to calculate particular
results, ...
it is like, programmers don't use proofs, stuff works or it doesn't work.
one need not worry about things like why ABA^-1 works with both matrices and
quats, or for scalars ABA^-1 = B but for others ABA^-1 != B.
these can be observed, but most often it does not matter so much why.
it not even really need to be a concern that scalars and complexes are
commutative but matrices and quaternions are not...
these are what are here, and this is how they are used...
OTOH, if one changes some little detail in a more "traditional" approach,
then seemingly it causes changes which "cascade" and apparently change
nearly every expression in the system.
<--
Yes, physics is stuck with explaining the real world world which can
be remarkably messy. Sometimes small changes in conditions really do
product huge changes in results, and the mathematics had better
incorporate that complexity or be useless.
-->
yep, and software typically doesn't need to bother, since well-written code
will usually respond to the changes on its own.
in this case then, it is "hard coding" things which is the problem.
hard-code as little as possible, and interconnect parts with consistent and
generic interfaces, and the system is far more dynamic.
if programming were done the same way as I had observed physics being done,
it is very likely that the code would have been unusably brittle and the
programmer would overwork themselves trying to address every possible set of
inputs and edge cases...
granted, something vaguely similar happened in my case when writing a C
compiler, and this thing turned into a bit of a mess (particularly in the
codegen). the codegen is sadly inflexible and is a big mass of tangled
string and terrible hacks.
this is nearly the inverse of the programmer strategy, where once these
general-purpose functions are created, one very rarely needs to change
them
again, it is merely a matter of how one puts them together.
(and, the system as a whole is primarily the result of the interactions of
some open-ended set of small "atomic" pieces...).
<--
I have never seen that work as well as it has been advertised to work,
but I do not really have the background and experience to assess this
accurately.
-->
granted, it is very difficult to get right, as in practice code very rarely
reaches this level of atomicness...
far more often, one ends up with a big tangled mess...
or, as is typical with many OO projects:
some huge monstrosity of a class heirarchy...
somewhere along the lines, someone has an idea:
why not make everything inherit from everything else?...
then there ends up being a project architecture which could be stated in
analogy as "a bunch of jello stuck onto a tree made of string and
toothpicks...". a good hit, or a break in the tree, and the whole structure
collapses...
my personal preference is to break down the project macro-structure into a
large number of independent components as well, where some may be C++, and
others in C, and where I can tear the project apart and put it back together
in a different way (or maybe even bolt components onto a different
codebase), and it all still works.
second observation:
there would seem to be a difference in the particular "tools" one will use
to work through a problem.
for example, a programmer may note "well, I have some code for quaternions
and matrices, may as well just use these...". so, we have things like
quats,
matrices, and vectors, all over the place for sake of doing relatively
"simple" operations, such as rotating an object.
the simplest strategy, then, is to use the most capable tool, such as a
matrix or quaternion, and use this (regardless of where the object is, how
it moves, ...).
another person, OTOH, would be like "well, this particular object
undergoes
a coplaner rotation, so I am going to use an angle here". an angle may be
chosen for one object even though another object in the system may not
rotate in a single plane.
<--
I agree with you that people in different professions generally look
at their problem spaces in quite different ways, but you appear to be
putting down the way those who are not programmers conduct their
business. To me, the reason that we look at things in different ways
is because we have different goals. A mathematician wants to prove
things that haven't been proved before or to understand why the things
that have been proved are true, at a minimum by following the proof,
and learning these things from different angles is often quite
helpful. The physicist is trying to model the actual real world any
way he can that gives agreement with experiment in all possible
experimental tests. The physicist also likes to have models he knows
are inaccurate but are simple enough to be tractable, because that is
frequently of great use in practical applications. Examples of this
are the oscillation of a pendulum under the assumption that x = sin x
(in radians), This is clearly false, but the simplifying assumption
makes the problem much easier to solve and is pretty close when x is
under 10 degrees, whatever that may be in radians. Foucault's
description of his pendulum also uses some gross approximations, but
his result is close enough to reality to predict the pendulum knocking
down all the pins laid in a circle and is pretty accurate about the
timing as well. This drives us mathematicians crazy, but there is a
actually a good motivation behind it. There are so many diffferent
goals in programming - database, numerical solution of partial
differential equations, printing paychecks, factoring numbers, etc. -
that it is difficult for me to find a common mindset among all of
them. In any field, if you are working on a problem for which there
is no model - that is the norm in mathematics (no pun intended.
really.) you use whatever attracts your attention, and you keep trying
things until they work. Teachers occasionally try to instill this
mode of thoughts into their students, and maybe your above example is
an example of that and maybe not.
-->
granted, I am not really sure...
it is a bit different than the usual mindset:
"run forwards and do it";
or "make it work".
often, "make it work" is the primary goal, regardless of the problem at
hand.
how or why it works is then of lesser importance.
similarly, a programmer will generally and consistently use, say, one
particular system for expressing translations and rotations (say,
vectors+quats, matrices, ...), whereas a person using a more traditional
strategy will consistently fall back to using piles of rather
obtuse-looking
trigonometry-based solutions...
then again, it can be noted that they also like doing everything by hand,
and I have observed how quickly and terribly wrong something like a cross
product, or normalizing a vector, can go when trying to do it using
traditional means. but then I am left to wonder: why do it this way in the
first place?...
<--
Yes it is easy to make computational mistakes. We like to use
automated tools, too, and frequently do so. However, when teaching,
we need you to get a feel for the meaning of what is being done, and
that can only be done by making you go through the process, at least
for a while. Once you have it down, you don't have to do it again.
Also, when you are taking the cross-product of expressions rather than
numbers, there are fewer automated tools, and they don't necessarily
give you the result in a usable form even if it is correct.
-->
yeah...
hence it is typical in my experience to think of the cross product itself as
the operation, rather than look at the details of what goes on on the
inside...
if one thinks of these in terms of individual components, then things turn
malevolent...
similarly, there are lots of derivatives and integrals used, even though
personally I have not seen much need to use them in practice (and, infact,
dividing by very small numbers is very likely to lead to very big roundoff
errors...).
<--
Most of us never need to use the skill in doing integration and
differentiation that we pick up in a calculus class. Mathematicians
often need to use them. Physicists as well. Programmers generally
never. As far as rounding errors go, there is a huge body of research
in how to minimize rounding errors in a field called numerical
analysis. If you are a pure mathematician, this is generally
irrelevant as we want exact answers, and approximate answers, such as
you generally get by programming math problems of certain sorts (like
solving differential equations) are excellent for developing a feel
for what is happening, but useless for proving anything, and what we
really want to do is prove things.
-->
granted...
programmers don't really use integration, if anything, because it is not a
very efficient means to solve most problems (that, or it amounts to a simple
summation).
similarly, it is not as much use to use a derivative, since usually
something like lerp or a b-spline can accomplish the same task, but without
a division or potentially large roundoff...
also: people in the more traditional camps seem to not know of such things
as bezier splines (for example, for calculating intermediate values), even
though they seem to be common-place in software (and seem to be plenty
mathematical enough), ...
granted, it could all just be programmer ignorance speaking here, I don't
know...
<--
I think most of this is your ignorance, but it is good that you are
thinking of these things and trying to put it all together. I have a
sense that you are missing the forest not for the trees but actually
for the leaves. It is always that way when starting, because you are
presented with a mass of detail and don't yet know enough to put
together the larger view. You teachers should be helping to do this
as they teach, but that skill is by no means universally present among
those of us who teack.
-->
yes, ok.
actually, it has been a fairly long time since last I had any sort of
math-related classes (~ 5 years), then I ended up taking a physics class
thinking I already sort of understood the material (after the physics engine
experience), but turned out to have been terribly wrong on this front...
(for a large part of the class, I had little idea what was going on, and
from what I could tell was at a bit of a disadvantage...).
the next semester, I will be taking a math class, and ammusingly a few
introductory programming classes.
luckily, at least the programming classes should not cause any real trouble,
granted they are in C# (and I use mostly C and some C++), and the classes
are stated as using DirectX, and I personally use OpenGL.
but, alas, this should not be too much of a gap, ...
.
- References:
- thought: "traditional" vs "programmer" math?...
- From: BGB / cr88192
- Re: thought: "traditional" vs "programmer" math?...
- From: Achava Nakhash, the Loving Snake
- thought: "traditional" vs "programmer" math?...
- Prev by Date: Re: probability problem
- Next by Date: Re: Bilinear abd n-linear maps: can we define uniqely on basis vectors.?
- Previous by thread: Re: thought: "traditional" vs "programmer" math?...
- Next by thread: Re: In effort to solve ax^5+bx+c=0
- Index(es):
Relevant Pages
|
