"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"
Until we evolve past the need to solve conflicts with violence. So 100,000 generations of positive evolutionary pressure (which won't happen), or artificial tweaking of DNA (forced upon every human at the same time - which also won't happen).
The alternative is strong military posturing in order to deter opportunists from trying their luck attacking you.
The alternative is political structures that prevent violence and resolve political problems otherwise.
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.
You still want to focus on force, but most people want other outlets for their political needs. It's when those outlets are unavailable that they resort to force.
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.
Until humans are either all dead, or no longer human (e.g., they've been genetically engineered to have no capacity for violence, or perhaps be part of a hive-mind like ants).
I'm not aware of ants ever having conflicts within their own colonies. With other insects (namely termites), sure, but that's not the problem here.
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.)
>I'm not aware of ants ever having conflicts within their own colonies.
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.
Violence or the believable threat of violence is unfortunately the only way to resolve a conflict between A and B when there is no third party C that can enforce a decision between A and B.
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.
First I thought you were joking. But as of February 2, 2009, 1 ZWL (third re-denomination) was equal to 10^12 ZWR (second re-denomination), 10^22 ZWN (first re-denomination), and 10^25 ZWD (original currency).[1] 1 ZWL does not fit in a 64-bit integer if converted to ZWN or ZWD:
>To store dollars with a precision of 1 cent, you store into your integers cents instead of dollars. No need to mess with anything more complicated.
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.
Why would it have to be floating point to work? For ("physical") money there always is a finite smallest part, so integer math works fine. For time, if you go nuts and store Planck time a 256 bit integer is enough to store almost 1 billion billion billion years and you cannot go smaller for more precisions. So I'm curious why you claim it must be floating point for calculation.
I'm curious what situation you have in mind. I suppose if you wanted to calculate a rate, you would need to divide (integer) money by an (integer) time interval.
Of course they are not the same. But why does it matter? With floating point you must always be conscious of precision errors and they can lead to catastrophic compounding errors vs with integer you have to decide how to handle rounding and overflows. One is not better than the other, it's just different, and both work fine with time and money if you are careful enough. That said, I personally find integer math to be the less surprising of the two. It's simply easier to reason about, and handle, edge cases.
Because that is not how we model computation and that matters for how the computation is done? Obviously I could do any math in unary, or construct it from Euclid's elements. However that is not typically how floating point numbers are stored in computers or represented to users. And it is typically no how the computations on them are done?
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.
If you model your particular computations and storage after FP, obvious that is closer. My guess is, that is with all likelihood a choice made for performance reasons when computers was far less powerful than they are today. The rest might as well just be inertia and a different choice could be made today if it was to start over. Or maybe not, but it's no longer as a clear cut choice as it once was.
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.
The problem wasn't in the way the time was stored (integer representing tenths of seconds); it was in the conversion to float for the calculations being done. A 1/1000000 error margin is fine for small numbers (up to 30,000 seconds), but not for big ones (100,000 seconds) where being even a tenth of a second off causes the calculation to become unreliable.
Rule #2 is when calculating duration is to keep the timestamps as long long. If for some reason you need to convert the duration to float, check the duration first and/or just use double precision.
Floating point numbers are the worst ways to work with non-integer numbers, unless you count all the other ways of working with non-integer numbers, which are worse (ratios, fixed-point).
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.
Is there anything I can read about the sharp edges of these alternate representations? Lots of ink is spilled about the perils of floats, but in the past when I've been tempted to write a fixed point or ratio implementation (for mathy personal projects where they were especially useful), I've had a hard time finding much written about them at all.
You can instead list your criteria for good number format and look at alternatives with those lenses. Floating point is designed for a good balance between dynamic range and precision, and IEEE 754 binary formats can be seen as a FP standard particularly optimized for numerical calculation.
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].
In the future it will be the missle's arming service unable to talk to the guidance service because it doesn't trust "Kubernetes Ingress Controller Fake Certificate"
Weird that the internal systems communicate via an Ingress, but I guess that's government contractors for you. Clearly they should have gone with Istio instead.
While we're being absurd, are there any open source/copyleft licences that specifically forbid uses in war or weapons? I guess the gov will do whatever they want, but it would be interesting to see how it played out.
There are, but neither the FSF nor OSI support them. Those provisions go against OSI's rule 6 and FSF's rule 0. Both believe free software and open source software licenses should allow the software to be used openly by anyone. On the other hand, breaking software licenses is fair game in war.
The HGPL-4 states that all systems using covered source code must be programmed to attack those who would threaten our software freedoms. It's in the "paradox of tolerance" clause. See also: Creative Commons BY-NC-ID (ideological derivative) which allows noncommercial remixes with attribution, but not in works that promote copyright.
US companies. One example is Motorola Solutions Inc.
All of their new handheld radios run linux on the inside and have been confirmed to run code under GPL.
Nothing has been released in the past decades.
Older versions of Minecraft had a similar issue. The block display started to get desynchronized with large enough coordinates, because their coordinates were relative to the world origin and not the player/camera position and truncation errors got large enough to have visible effects. (You can see them from most Far Lands videos.)
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.
> 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?
The problem is that there aren’t enough digits of precision to represent the answer. The exact answer would be 999999.0000001, but let’s say you only have space to store six significant digits. The exact answer is way more precise, so you need to round it to the nearest representable value, 999999.
Floating-point rounding issues are the same thing but with binary digits instead of decimal ones.
Graphical glitches I mentioned are independent from the Far Lands---AFAIK they start to happen around 1--2 million blocks from the origin, much closer than the Far Lands (~12.5 million blocks). The Far Lands itself is a result of noise generator bug with very large inputs [1].
Hunh. I just discovered that when you cast the 32 bit 2's complement -273613110 as an IEEE 754-2008 binary32 float, you get -109554765609536775148540002304.0 which, when you look at it's in-memory representation as a series of octets on a little-endian machine, it's CAFEBOEF.
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.
Even in C, incompatible object accesses are undefined, not unspecified. (`char` is a major exception.) Using `union` is explicitly allowed by ISO C for this use case; you need to use `memcpy` or `std::bit_cast` in C++ instead though.
I didn't quite get why the error in the absolute time would cause the effect. Sure using 0.1 seconds as a unit is problematic because 0.1 can't be represented accurately in binary, but I didn't see how the tracking error was relative to the absolute time.
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.
Oh well, that's even worse. If I understood correctly, that means there are two timestamps t1 and t2 from each radar pulse, which difference in seconds is computed as `f(t1) - g(t2)` where g somehow truncated to 24 bits instead of the full 48 bits. I don't exactly get why f and g are different enough to cause the truncation, it might well be that f and g are correct but the final subtraction missed lower bits of `f(t1)` instead.
In the 1980s the Vancouver Stock Exchange silently lost 500 points due to rounding errors - repeated addition of small numbers. They didn't notice for two years.
90 comments
[ 3.2 ms ] story [ 171 ms ] threadPre-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.
[1] https://en.wikipedia.org/wiki/Zimbabwean_dollar#History
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.
[1] https://www.gao.gov/assets/imtec-92-26.pdf
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.
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].
[1] https://iquilezles.org/articles/floatingbar/
[2] https://arblib.org/
[3] https://dl.acm.org/doi/pdf/10.1145/2911981
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?
https://youtu.be/-hCimLnIsDA
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...
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.
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.
But I haven't seen this when going from signed int -> unsigned int or vice versa.
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...