Physics, Maths and Code

I read an interesting article yesterday about physicists learning to code and moving into Silicon Valley. From my reading, the takeaway was that it’s easier to teach someone who works with maths to code than it is to teach someone who works with code maths.

Obviously, that’s a sweeping statement, and the ranges of code to which it applies are probably not that common, but it’s still interesting. And it got me thinking about how programming uses maths and physics.

I studied maths and physics in high school, both to Higher, and I passed both, though in the case of maths not by much. More recently, I’ve become hooked on Kerbal Space Program (KSP), a game which gives the player rocket parts and astronauts (from a race of small green people called Kerbals) and lets you explore the solar system.

In and of itself, it’s a lot of fun, and there have been collaborations between Squad, the company behind KSP, and NASA. There have also been reports of people inadvertently reading up on orbital physics to work out the most fuel-efficient course from one planet to another.

And then there’s kOS, a mod which provides the user with the possibility to write autopiloting scripts which can take control of your lovingly crafted rocket, blast it out of the atmosphere and do… well, whatever you want, really.

The drawback (of course there had to be a drawback, it couldn’t just be a game about coding and space exploration, that would be a nice thing and we know we can’t have nice things) is the syntax, which… I was going to make a comparison to the bastard child of BASIC and some very early OOP language, but I’m not sure that that’s fair.

Let’s take a look at some syntax (pro tip, don’t run this. It’s overly simplified and will likely cause unexpected re-entry heating due to unexpected re-entry), and you’ll maybe see what I mean.

declare function orbit {

// This only works if we're already in space, so it should probably check

// Also, it doesn't check that the orbit actually /is/ stable before exiting, so...

parameter min_periapsis.

lock steering to ship:prograde.

wait until eta:apoapsis < 10.

lock throttle to 1.

wait until ship:periapsis > min_periapsis.

print "Stable orbit.".


Fun things about kerboscript (as this language is commonly known) include

  • declaring functions by… well, typing declare function in front of the function name
  • defining the function’s arguments with the parameters keyword
  • the use of a full stop as a line ender (Python has made me bratty about these).
  • the lock variable to value. syntax

However, bonus points if you picked up on this – there are actually to ways of defining the value of a variable – set and lock. The former of these – set altitude to alt:radar, say – does what you’d expect, but lock? lock marks the variable for lazy evaluation.

For those of youto whom lazy eval is a new concept (it was for me, too), here’s a primer: lazy evaluation decides the variable at the time that it’s needed, not the time it’s assigned. So, for instance:

set a to 3.

set b to 2.

set ab to a*b.

set b to 3.

print b.

In this example, when you ran the code it would print 6 to your screen. Perfectly reasonable, really – that is what 3*2 is, right? Now consider the following example:

set a to 3.

set b to 2.

lock ab to a*b.

set b to 3.

print b.

In this instance, rather than printing 6, the code will print 9! How exciting is that?

Well, admittedly, not very. But it does come in handy for, amongst other things, readability. Consider the following equation, which (with a couple of caveats) determines the height above an airless body (like the moon) at which a rocket should start firing engines so as not to crash (at least, I hope it does. I roughed it out on a sheet of paper yesterday and I haven’t had the chance to test it, yet):

set altitude to (ship:velocity^2)/((ship:availablethrust/ship:mass) - (ship:body:mu / ship:body:position:mag^2))

That is… not human-readable, really. Much less easily proofreadable, especially since kOS doesn’t have an IDE to keep track of brackets and what have you. Thankfully, this does exactly the same:

lock v to ship:velocity^2.

lock at to (ship:availablethrust/ship:mass)*1000. // at is acceleration due to engine thrust, multiplication is because availablethrust returns in kilonewtons

lock ag to ship:body:mu / (ship:body:position:mag ^2) // ag is acceleration due to gravity

lock altitude to v/(at-ag).

The altitude variable will now give you an always-updating readout (which is necessary since the lowest safe burn height will vary depending on the fuel you have left, the altitude you’re at, and how high you are.

So, all of this has left me with a thought. I’m going to start assessing the feasibility of writing a transpiler, a program which will take some rocket code written in something approaching Python and convert it into kerboscript. It seems pretty complicated, but then again taking on massively over-complicated projects which are doomed to languish forever in early development is… well, not to be immodest but it’s kinda my métier, so who knows?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s