Editing 3228: Day Counter

{{comic
| number    = 3228
| date      = April 3, 2026
| title     = Day Counter
| image     = day_counter_2x.png
| imagesize = 319x287px
| noexpand  = true
| titletext = It has been −2,147,483,648 days since our last integer overflow.
}}

==Explanation==

{{incomplete|The calculations by DL Draco Rex et al. in the Talk should be included in the explanation. Don't remove this notice too soon.}}

A common feature of an industrial setting is a prominent sign announcing how many days have elapsed since the last workplace accident.  The sign is typically updated each day to a number one higher — or back to zero, if there ''has'' been an accident.  Such signs are intended to foster a culture of safety among the workers in the facility, since presumably no one wants to suffer the embarrassment of being the one to have caused an accident that resets the number to 0. (However, it may also lead workers to cover up or conceal accidents, for the same reason, which would tend to increase future accidents, because they do not report the need to correct hazardous conditions that are causing accidents.)

Evidently, in the programming facility shown in the comic, a floating-point error has occurred today, and an attempt has been made to update the sign to say "It has been 0 days since...".  But the number 0 is displayed incorrectly, as the very small negative value −0.00000000000000044.  Perhaps the error that was made today was the very error that occurred in updating the sign!  (This would of course violate {{w|causality}}, but in comedy, self-referential humor beats causality every time, and is at least self-consistent, like with [[363: Reset]])

Floating-point errors occur because computers can devote only a finite amount of storage for each {{w|Floating-point arithmetic|floating point number}} or other fraction.  However, many {{w|real numbers}} and {{w|rational numbers}} theoretically require an infinite number of digits to represent them.  For example, the ordinary fraction ⅓ is represented in decimal as 0.3333333333…, where the 3s repeat forever.  When a number is truncated to fit in the finite amount of space, precision is inevitably lost, resulting in a slight rounding error.  Unless carefully controlled, these rounding errors can accumulate, significantly degrading the accuracy of floating-point computations. For example, although ⅓ + ⅓ + ⅓ should obviously equal 1, a finite-precision calculation like 0.333 + 0.333 + 0.333 might show a misleading result of 0.999, which might not trigger the code to do what it should do when three thirds have been accumulated (it can be mitigated by allowing a match for a value which is within a suitably very small difference to the test value, but this must be considered carefully to not be over-/under-sensitive). The amount of required space for rational numbers is not universal, it depends on the base used (⅓ in base 3 requires just two digits: 0 as the units and 1 after the {{w|Decimal separator#Radix point|radix (ternary) point}}). Floating point arithmetic standards, like the popular IEEE 754, define how and when an approximation should take place, leading to predictable results, but they don't respect some basic properties of common arithmetic operations, which someone may take for granted, e.g. in floating point arithmetic addition and multiplication are commutative (a+b=b+a; a*b=b*a), but aren't guaranteed to be associative ((a+b)+c≈a+(b+c)); (a*b)*c≈a*(b*c)).

This issue is exacerbated on computers which use binary arithmetic (i.e., virtually all computers today), since in binary, the ordinary fraction 1/10 is represented as the infinitely-repeating base-2 fraction <tt>0.000110011001100110011</tt>….  A classic example is that, depending on circumstances, the calculation 0.1 + 0.2 might [https://stackoverflow.com/questions/588004/is-floating-point-math-broken seem to give an answer of 0.30000000000000004].

Floating point errors are particularly common in programming, especially in languages that implicitly convert decimal numbers to binary floating point, so an approximation is already made at conversion leading to unexpected results. The title text cites another common programming problem, integer overflow. When a value  gets bigger than the biggest integer that can be represented in a certain format, it may "wrap around" to the smallest/most negative value (if the system is not instead set to catch this as an overflow error). In case of 32-bit signed integers it may wrap from 2<sup>31</sup>−1 (2,147,483,647) to −2<sup>31</sup> (−2,147,483,648). 

Integer overflow was the topic of [[571: Can't Sleep]], with yet another example of a 'days since' sign being [[3140: Biology Department]] (two examples, in both the comic and its title text).

It should be noted that computers displaying things like "-1 seconds until the next [blank]" is a glitch that actually happens.

==Transcript==
[White Hat, Ponytail, Cueball, and Megan are all below a large sign, which appears to be attached to the wall at its four corners. White Hat and Ponytail appear to be discussing something, while Cueball is sitting at his desk working on a laptop and Megan is walking away. The sign has text on it, as well as a large display presumably meant to show a number.]

:[Sign:] It has been
:[Display:] -0.00000000000000044
:[Sign:] days since our last floating point error

==Trivia==
As an example of how the number −0.00000000000000044 could have arisen when 0 was intended, consider this simple {{w|C (programming language)|C}} program:

 #include <stdio.h>
 int main()
 {
     double d = 19;
     for(int i = 0; i < 10; i++) d -= 1.9;
     printf("%.17f\n", d);
 }

The program starts with the number 19, and subtracts 1.9 from it, ten times.  Mathematically, we would expect the result to be 0.  However, the number 1.9 cannot be represented exactly in binary, nor can the intermediate results 17.1, 15.2, 13.3, etc.  The cascading roundoff errors conspire to produce a result of −0.00000000000000044 instead of the expected 0.

In the comic, such an error creates the ridiculous illusion that −0.00000000000000044 days have passed, which implies a 'negative' number of days, which is impossible{{cn}}. It also, even if it were a positive number, would mean that much less than a nanosecond had passed since the last error, which would be an unfeasably short amount of time. Of course, the joke is that in making the sign showing the amount of time since a floating point error was last made, they are creating a floating point error, meaning the sign maintains its own "error state" in a self-referential way. Also, if they tried to reset the sign, they might make the same error again, repeating the cycle over and over, which would not be ideal.

Coincidentally enough, [[Cueball]] is also floating — off his seat in this case. The seat itself looks the same as the chair in [[2144]], possibly meaning making people levitate is one of its numerous settings.

Strangely enough, when the comic was first published the sign number was −0.00000000000000017 days.{{actual citation needed}} It was changed later though, probably so that it would be more realistic, −0.00000000000000017 would correspond to the very last bit of mantissa being incorrect and only for numbers between 1 and 2 (not including 2), and operation (1-1) is unlikely to result in rounding errors, so the smallest difference from integer is usually higher, which would result in −0.00000000000000044 the smallest possible  rounding error for values between 2 and 4.

{{comic discussion}}<noinclude>[[Category:Interactive comics]][[Category:Dynamic comics]]
[[Category:Programming]]
[[Category:Math]]
[[Category:Comics featuring White Hat]]
[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Megan]]