How to calculate (almost) anything, and I invented a word!

[STxAxTIC]

Hello all,

So this post will be the summary of several topics I've raised recently, namely: (What this doesn't include is anything about geometric intersections, so all the recent circle/line/ellipse stuff is different from this. Same goes for the vector field simulator or anything else I recently posted.)

Faster trig functions: tables and interpolation
https://www.qb64.org/forum/index.php?topic=2125.0

A Two-Roads Problem
https://www.qb64.org/forum/index.php?topic=2138.0

Pendulum Motion - Can you fix this code?
https://www.qb64.org/forum/index.php?topic=2180.0

Physics Simulations
https://www.qb64.org/forum/index.php?topic=2186.0

All of that stuff was just leading up to, and is contained in, my latest set of notes that now exists as a PDF. I called this study "Mechalculus" It's the blend of "mechanics" and "calculus", pronounced like you'd say "Metallica". So "Mechalculus". I totally invented this word, even Google realizes it (see two screenshots below).

Why post this here at all? Because almost every single game, simulation, approximation, and so on, especially those posted around here - has some coupling to applied calculus, whether the coder knows it or not. Here we formalize, and in all senses, improve upon what might be the "intuitive" way to solve a problem. This goes over many many things, and it builds linearly. I start by defining what an equation is (some of you may have heard of these), and then start laying down definitions.

If you aren't sure what vectors are, you might want a primer on that:

http://barnes.x10host.com/vectors%20and%20trigonometry/Vectors%20and%20Trigonometry.pdf

Otherwise, I delay no further. I bring you:

Mechalculus

http://barnes.x10host.com/mechalculus/Mechalculus.pdf

(I will be adding applications as time comes. Let me know of any typos. I'll be fixing up the grammar a little but the equations had better be perfect.)

[Pete]

Ya, so what? I created a one-size fits all (calculates dimensions and then shrinks or expands to any cup size) brazer.

I bring you the...

Alge-bra

Pete

[OldMoses]

Very timely, for the stuff I'm trying to do. Downloaded and thank you. Now to wrap my miniscule brain around it, I only need a small cup alge-bra at this point...

[Pete]

No worries Andy; you're a fast learner. I'm sure you'll be up with us big boobs in no time! ;D

Pete

Edit: After reading all 41 pdf pages... What? NO APPLICATIONS???!!! I read all of that , and there's nothing to apply it to? &*^&* ^**^%**&^( (!!!!

It's interesting documentation, in that it starts out defining terms for a complete novice, and three sentences later loses just about anyone who isn't in college any more. Well, I actually do love the concise approach, but I'm left wondering who the target audience is supposed to be. Is this for college students already finished with calculus courses? 

[STxAxTIC]

Good question Pete.

The only calculus equation is the derivative - slope at a point, and that doesn't happen until page 8. So it really only requires that you attended the first few classes and dropped, which I think covers many. This practically explains that concept too, its really self-contained if you read slowly enough. Nothing should come out of right field. Same goes for the matrix stuff. If you've seen numbers, and played with blocks, you can grasp what I say about matrices. It's written very carefully. One may need to write and scribble notes in order to read this.

[OldMoses]

I can attest to the coding power of this matrix math stuff. I've lately been trying to work with R3 vectors and working on a routine that has one spaceship unit as a "chaser" maneuvering in 3 dimensions to intercept another unit that is the "runner". The chaser has to accelerate "pedal to the metal" fashion until it gets close enough that it must decelerate in order to match the runner's vector upon arrival. It also has to respond to changes in the runner's vector.

Well,.... that one hasn't been working so well as the chaser keeps overshooting and having to turn around if the runner is mostly stationary. It ends up zipping back and forth like it's on a spring, but...

The part that does work, moving towards and closing with the runner, I've been able to condense into much tighter code using basic matrix math. The polar coordinate approach worked as well, but used vastly more complicated code. I feel like I'm almost there and just missing some essential point.

I've seen folks trying to do the same thing, but their code is usually written in C++, which I find even more incomprehensible than linear algebra.  I'm just a BASIC guy recently clawing my way out of SCREEN 0. ;)

[STxAxTIC]

Hi OldMoses

So this line riiiight here:

until it gets close enough that it must decelerate in order to match the runner's vector upon arrival. It also has to respond to changes in the runner's vector.

The part "on arrival" might wanna be replaced with "before arrival". This will get rid of the weird oscillatory motion at the end, and also be open to when the target velocity changes. The dirty way is to just reduce speed as you get closer, limiting to delta V=0 when you get there, kind of like a shock absorber. However the way you spell this out, its a dead-ringer candidate for derivative matching, just like the two-roads problem detailed in a few places around here. In this analogy, your present trajectory is one road, your desired trajectory is the other road. Okay, just replace "road" with "the ship's past position".

Literally it's like this: If your ship is at one position, with a given slope, and you need to get to a new position and a new slope, guess a polynomial:

Y = A + Bx + Cx^2 + Dx^3

Choose A, B, C, D so that y and y' match at both points x1 and x2. Refresh this calculation every millisecond or so and you will have a terrifying chase-me-down AI. Make sense? (Oh and you want this to be 3D so you have to extrapolate this idea out into a new dimension, which if you already know what's up with vectors, is trivial.)

[OldMoses]

My HS algebra teacher used to throw erasers at me. ;)

Actually; it being a utility program for a turn based RPG more than an actual computer game, the dirty way would suffice, given that the primary purpose is to get the vessel within a "target lock" range of about 1/2 light second (150,000km) or less. Precise vector matching wouldn't even be necessary, so long as it's in the ballpark. As you say, I need to start braking thrust before arrival.

The application (which I just updated) is expanding on an old table top role playing system which used to track ships on paper in 2D, with static planetary details and used simple time/distance/acceleration equations to travel to stationary destinations. What I'm doing has upped the ante with 3D space and dynamic, moving, star system details, which has created the brick wall that my math chops have slammed into. What used to be a simple "accelerate to mid-point, turn ass around and decelerate to destination" is now a whole lot more complex.

I do believe, though, that I managed to slay the twin dragons of graphic based unit selection and coordinate transformations, or maybe it just looks convincing...

If anyone in the target audience actually uses the thing, maybe they won't notice, LOL


https://www.qb64.org/forum/index.php?topic=1429.0