Patriot Missile Software Problem
cs.unc.edu
cs.unc.edu
I remember reading the license of a game engine that forbade using it for military training. I thought it was Quake but it doesn't seem to be.
By who?
It should be noted that floating point is not really an issue for both Patriot and Minecraft. There would have been similar issues even when fixed integers of the same size, 24 and 32 bits respectively, were used. The real issue is that there were two values where one is much larger than another, and they were combined into a single variable without further consideration.
What do you mean by this? How is this related to the Far Lands generation?
999999 + 0.0000001 ~= 999999
Floating-point rounding issues are the same thing but with binary digits instead of decimal ones.
[1] https://minecraft.wiki/w/Far_Lands#What_the_Far_Lands_are_no...
This short article by Skeel[1] cleared it up, where he notes that the real issue was rather that they had changed the way they converted the absolute time to floating-point, but had missed a spot so the code mixed new and old floating-point times.
[1]: https://www-users.cse.umn.edu/~arnold/disasters/Patriot-dhar...
https://en.m.wikipedia.org/wiki/Vancouver_Stock_Exchange#Rou...
log2(10^22) = 73.08
log2(10^25) = 83.05
However there are languages that are looking at F128 (https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). The problem is that there isn't really hardware support for them yet so you'd do it through software.
As someone who does it, financial math is often done at a precision of more than 1 cent. This is the reason that most (high-latency) financial libraries use strings underneath.
This al doesn't address the high order floating point arithmetic of geo-spacial, which was the Patriot issue.
I personally find FP math perfectly find when you are dealing with numbers "small enough" to fit the datatype you're working with. The issues with overflow exist in both integer and fp's alike.
Your original claim was that Int64 would not work for financial calculations. For most normal calculations it would be fine, and for tax purposes it would be too, as the tax authority defines exactly when to round and how (at least in Denmark). If you retain the fractional precision the "true" calculations have, your tax calculation would be wrong.
No matter what you use, it is always a tradeoff between precision, range, and speed. Floating point have been use a lot because they provide relative precision and have much bigger range and vastly faster speed compared to the same range in integers. But that comes with a lot of gotchas. To get the same range as a 64bit float, you need around 1024bit integer, which will inevitably be slower and require more memory.
With a C-style cast you don't think that a conversion is happening. You think it's just re-interpreting the bits.
But that's not the case with floats -> int. You can't just look at a float with int-colored glasses.
float floatValue = *(float*)&intValue; #include <stdio.h>
#include <stdint.h>
int main() {
uint32_t i = 1200053440 + 64;
float * fp = (float *) &i;
float f = *fp;
printf( "%ld %ld %ld\n", sizeof( i ), sizeof( fp ), sizeof( f ) );
printf( "%08X %d %f\n", i, i, f );
return( 0 );
}
How to get to DEADBEEF is left as an exercise for the reader.
The next time I need a floating point constant, I'm picking -109554765609536775148540002304.0.
union { float f; int i; } value;
value.i = intValue;
float floatValue = value.f;But I haven't seen this when going from signed int -> unsigned int or vice versa.
https://gist.github.com/jevinskie/58c65760a0b54f117a8d0f3b32...
For at least two weeks prior it was know that long continuous operation would render the system unusable.
It seems the floating point issue was a known limitation was a reasonable work around.
Pre-internet society be crazy -
"On February 26, the next day, the modified software, which compensated for the inaccurate time calculation, arrived in Dhahran. According to Army officials, the delay in distributing the software from the United States to all Patriot locations was due to the time it took to arrange for air and ground transportation in a wartime environment"
The alternative is strong military posturing in order to deter opportunists from trying their luck attacking you.
Warfare is politics - it's when someone says, 'I must get what I want and talking can't achieve it'. We need political structures that provide solutions through talking, which is the/an origin of courts, democracy, a rules-based international order.
For example, Massachusetts isn't attacking New York any time soon, nor is the US invading Canada or France invading Germany. That has nothing to do with force.
People love to embrace violence these days. It's edgy to be cold, but it's actually very important to understand how humanity actually functions, and how our exceptionally peaceful world has been built.
Unlike ants, humans have no natural enemies, and are unlikely to unless some aliens attack, so humans don't have much need of violence for self-defense from outside, though I suppose you could make an argument that violent weapons can be useful for dealing with asteroid threats. (But even here, it probably makes a lot more sense to use engines to slowly push asteroids into safer orbits than to use bombs.)
If most humans were mindless drones easily controllable by pheromones or physical gesturing, there would be no inter-tribe conflicts either.
Also, it is highly likely that humans do have natural enemies. There is compelling evidence that human beings are evolutionarily predisposed to recognize snakes extremely quickly, faster than almost any other object, and electrically speaking faster than our conscious perception of them due to the immense threat they once posed (and still pose) to humans.
For example, national laws only work when backed by a credible threat of violence. Arresting people and forcing them to live in a prison or getting executed for breaking a law is an act of violence carried out by all governments.
This is kind of a ha-ha cute response and not something you should try to dissect, but it’s worth thinking about the reasons why float beat out both ratios and fixed-point as the preferred way to represent numbers—those types both come with traps that are somewhat more severe than the traps you encounter with floats.
Like time, floating point is deceptively hard.
There are several other FP formats. The most popular one is IEEE 754 minus subnormal numbers, followed by bfloat16, IEEE 754 decimal formats (formerly IEEE 854) and posits. Only first two have good hardware supports. The lack of subnormal number means that `a <=> b` can't be no longer rewritten to `a - b <=> 0` among others but is widely believed to be faster. (I don't fully agree, but it's indeed true for existing contemporary hardwares.) IEEE 754 decimal formats are notable for lack of normalization guarantee. Posits are, in some sense, what IEEE 754 would have been if designed today, and in fact aren't that fundamentally different from IEEE 754 in my opinion.
Fixed-point formats share pros and cons of finitely sized integer numbers and you should have no difficulty to analyze them. In short, they offer a smaller dynamic range compared to FP, but its truncation model is much simpler to reason. In turn you will get a varying precision and out-of-bound issues.
Rational number formats look very promising at the beginning, but they are much harder to implement efficiently. You will need a fast GCD algorithm (not Euclidean) and also have to handle out-of-bound numerators and denumerators. In fact, many rational number formats rely on arbitrary-precision integers precisely for avoiding those issues, and inherit the same set of issues---unbounded memory usage and computational overhead. Approximate rational number formats are much rarer, and I'm only aware of the Inigo Quilez's floating-bar experiment [1] in this space.
Interval/ball/affine arithmetics and others are means to automatically approximate an error analysis. They have a good property of being never incorrect, but it is still really easy for them to throw up and give a correct but useless answer like [-inf, inf]. Also they are somewhat awkward in a typical procedural paradigm because comparisons will return a tri-state boolean (true, false, unsure). Nevertheless they are often useful when correctly used. Fredrik Johansson's Arb [2] is a good starting point in my opinion.
Finally you can model a number as a function that returns a successively accurate approximation. This is called the constructive or exact real number, and simultaneously most expensive and most correct. One of the most glaring problems is that an equality is not always decidable, and practical applications tend to have various heuristics to get around this fact. Amazingly enough, Android's built-in calculator is one of the most used applications that use this model [3].