explain xkcd - User contributions [en]

Talk:3062: Off By One

2025-03-13T22:41:53Z

172.70.230.159:

But what about floats? [[User:GreyFox|GreyFox]] ([[User talk:GreyFox|talk]]) 20:01, 12 March 2025 (UTC)

Is this dithering? [[User:Hcs|Hcs]] ([[User talk:Hcs|talk]]) 21:19, 12 March 2025 (UTC)

: Could be. --[[User:PRR|PRR]] ([[User talk:PRR|talk]]) 22:19, 12 March 2025 (UTC)

This language has a huge off by one error: the docs don't explicitly say if the random range is inclusive. EDIT: the comic description above now includes this, thx --[[User:Snaxmcgee|Snaxmcgee]] ([[User talk:Snaxmcgee|talk]]) 22:22, 12 March 2025 (UTC)

But if it's adjusted both on store and on read, then there is a chance (of about 1 in 22) that the value after read will be exactly the same as the value before store. This does not eliminate pre-existing off-by-one errors, and in fact, introduces new ones if the adjustment on read is off by one from the adjustment on store, when there was no off-by-one error in the original code. And what's worse - with a single store-read cycle, the value can never be off by 40 to 50. It can be off by up to 10, or by between 80 to 100, in either direction. --[[User:NeatNit|NeatNit]] ([[User talk:NeatNit|talk]]) 22:42, 12 March 2025 (UTC)
:I was ''just'' adjusting the explanation to imply this sort of thing (without having read your comment, just yet). Given the assumption that n=n±(40+rand(11)) at every stage (I'm assuming 'inclusive', Snaxmcgee!), two steps of 'intentional adjustment' might result in: -100 (x1), -99 (x2), -98 (x3), -97 (x4), -96 (x5), -95 (x6), -94 (x7), -93 (x8), -92 (x9), -91 (x10), -90 (x11), -89..-80 (x10..x1), -10 (x2), -9 (x4), -8 (x6), -7 (x8), -6 (x10), -5 (x12), -4 (x14), -3 (x16), -2 (x18), -1 (x20), ±0 (x22), +1..+10 (x20..x2), +80..+90..+100 (x1..x11..x1).
:This gives a chance of being entirely correct as 22/484 (4.5454...%) and ''each'' off-by-one as ''very'' slightly less (though ±1, in total is almost twice as likely!).
:Adding further steps (skipping odd step-cummulations, at least at first, until you get to nine of them and everything entirely stops being discontinuous) just spreads out an increased number of highs right next to zero deflection... [[Special:Contributions/172.70.86.129|172.70.86.129]] 23:38, 12 March 2025 (UTC)

::Obligatory quote:
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
::See here for a full story of this quote: https://twitter.com/codinghorror/status/506010907021828096
::--[[Special:Contributions/162.158.129.64|162.158.129.64]] 08:28, 13 March 2025 (UTC)
:::And 3 hard things in distributed computing: 3. Delivering messages exactly one time, 2. Making sure things happen in the correct order, and 3. Delivering messages exactly one time [[User:Jamcdonald|Jamcdonald]] ([[User talk:Jamcdonald|talk]])
::::Presumably 1 is not losing data? --[[User:NeatNit|NeatNit]] ([[User talk:NeatNit|talk]]) 10:19, 13 March 2025 (UTC)

In the comic, Cueball clearly says the adjustment amounts is ‘’between’’ 40 and 50, yet this explanation says the adjustment is from 40 to 50, ironically making an off-by-1 error on both ends of the range. Neither integers 40 nor 50 are “between 40 and 50”. [[Special:Contributions/172.71.154.39|172.71.154.39]] 10:43, 13 March 2025 (UTC)
:English language is imprecise with its use of "between", but it's usually taken as inclusive. Most people, when asked, "Pick a number between 1 and 10," will assume that 1 and 10 are both valid choices. Even in computing, you have things like Excel's RANDBETWEEN function to generate random integers between two bounds, which is inclusive. {{unsigned ip|104.23.187.72|13:28, 13 March 2025}}
::Interestingly, in German such ranges are defined as including the borders, in Dutch they're defined as excluding the borders. (hence the Dutch t/m ("tot en met" - "up to, and including") [[Special:Contributions/104.23.170.81|104.23.170.81]] 15:28, 13 March 2025 (UTC)
::Yes, see {{wiktionary|between#Usage notes}} as one overview. Between as in "within the bounds defined by" is different from "amongst those things of which these items are the defining outer examples". Especially, but not exclusively, when that's just two distinct items which have ''no'' valid intermediate states betwixt the two to choose from ("you have to choose between me and my sister" isn't usually satisfactoraily answerable by choosing a different sibling, or perhaps parent, of the two). [[Special:Contributions/172.69.195.54|172.69.195.54]] 15:24, 13 March 2025 (UTC)

It's easy to make an off-by-one error without using a computer at all. Ask a friend how many fenceposts are needed for a 100-foot fence if the rails are ten feet long. [[Special:Contributions/172.71.30.199|172.71.30.199]] 12:58, 13 March 2025 (UTC)
:And how wide are the posts..? ;) [[Special:Contributions/141.101.98.6|141.101.98.6]] 15:27, 13 March 2025 (UTC)
::If I ever answer this question 100, it's obviously because in my mind each post (or more accurately, the distance between the grooves cut into the post) is a foot wide, which is slightly larger than usual but not totally unreasonable size, and not because I fell for the trick.--[[User:Snaxmcgee|Snaxmcgee]] ([[User talk:Snaxmcgee|talk]]) 16:47, 13 March 2025 (UTC)

I don't understand - what's all this got to do with water balloons? [[Special:Contributions/172.70.86.129|172.70.86.129]] 15:37, 13 March 2025 (UTC)
:(ISWYDT...) [[Special:Contributions/173.70.195.206|171.68.193.204]] 16:47, 14 February 2026 (UTC)
::What did they do. Waterballoons were the previous comic? What did they do? [[Special:Contributions/172.70.230.159|172.70.230.159]] 22:41, 13 March 2025 (UTC)

Let's make programming languages do this! There should be an implementations section! :D :D [[Special:Contributions/172.70.230.159|172.70.230.159]] 22:41, 13 March 2025 (UTC)

2989: Physics Lab Thermostat

2024-09-24T12:28:57Z

172.70.230.159: /* Explanation */

{{comic
| number = 2989
| date = September 23, 2024
| title = Physics Lab Thermostat
| image = physics_lab_thermostat_2x.png
| imagesize = 264x296px
| noexpand = true
| titletext = Hopefully the HVAC people set it to only affect the AIR in the room.
}}

==Explanation==
{{incomplete|Created by a BOLTZMANN BRAIN - Given the calculations mentioned in the comment, it would seem that the thermostat works normally in the way that turning it clockwise will increase the temperature. This should be mentioned and some kind of calculation like the one mentioned in comments section could be added for clarity/reference. Do NOT delete this tag too soon.}}

A thermostat is often used to regulate the operation of heating and/or cooling for a room. This may take the form of a simple dial, graduated by desired temperature values marked Celsius or, in {{w|Fahrenheit#Usage|some backwards parts of the world}}, Fahrenheit. Typically a person is expected to know what sort of temperature they will find comfortable, to have heating/cooling effects kick in as the wall-device detects a temperature more than a certain amount below/above that ideal. The basic design of a physical wall-mounted dial might relate the relative position of the dial against the current state of a {{w|Bimetallic strip#Thermostats|bimetallic coil}}, switching {{w|Bang–bang control|on or off}} the relevent systems once conditions locally drift away from the chosen ideal.

In this comic, the thermostat is installed in a physics lab, with those that work there clearly being expected to be familiar with the {{w|Boltzmann constant}}, a more fundamental method of measuring temperature which relates the average kinetic energy of a particle in a gas with the temperature of that gas. The Boltzmann constant is defined as 1.380649 × 10^-23 J/K (joules per kelvin).

Thus Randall imagines a physics lab having a dial that can alter the constant between 1.418 x 10^-23 J/K and 1.351 x 10^-23 J/K. If the average kinetic energy of gas particles remains constant when moving the dial, then changing the Boltzmann constant would change how this average energy is measured in {{w|kelvin}} (and therefore {{w|Conversion of scales of temperature#Comparison of temperature scales|any other measure}} of temperature), thus "changing the temperature". The equation is E=kT where k is the Boltzmann constant. Notice that if E is the same, lowering k will raise T, so the thermostat works as intended. Rather than controlling the nature of the airflow into the lab (or convection heaters/coolers around it), it might be implied that this applies the effect directly across the whole lab at a fundamental level. Changing one of the fundamental constants of thermodynamics would have dangerous effects.{{acn}} 

There have previously been control panels for properties of the universe in [[1620: Christmas Settings]] and [[1763: Catcalling]].

Because the Boltzmann constant is primarily concerned with the nature of temperature within gas, the titletext expresses concern that it might not only be applied to the air in the room. Aside from the possibility that those responsible for the {{w|heating, ventilation, and air conditioning}} (a.k.a. HVAC) of the room could perhaps directly enhance or suppress the temperature in all the solids and liquids within the room, in unknown and not necessarily conducive ways, there may also be a secondary joke in which {{w|high voltage}} forms of {{w|alternating current}} (also refered to as HVAC) are influenced, in the related but distinct use of the measure for '{{w|Boltzmann constant#Thermal voltage|thermal voltage}}'.

I note that "AIR" is in all caps. Is it supposed to be an Acronym? 12:28, 24 September 2024 (UTC)

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

:[A black circular dial is shown with a white indicator line at the upper right. The label above the dial, enclosed in a rectangular box, says:]
:Local Boltzmann Constant
:[The two extremes of the dial are labeled as follows, the first value on the left and the second value on the right:]
:1.418 x 10-23 J/K
:1.351 x 10-23 J/K
:[The indicator line is pointing to a position on the dial somewhere around 1.375 x 10-23 J/K.]
:[Caption below the panel:]
:Physics Lab Thermostat

{{comic discussion}}
[[Category:Physics]]

Talk:2980: Lava Lakes

2024-09-03T01:24:37Z

172.70.230.159:

yoo [[Special:Contributions/172.70.230.159|172.70.230.159]] 01:24, 3 September 2024 (UTC)

2697: Y2K and 2038

2022-11-13T10:49:14Z

172.70.230.159: /* Explanation */ bit-twiddling to store your values, useful for assembly work

{{comic
| number = 2697
| date = November 11, 2022
| title = Y2K and 2038
| image = y2k_and_2038_2x.png
| imagesize = 527x190px
| noexpand = true
| titletext = It's taken me 20 years, but I've finally finished rebuilding all my software to use 33-bit signed ints.
}}

==Explanation==
{{incomplete|Created by a Y2K-BRICKED BOT (MADE JAN 1, 1970). Do NOT delete this tag too soon.}}

[[File:Year 2038 problem.gif|thumb|An animation of the 2038 bug in action. The {{w|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]]

The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years incorrectly handling the year 2000, such as by treating it as 1900 or 19100. The {{w|year 2038 problem}} is a similar issue with timestamps in {{w|Unix time}} format, which will overflow their {{w|Signed number representations|signed}} 32-bit binary representation on January 19, 2038.

While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. On New Year's Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of them that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which often made up at least in part for the the cost of correcting the date bug.

It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity and access to source code has allowed many otherwise vulnerable systems to already upgrade to wider timestamp and date formats, so there is reason to believe that it may be even less consequential and expensive. The 2038 problem has been previously mentioned in [[607: 2038]] and [[887: Future Timeline]].

This comic assumes that the 38 years between Y2K and Y2038 should (or must) be split evenly between recovering from Y2K and preparing for Y2038. That would put the split point in 2019 (specifically, January 10, 2019). The caption points out that it's now (2022) well past that demarcation line, so everyone should have completed their "Y2K recovery" and begun preparing for Y2038. It is highly unlikely that there are more than a very few consequential older systems that still suffer from this bug, while systems built to operate only since the millennium can already handle years after 1999 correctly, though not ''necessarily'' those after 2099, 2255 or some other notable problematic date. There's also no reason any developer should have waited until 2019 to start preparing for 2038.

The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format. Doing this may seem complicated to new software developers, but was a normal solution to engineers of Randall's generation, who learned to code when computer memory space was still at a premium. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is a far less efficient use of resources than upgrading to the widely available and supported 64-bit Unix time replacement format (which much better fits 64- and even 32-bit hardware than a 33-bit format does) and software compatibility libraries.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

[A timeline rectangle with 37 short dividing lines between the two ends, defining it into 38 minor sections, with the label "2000" above, associated with the leftmost edge, "2038" associated with the rightmost edge and "2019" directly over the centermost division that starts the section which covers that year, which is also extended to form a dotted line divided the whole height of the timeline into two equal 19-section halves. The left half has the label "Recovering from the Y2K bug" and the right half is labeled "Preparing for the 2038 bug". A triangular arrowhead labeled "Now" is also above indicating a rough position most of the way through the section that would represent the year 2022.]

[Caption:] Reminder: By now you should have finished your Y2K recovery and be several years into 2038 preparation.

{{comic discussion}}
[[Category:Calendar]]
[[Category:Computers]]
[[Category:Programming]]
[[Category:Timelines]]

2697: Y2K and 2038

2022-11-11T19:48:48Z

172.70.230.159:

{{comic
| number = 2697
| date = November 11, 2022
| title = Y2K and 2038
| image = y2k_and_2038_2x.png
| imagesize = 527x190px
| noexpand = true
| titletext = It's taken me 20 years, but I've finally finished rebuilding all my software to use 33-bit signed ints.
}}

==Explanation==
{{incomplete|Created by a Y2K-BRICKED BOT. Do NOT delete this tag too soon.}}

[[File:Year 2038 problem.gif|thumb|An animation of the 2038 bug in action. The {{w|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]]

The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years not correctly handling the year 2000, such as by treating it as 1900 or 19100. The {{w|year 2038 problem}} is a similar issue with timestamps in {{w|Unix time}} format, which will overflow their {{w|Signed number representations|signed}} 32-bit binary representation on January 19, 2038.

While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. On New Year's Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of these that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which likely made up for the the cost of merely correcting the date bug.{{Actual citation needed}}

It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity has allowed many otherwise vulnerable systems to already upgrade to wider timestamp and date formats, so there is reason to believe that it may be even less consequential and expensive. The 2038 problem has been previously mentioned in [[607: 2038]] and [[887: Future Timeline]].

The caption in this comic provides a punchline: everyone should have completed their "Y2K recovery" as it has been a full 22 years since the year 2000. It is highly unlikely that there are more than a very few consequential older systems that still suffer from this bug, and any modern systems have already been built to handle the years 2000 and later.

The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

[A timeline rectangle spanning from 2000 to 2038 divided into two halves. The first is labeled "Recovering from the Y2K bug" and the second labeled "Preparing for the 2038 bug." An arrow labeled "Now" is pointing approximately at the year 2022.]

[Caption:] By now you should have finished your Y2K recovery and be several years into 2038 preparation

{{comic discussion}}
[[Category:Calendar]]
[[Category:Computers]]
[[Category:Programming]]
[[Category:Timelines]]

2697: Y2K and 2038

2022-11-11T19:48:24Z

172.70.230.159:

{{comic
| number = 2697
| date = November 11, 2022
| title = Y2K and 2038
| image = y2k_and_2038_2x.png
| imagesize = 527x190px
| noexpand = true
| titletext = It's taken me 20 years, but I've finally finished rebuilding all my software to use 33-bit signed ints.
}}

==Explanation==
{{incomplete|Created by a Y2K-BRICKED BOT. Do NOT delete this tag too soon.}}

[[File:Year 2038 problem.gif|thumb|An animation of the 2038 bug in action. The {{w|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]]

The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years not correctly handling the year 2000, such as by treating it as 1900 or 19100. The {{w|year 2038 problem}} is a similar issue with timestamps in {{w|Unix time}} format, which will overflow their {{w|Signed number representations|signed}} 32-bit binary representation on January 19, 2038.

While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. On New Years Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of these that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which likely made up for the the cost of merely correcting the date bug.{{Actual citation needed}}

It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity has allowed many otherwise vulnerable systems to already upgrade to wider timestamp and date formats, so there is reason to believe that it may be even less consequential and expensive. The 2038 problem has been previously mentioned in [[607: 2038]] and [[887: Future Timeline]].

The caption in this comic provides a punchline: everyone should have completed their "Y2K recovery" as it has been a full 22 years since the year 2000. It is highly unlikely that there are more than a very few consequential older systems that still suffer from this bug, and any modern systems have already been built to handle the years 2000 and later.

The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

[A timeline rectangle spanning from 2000 to 2038 divided into two halves. The first is labeled "Recovering from the Y2K bug" and the second labeled "Preparing for the 2038 bug." An arrow labeled "Now" is pointing approximately at the year 2022.]

[Caption:] By now you should have finished your Y2K recovery and be several years into 2038 preparation

{{comic discussion}}
[[Category:Calendar]]
[[Category:Computers]]
[[Category:Programming]]
[[Category:Timelines]]

Main Page/sandbox

2022-11-04T02:22:31Z

172.70.230.159:

If you get to this sandbox page, say hi! —[[User:EnderPlays|EnderPlays]] 09:11, 18 October 2022
:Hi —[[User:While False|While False]] ([[User:While False/explain xkcd museum|'''museum''']] | [[User talk:While False|talk]] | [[special:Contributions/While_False|contributions]] | [[special:Log/While_False|logs]] | [[Special:UserRights/While_False|rights]]) 15:31, 18 October 2022 (UTC)
:Hi
:Hi! [[User:Netherin5|“That Guy from the Netherlands”]] ([[User talk:Netherin5|talk]]) 16:42, 21 October 2022 (UTC)
:Hi! {{User:PoolloverNathan/Signature}} 17:33, 25 October 2022 (UTC)
:hi! [[User:JLZ0kTC5|JLZ0kTC5]] ([[User talk:JLZ0kTC5|talk]]) 17:38, 25 October 2022 (UTC)
:Hi! [[Special:Contributions/172.69.68.22|172.69.68.22]] 12:05, 2 November 2022 (UTC)Bumpf
Hi [[Special:Contributions/172.70.230.159|172.70.230.159]] 02:22, 4 November 2022 (UTC)

2690: Cool S

2022-10-27T02:03:59Z

172.70.230.159:

{{comic
| number = 2690
| date = October 26, 2022
| title = Cool S
| image = cool_s_2x.png
| imagesize = 325x327px
| noexpand = true
| titletext = Although I hear they were caught cheating off of Rosalind, who sat at a desk in front of them.
}}

==Explanation==
{{incomplete|Created by a COOL MIDDLE SCHOOL RESEARCHER - Please change this comment when editing this page. Do NOT delete this tag too soon.}}
The '{{w|Cool S}}' is a stylized drawing of the letter "S". It is a popular doodle among teenagers as it can be quickly hashed out using six vertical lines which are then connected with an appropriate pattern of diagonal lines.

Randall first draws the steps to make the Cool S. Then he draws a chain of repeats of this pattern, excluding the end caps, making something that looks like a twisted rope. Finally he separates the two strands and adds cross bars, creating something that turns out to have a visual similarity to the discovered helical structure of {{w|DNA}}. However, although the final diagram is a double helix, the chirality, or "handedness", is backwards: an actual DNA molecule winds in the opposite direction (clockwise, if you're looking at it end-on). (The tutorial at [http://realerthinks.com/correctly-draw-dna/ How to (correctly) draw DNA] describes this in more detail.)

He posits that the helical shape of DNA was originally discovered when somebody decided to doodle this extended S pattern.

Understanding the shape of the DNA molecule was an important step towards understanding how it duplicates itself and serves as a template for RNA. In real life, {{w|Francis Crick}} and {{w|James Watson}} were awarded a Nobel Prize for this discovery.

The title text is a reference to {{w|Rosalind Franklin}}, who made a material contribution to the discovery of DNA but was [https://web.archive.org/web/20160927113256/http://www.biomath.nyu.edu/index/course/hw_articles/nature4.pdf controversially not included in the Nobel Prize], although the reason was not as biased as common belief supposes. She wasn't excluded due to sexism, but because she had died in 1958, five years before the prize was awarded and as such was ineligible. Franklin's boss at the time of the discovery, Maurice Wilkins, was also named on the prize. Wilkins had shared some of Franklin's data with Watson, who then shared what he saw with Crick. None of the three men ever told Franklin that Watson and Crick had based their model on her data.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

:[10 drawings evolving from simple dashes, to a "cool S" symbol, to a representation of DNA.]

:The structure of DNA was originally discovered by a group of especially cool middle school researchers.

{{comic discussion}}
[[Category:Biology]]
[[Category:Comics featuring real people]]