Ion drives like VASIMR, and adjustable NERVA like the shockwave rotor, can squeeze more efficiency from their drives by feeding in energy and/or adjusting the exhaust throat. It occurs to me that this means recalculating the rocket equation in real time. As in: on the rocket, not outsourced to orbital data. That drinks more energy for compute, which then must be controlled somehow; probably by radiating out.
These are exponent and logarithm equations. If we were using a TSR-80 extended BASIC processor, welcome to Taylor series.
Needless to say, that is some bull-tish. Don't we have some tricks to turn a float into a longint? Just shift the integer over bro. *(long*), subtract some magic number, then <<= bro. Like when the exponent was -1/2.
That'd be great if the ratios were all integers. They... probably aren't. Because they aren't, this method requires to poll the ratio until it reaches an integer and then run the calc.
We'd hope to force integers on all four values of the Tsiolkovsky to some cromulent unit-length, like millimeters and grams. We'll see. Instead of exp(dv/ve) it's exp(dv) × root-ve(e). One multiplication operation. Gotta be better than Taylor(8). Ln(m0/mf) meanwhile is [lb(m0) - lb(mf)] × ln(2). Now we have to ponder overflow: 32-bit integers go only to 231. So, no; these are going to be km/s maybe even Mm/s which we have to rescale after the calc.
Depending on the unit-lengths I might even consider storing the exponent-powers and the e-roots in tables. Data got corrupted on Voyager but I suspect our triage is better today; so's our shielding. On arrival at the destination our need to punch the engine shouldn't be as dire, so the memory used in the tables can be wiped, for reüse in the actual mission.
This was imprecise for q_rsqrt and will be imprecise now. Those 1990s gamers applied Newton's method upon that approx "y", thus: y * ( 1.5F - ( x * 0.5F * y * y ) ). Lotsa multiplications, here. And that's second-order because this was just a square. And, to remind: we're talking about high exponents and high roots. May as well devolve to Taylor.
Kasper Nielsen's cheat-sheet of "float tricks" may offer an out. We have NVIDIA's "piecewise linear approximation" which shouldn't overflow. Ian Stephenson does one better for Pow2 which "approximates the error with a quadratic".
There are other unsafe-code solutions in the roster, some just straight assembler with no overflow checks. Good news: I doubt we need 'em for the floating fractions. The mass ratio as wet/dry[-er] even at some Apolloesque 96 isn't going to have ln(x) all that high (4.6ish here), and this is going down as we drive. The velocity ratio working with inner-system delta-V and as-good exhaust as they'll allow us (like, 14 km/s) should also be low, enough for exp[x] anyway.