#Questions on PAR001.poc
20 messages in this thread
ED,
I am a little rusty on my physics, but I don't understand the eqns of motion
you are using in PAR001.poc – in particular the ones in move_particles and
move_mass
The motion of a particle acted on by a single mass can be described as:
F = ma = (constant)*M*m/d^2, where m=particle mass, M=mass, d = distance
=> a = (constant)*M/d^2 and decomposing vector into orthogonal
components
ax = (a)* dx/d = (constant)*M*dx/d^3
You use ax (delta vx) = (constant)*M*dx/d^2 Why?
Working the other way around using your dx and dx(=M*dy/d^2)
we get that the particle acceleration a is:
a = sqrt(ax^2 + ay^2) = (constant)*M*sqrt(dx^2+dy^2)/d^2
= (constant)*M/d
Aren't we off by a 1/d here? I tried putting in the 1/d^3 in move_particules
and move_mass and the particles just spun off, I assume that means that the
initial rotational acceleration was too great for them to stay in orbit – but
like I said, I'm rusty on my physics, so I don't know what correction to make
to the particle initial state to put them in stable orbit.
Please feel free to correct me on this – I am NOT a physics expert, I am just
trying to remember what I learned years ago, but it bothers me when stuff
doesn't make sense to me.
I'm holding a kranky baby in my arms right now. I'll take a look tonight. (I am
typing with only one hand now).
Why didn't WinCIM tell me I had a message waiting? It always has before.
Ed K.
Hi Dennis.
I am glad you are looking into the inner workings of the particle system.
(I'll make the code easier to read the next time.)
I'm sorry I couldn't respond sooner. I am helping my daughter, and baby,
while her husband gets an apartment ready for them in Albany. I didn't
realize what I was getting into!
I didn't see anything wrong with the equations you derived. I want to check
more thoroughly before thanking you for finding the first bug! I should get
time to look into it in more depth in the next few days (famous last words
… there were two baby interruptions while writing this note!).
I was very happy when I was able to use my particle system to reproduce a
spiral galaxy (SPI05.ZIP) which was very similar to one in the article I
used for reference. It would really be interesting if it turns out that a
different law of gravity would also work!
Ed K
(The article was "Violent Tides between Galaxies" on pg. 38 of Scientific
American 12/73.)
Dennis:
You've got my appreciation and your money back! I've put in most of the
changes to fix the error you found, and I've been having a ball seeing the
effects produced by the "correct" gravity. Neat stuff! I'll be making a few
enhancements/fixes and E-mailing the new code. I'll probably leave the old
equation as an option, until I find out if 1GA29 (and others) can be done
with the real laws of nature. It's hard to believe that something that
realistic could result from wrong equations!
Many results, surprisingly, are similar to the ones resulting from the
wrong equation. I haven't had time to redo the spiral galaxy yet, but that
will apparently work using either equation. I've looked at the galaxy
article again; the authors of the article were careful enough not to claim
they had proven that gravity did it. Now you've helped find an alternate
possible explanation for spiral galaxies <g>.
I am still not an expert in Physics, but I feel a little bit closer.
Thanks again!
Ed K
Ed,
Just because a system doesn't use the "real" law of gravity doesn't mean
that it might not be superior for producing "interesting" particle
animations! I do think that it makes a better "proof" of spiral-arm
galaxies if it is based on "real" gravity though. And you thought you
weren't going to get any feedback!
By the way, you have said that you learned C from working in POCO – so
obviously you have worked in some other structured language before, right?
Your code is very well organized, the modularization is very good, I like
your use of meaningful variable names, etc. My only objection is that I
use a different convention for brace placement (that is an issue that rages
unabatedly among C prgmrs everywhere). This is a good example of how to
generate a flick entirely through code.
Dennis
<Ed, Just because a system doesn't use the "real" law of gravity doesn't mean
that it might not be superior for producing "interesting" particle animations!>
I am struggling with how to provide many options without overwhelming the
users.
Let me just dump some thoughts and problems as they come to mind. I can use all
the help I can get!
The program quadrupled in size when I added the capability to place the values
used at the end of the animation. A friendly user interface could easily
become 95% of the code and take up a lot of time that I could dedicate to
creative features. I would like to continue using the POCO editor for data
entry. It's an easy way to edit Poco, and seems equally well suited for editing
data, EXCEPT that most of the time it doesn't use a monospaced font. It would
be nice to be able to use one line for related values, such as the initial x
pos, y pos, x vel, and y vel for one mass. But, if the data doesn't line up in
columns, it becomes very confusing. It also wanted data entry to be obvious and
simple to reduce data-entry errors. (You might have noticed I like to align
the code to make certain types of errors stand out).
< And you thought you weren't going to get any feedback!>
I can't tell you how happy I was! Specially, since I may be discourang you
all. I can't respond as quickly as I want while I am helping take care of a
soft, cuddly baby, who goes crazy over particle system animations <g>. Please
don't be discouraged by my delays. All input I get from you, or the other
users, is very important to me.
<By the way, you have said that you learned C from working in POCO – so
obviously you have worked in some other structured language before, right?
Your code is very well organized, the modularization is very good, I like your
use of meaningful variable names, etc.>
I have done a lot of programming. I am still using C like PL/I, or REXX (used
in VM and OS/2).
I'll send this now and continue tonight. I think you can guess why I have to
stop!
Ed
Ed,
I would like to throw in ONE MORE programming style comment – a lot of people
like to keep everything to 80 columns or less so that they can print the file
and not be missing a lot of stuff that's off the right sid of the paper!
I must say that I can definitely understand your distractions – next week my
wife starts back at night school (taking 3 graduate courses, working fulltime
during the day also). So I am going to become a fulltime baby-sitter in my own
home – unfortunately, that probably means that my AniPro experiments will come
to a complete halt for 9 months until she graduates. I don't have much free
time to play at work, and my free time is going to be consumed as a "support
personnel" for my wife during evening, weekends, etc.
Now, to give you some feedback, I think that editing the POCO to change the
data values is reasonable – I agree that a lot of code would be requ'd to make
a fancy interface – at that stage it would be better to just compile it and
make it read a DATA file – which is something that we don't want to get into-
do we? POCO-heads are willing to wade into the code and change stuff to change
options, data, etc. In fact, I get the impression that if anyone UP'd a
compiled POCO utility and didn't provide the source for the POCO-heads to
browse thru he would be considered "elitist".
Later, Dennis
<print the file and not be missing a lot of stuff that's off the right side of
the paper!>
Paper? What's that? OK. seriously. Once a function is working, I string it out
horizontally. That way I don't have to scroll past a lot of code I don't need
to see any more. The editor I use, KEDIT, shows me only the first 132 chars of
each line. The rest only when I ask for it. I prefer to have as much "relevant"
data on the screen as possible (old age effects on memory <g>) and not have to
scroll up and down all the time. I'm sure you wouldn't want to see the code for
"printf()" all the time. I also didn't want to split my work into more thatn
one file, to keep it simple for my users. I feel bad enough that I force them
to edit the source code.
I was in 7-th heaven when I was able to run four simultaneous VM sessions at 96
rows by about 140 columns under OS/2 (before I retired from IBM last year).
KEDIT is a PC version of XEDIT, the editor I used then, and I like most (I am
as good with it, as I am with AniPro). I am slowly converting all my XEDIT
macros to KEDIT and modifying them to help me work with C-code instead of
REXX-code. With these macros I go from horizontal to vertical style as needed.
But until I know all of C<g>, there will be manual intervention required. Until
then, I'll be careful not to obscure the important sections of code.
< that probably means that my AniPro experiments will come to a complete halt
for 9 months until she graduates>.
< … time is going to be consumed as a "support personnel" for my wife during
evening, weekends, etc.>
Her gain is my loss!<g>.
< and make it read a DATA file – which is something that we don't want to get
into- do we?>
I think of the POCO program as THE data file (with some other stuff thrown in).
The "compile-link-go" feature of POCO allows sophisticated users to generate
data for a variety of problems by editing my C-code. Unless I develop a
"particle/mass specification language" of my own, I must let the users edit the
code. I just have to make sure that knowledge of C is not necessary to enter
data for a useful set of particle system animations.
Ed K
Ed,
C is a very powerful language, but it is also very easy to write very cryptic
code. In fact, some people have said that in the hands of some people
C is a read-only language. I am an engineer and also a programmer. Before
coming to my current (small) company, I worked for a major company, and I spent
time in the Applied Mechanics Computer Technology department, where I wrote in
FORTRAN on a VMS system. We wrote pieces of a major software system (about
400,000 executable lines of Fortran), and we quickly learned to do it right
(spelled maintainable). At my current company we have a lot of "hack"
programmers who know nothing about proper progrramming. I am responsible for
"maintaining" a fortran program which is about 500 pages of source code, with 1
and 2 letter variables, and not a single comment in the code (and no external
docs). Since the guy who wrote it left the company I told my boss if we find a
bug, it's quicker to re-write from scratch than to figurre out what the !@# the
old code is doing. The only good news is that the guy didn't know C, which
would be even worse. So anyway, I have been on a "software quality" crusade
for about 2 years, so I apologize if you sometimes catch some of that by
accident. Believe me, I wish my programmers wrote code that was as
self-documenting as yours!
P.S. I really HATE it when I blow a punchline – above it is obviously
supposed to be "a write-only language" instead of "a read-only language".
P.P.S. I got the POCO, I'll try to find time to look it over!
Ed,
I've had a chance to take a quick look at the POCO – assuming that your
question in particles_orbiting of why does G==1 work is NOT rhetorical, I
thought I'd respond:
Basically, the stable orbital velocity can be calculated from the eqns for
centrifugal force on the orbiting particle, as:
Fc = m*(Vt)^2/(gc*r) = m*at/gc where m=particle mass, Vt = tangent veloc
at = normal accel (I can't type), r= radius
cancel m and gc and we get an = Vt^2/r
Now, we know that the normal accel (an) is supplied by the gravity attraction
of the particle by the mass, and from our previous discussions:
Agrav = M/d^2 (assummed G==1 for this)
=> An = Vt^2/r = Agrav = M/d^2
=> Vt = sqrt(M/d)
So G==1 works for calc stable orbital velocity, because G==1 was used to
calculate gravitational attraction and that is what determines the stable
velocity. If you used G=2 for gravitational attraction, you would have to use
G=2 for calculating stable orbital velocity to keep the particules in orbit –
you can use whatever you want, as long as you are consistent.
The other implicit assumption in your code (I know you know this, but let me
state it explicitly – suggested comment in code) is that each frame represents
a unit time, such that:
v = v0 + a
d = d0 + v where v = velocity, a = acceleration, d = position
Have a nice day!
Dennis
Ed,
<C is a very powerful language, but it is also very easy to write very cryptic
code.>
My programming style is the result of years using APL. I became accustommed to
having all the code visible at once. One of the first programs I wrote in APL
was "An Adaptive Query System," a program that learned by holding conversations
with users. It maintained a data base containing what it knew. It was able to
recognize phrases that were similar to those in the data base. It was done (by
a beginner) in about 40 lines.
With APL,
< re-write from scratch >
is the accepted practice. The programmer, however, must provide comments that
formally describe what a routine does. I am looking at a 5 line APL program
right now. The output from this routine is computed on a line containing 24
characters. I'll try to give you an idea of what that line looks like:
R<1 "drop" (Z "or" 1 "rotate about the first dimension" Z < V "not eq" ' ')/V<'
',V
"<" is assigment (arrow pointing left), used 3 times
There are no blanks, except between single quote marks
"rotate about the first dimension" is a circle with a vertical line through it
"not eq" is an equal sign with a slash through it
"or" looks like a small V
"drop" is an arrow pointing down
The comments describe this routine as:
Deleting extra blanks from a character vector (the input is "V", the output is
"R")
where extra blanks are:
– any blanks following another blank,
– any blanks preceeding the first non-blank character
– any blanks following the last non-blank character
The other four lines are comments and code to check that the input is a vector
containing character data.
<"a write-only language">
Good one!
<Assuming that your question in particles_orbiting of why does G==1 work is NOT
rhetorical>
Boy, you are really digging in. That was a reminder that I still had to check
that my guess, G==1, was correct.
Thanks for saving me time!
Ed K.
Some more stuff I didn't get to yesterday. Also, I just got E-mail from Frank
Kurta, who wants to know more about me, so I'll go into more detail.
<By the way, you have said that you learned C from working in POCO – so
obviously you have worked in some other structured language before, right?>
Not only that, but I've been in programming a long time:
1963 – Univac 1101 machine language
(Entered via paper tape). Around that time an assembler became
available (maybe SNAP: Symbolic Numeric Assembler Program or SOAP ?).
1964 – ALGOL on a Burroughs 220 (or 200?). It took a while before I
moved to Algol from machine language (similar to the way I want to
know all about the more primitive Animator before moving on to
more advanced animation programs like 3DS.)
1965 – FORTRAN on a 1620 and later on a 7090.
1966 – 360 microcode and an interactive version of FORTRAN (I think it was
called QUIKTRAN).
It used from a typewriter! Unique, because programs in that era
where usually submitted on punched cards to a computer center.
1968 – FORTRAN and everything a 1620 could do.
I spent a year as a consultant to the University of Costa Rica.
Their first scientific computer (a 1620) was about to arrive and
a Computer Science school was to be created (the BID, Banco
Internacional del Desarrollo, would only provide funds if an
American advisor was hired for a year).
BTW, the other day I looked at "Problems for Computer Solution,"
a book I used in Costa Rica, to see if it had anything on Gravity.
1969-70 – PL/I
which then was already structured.
It introduced (to me anyway) two (new?) features: "structures"
and pointers. Instead of braces it used "BEGIN"/"END" blocks and
"DO/END" blocks. Local and global variables were used almost the same
way as they are in C. You could compute factorials recursively,
for example, with several instances of the "same" variable being shielded
from each other. (I never went back to PL/I so I don't know what it is
like today.)
– And around then, APL.
About a quarter of a century later it is still the language I like best.
71-75 PL/S, 360 assembler.
1976 – MOS 6502 assembler (I wrote an assembler for it using APL).
The power of this microprocessor led me to write a memo (19 pages
and fifty-five references) announcing the arrival of "distributed
processing" to my management. I recommended that we migrate our
electronic design automation (EDA) programs to networked minicomputers
(like release 3DS did recently <g>).
The minicomputers I recommended were the IBM 5100 and, later, the
to-be-unannounced Series/1. Remember that this was five years before
the era of the IBM PC, and a few years before the first Apple appeared.
I have copies of this memo and most of the other stuff I am mentioning.
I can send copies to anyone who wants them.
1978-More APL.
Published article "APL and Graphics" in Byte, and did two covers for
Byte (April and Sept) using APL.
1978 And even more APL.
When I saw the 4/78 cover of Scientific American by Mandelbrot, I called
him
in what was to be the first of many calls over a 4-month period. I have
boxes
full of fractals that I created then with APL.
81 BASIC
on one of the first IBM PCs. And later some Pascal.
More later.
Ed K
>> More later.
Fascinating work history Ed. I can't wait to see what madness you produce when
you dig into the more "advanced" 3DS arena.
– Dave
<Fascinating work history Ed.>
Thanks Dave, but that was just the software side of my work history <g>.
<I can't wait to see what madness you produce when you dig into the more
"advanced" 3DS arena.>
Neither can I! Retirement has freed me from schedules and planning and I have
found that I can't predict when I am going to be doing what.
I bought the Watcom compiler months ago to try my hand at IPAS. It's still
sitting on a shelf! It looked like I was going to be using it soon. But then,
what about those books on astronomy I just bought? <g>
One advantage about Autodesk never coming through with work, is that I remain
free to choose ("the grapes were green anyway" syndrome?).
Ed K
>> But then, what about those books on astronomy I just bought? <g>
I downloaded your 1GA29 flic and I'm simply amazed. I can't imagine what you
will come up with using your new astronomy references! Nice work!
– Dave
Ed,
Wow. I too am looking forward to seeing such amazing code 3DS. I'm sure you
could get some really amazing stuff done integrating your creativity and
persistience with 3DS' resources. I never thought so much stuff could be done
with a "little 256 color, 2d animation program" (my first impression) You've
shown that to be untrue.
JNJ
(BTW- PMJI, I thought it was something to do with the Personal Anim. Recorder..
<g> PAR..)
<Wow. I too am looking forward to seeing such amazing code 3DS. I'm sure you
could get some really amazing stuff done integrating your creativity and
persistience with 3DS' resources. I never thought so much stuff could be done
with a "little 256 color, 2d animation program" (my first impression) You've
shown that to be untrue.>
Thanks! But how do I stop adding features to this beast, and move on?
< Personal Anim. Recorder.. <g> PAR..)
Suggestions (3 letter max)? And while you are at it, how about a better name
than "My Particle System"?
Are you still doing robotics?
Ed K
hehe, never got any robotics stuff. I'd love to play, but I don't have
anything around to do it with. Someday I'll probably get that lego kit and
pretend I'm 12 again. <g>
>> Someday I'll probably get that lego kit and pretend I'm 12 again. <g>
Don't laugh, now that my brother has gone off to the Marines, I get all my old
Lego back -AND- all his stuff, too! Now to find that robotics kit…
– Dave
Go to it! (if you don't mind modeling in reality <g>)