explain xkcd - User contributions [en]

673: The Sun

2025-06-01T11:27:16Z

172.69.194.19: /* Explanation */

{{comic
| number = 673
| date = December 9, 2009
| title = The Sun
| image = the_sun.png
| titletext = Obligatory bad guy: This operation is sheer foolishness, and it's not happening on my watch! Mainly because I can't figure out how to adjust the time.
}}

==Explanation==
This comic makes fun of {{w|science fiction}} {{w|disaster movies}}, especially the 2003 film ''{{w|The Core}}'' in which a group of scientists travel through the Earth's mantle to place a series of nuclear devices in order to speed up the slowing rotation of the Earth's core and prevent a complete collapse of Earth's magnetic field. The comic is also a pun on "Daylight Saving Time", using it to mean saving the Sun's light rather than its usual meaning of the semi-annual shift in clocks to "save" daylight for a more useful part of the day.

This comic presents the next film from the makers of ''The Core''. In this case an astronomer, [[Ponytail]], discovers that the Sun's fusion is failing. The two [[Cueball]]-like guys behind her are not impressed; one is disbelieving and the other is not interested ("whatever"). But then Ponytail rallies them by pointing out the impeding doom for Earth and they call {{w|NASA}}. A group of astronauts at NASA takes the call and the leader (another Cueball-like guy) describes what could happen in trailer-like fashion:
*The earth bathed in eternal darkness?
*A night without a dawn? Not on my watch!
Then he tells his team of astronauts - a fourth Cueball-like guy, [[Megan]] and another Ponytail - to "saddle up", and the comic finishes with the poster (a copy of the one for The Core with the Sun in place of the Earth's mantle) of this new movie called ''The Sun'' (hence the title of the comic) with two taglines:
*It's Daylight Saving Time.
*Never fall back.

The movie describes a scenario in which "the Sun's fusion is failing". This is in fact the exact plot of the British science fiction film ''{{w|Sunshine (2007 film)|Sunshine}}'' from 2007, released two years before this comic, which was about a group of astronauts sent on a mission to reignite a dying {{w|Sun}} with a battery of nuclear bombs.

The {{w|Sun}}'s energy comes from {{w|nuclear fusion}} reactions among the extremely hot, dense hydrogen nuclei in its core. The idea of the Sun's fusion failing is rather ridiculous from a scientific perspective, because the fusion reactions are well understood and the Sun has enough hydrogen to fuel it for about 5 billion more years. Even if a sun's hydrogen was getting low, it would {{w|Star#Post–main sequence|start fusing helium}} and begin expanding into a {{w|red giant}}. This would then make the Earth uninhabitable. In other words, if the Sun stopped fusing, we wouldn't have to worry about less sunlight, we would have to worry about more.

In any case, it appears to be failing and the solution is to send a team of astronauts to the Sun to restart the fusion. The team leader is motivated by concern that if the Sun's fusion stops, there will be no more light, and so the earth will be in perpetual darkness.

The poster in the final panel gives the movies two taglines, both puns. {{w|Daylight saving time}} (DST) refers both to the policy of changing clocks and to the scenario in this movie in which it is time for the team to literally save the Sun's daylight from being extinguished. "Never fall back" is an additional word play on the {{w|mnemonic}} used (in the States at least) to remember the direction to change clocks. The mnemonic, {{w|Spring forward, fall back#Terminology|"spring forward, fall back"}} indicates that in the springtime, clocks get set ahead by an hour, while in fall the clocks are set backwards an hour. The phrase "fall back", however, can also mean to retreat from a battle.

[[Randall]] seems to believe that DST makes little sense today and he has made it clear in [[:Category:Daylight saving time|several comics]] that he is not a fan — or at least not a fan of the twice-yearly transitions between the two semi-arbitrary time standards. As DST is the main joke of the comic (and the title of the next movie), the comment from the astronaut about this not happening "on my watch" may be a pun relating to his wristwatch. He would not wish to have DST on his watch! This meaning is made clear in the title text (see below).

The comic makes fun of these disaster movies in a couple of ways. The characters in the first panel acknowledge that the scenario doesn't make sense scientifically, but are prepared to sacrifice scientific value for the plot. Also, in the second panel, the team is to be composed of {{w|NASA}}'s "hottest astronauts", which makes fun of the fact that the characters in movies are much more attractive than average, and the fact that they will be much hotter when they reach the Sun. The team leader expresses his concern with a few buzz phrases often used in such films.

An alternative explanation, which would make sense scientifically, is that the Sun had never stopped working, and Ponytail merely assumed that something was wrong with the Sun when the sunrise did not occur at its normal time, but that was only because the clocks had been sent an hour ahead for DST, and not because of anything wrong with the Sun, which continued working properly, oblivious to earth clocks.

The title text continues the lunacy (solacy?) of the situation with the cliché of the "obligatory bad guy" (or perhaps some version of {{tvtropes|DaChief|inflexible manager}}) — a person in the plot who acts antagonistic, often for the flimsiest of reasons. There is also the common complaint, especially among the technologically inept, that he can't figure out how to change the time, relating back to DST, and using the phrase "on my watch" as a pun here (if you interpret "watch" in the sense of a wristwatch). The phrase "on my watch" was used in the comic itself, but it isn't clear whether it was intended as a pun. It's possible that Randall realized he missed his chance to make a great pun with that phrase, inspiring the title text.

Note that while four different Cueballs in a comic is [[:Category:Multiple Cueballs|not uncommon]], it is rare that two different Ponytails are shown in one comic.

==Transcript==
:[Caption above the first panel, which is lower than the rest:]
:Coming this March from the makers of ''The Core''...
:[Ponytail is standing on a raised platform looking through a huge telescope (exiting the panel to the left) in an observatory. To her right is a large station with three screens and two Cueball-like guys are standing on the floor to the of that right. Behind them is another station with a large panel showing two circles with an arrow pointing from the top left to the bottom right.]
:Ponytail: The sun's fusion is failing!
:Man 1: Does that make sense?
:Man 2: Whatever.

:[Zoom in on the scene where Ponytail throws up her arms as she turns towards the two Cueball, still standing on the platform, but the rest of the background is white. The first Cueball turns around and points to the other Cueball who has also turned around and has taken a phone of the hook, the curled cord disappearing at the panels right edge.]
:Ponytail: If we don't send a ship to restart it, it could go out completely!
:Man 1: Call NASA!
:Man 2 (into the phone): Assemble our hottest astronauts.

:[Another Cueball-like guy has taken the call, and still stands with the phone in hand, the cord attached to the phone hook on the panels left edge. He stands with the helmet of a space suit under his other arm, obviously being an astronaut. Behind him is a fourth Cueball-like guy, Megan and another Ponytail.]
:Astronaut: The earth bathed in eternal darkness? A night without a dawn? Not on my watch!
:Astronaut: Saddle up.

:[The same four characters are shown in silhouette on gray background (still only one with helmet under arm), casting huge shadows towards the bottom of the panel from the dim sun in the top center of the panel. Above the sun is written a tagline (for the movie) and at the bottom of the panels with shadows falling over it is a second smaller tagline:]
:It's
:<big>'''''Daylight saving time.'''''</big>
:Never fall back.

{{comic discussion}}

[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Megan]]
[[Category:Multiple Cueballs]]
[[Category:The Core]]
[[Category:Physics]]
[[Category:Daylight saving time]]
[[Category:Telescopes]]
[[Category:Puns]]

Talk:3040: Chemical Formulas

2025-01-22T18:51:06Z

172.69.194.19:

I believe the diagram on the left incorrectly shows a double-bond between the carbon and the OH pair. -- [[User:Dtgriscom|Dtgriscom]] ([[User talk:Dtgriscom|talk]]) 03:13, 21 January 2025 (UTC)
:: ''"incorrectly shows a double-bond"'' This may be more correct (there are many ways to draw it):
:: https://www.shutterstock.com/image-vector/formic-acid-molecule-structure-260nw-1359283460.jpg [[User:PRR|PRR]] ([[User talk:PRR|talk]]) 03:42, 21 January 2025 (UTC)
:::what’s a double bond? '''[[User:42.book.addict|42.book.addict]][[User talk:42.book.addict|Talk to me!]]''' 04:25, 21 January 2025 (UTC)
:::: if a hydrogen atom had hands it would have one and could only hold other atoms with one hand. Some atoms have more than one hand and in the case of a double bond can hold another atom with two hands. I almost recall something about electron orbits and spaces. I hope this isn't to unhelpful.[[Special:Contributions/108.162.242.58|108.162.242.58]] 05:08, 21 January 2025 (UTC)
:::::ohhhh, i think i get it now. thanks! '''[[User:42.book.addict|42.book.addict]][[User talk:42.book.addict|Talk to me!]]''' 05:19, 21 January 2025 (UTC)
::::::For the molecules concerned (and ignoring some more exotic situations), you just need to know that;
::::::*Hydrogen should have only one bond in total (H-C... or H-O..., in whatever direction. An H-H would be H2, or hydrogen (probably!) gas unbonded to anything else).
::::::*Oxygen should have two bonds (...X-O-Y... as part of a link between X and Y, like the (acceptibly abbreviated) -OH ('hydroxy') group attached to a carbon; or ...C=O, as oxygen double-bonded to a carbon with those two bonds available). H-O-H would be water (H2O), O=O would be the pure oxygen molecule (O2).
::::::*Carbon has ''four'' bonds, which can be:
::::::**Four singles, often with alkane links, ...C-C... with three things (more carbons, hydrogens or hydroxys/etc) hanging off as well, as part of a hydrocarbon/similar, starting with CH4 which has ''only'' hydrogens hanging directly off the one and only carbon, longer chained alkanes string carbons together with two hydrogens off of each mid-carbon (in three-or-more chains) and a third completing each end.
::::::**Two singles and a double, like the ...C=O with two further off-shoots, or else an ...C=C... as an alkene link (with two things/continuations of carbon hanging off each of the ends of that carbon-pair),
::::::**''Two'' doubles (cumulenes, like ...C=C=C..., are rare, but O=C=O is the really common CO2/carbon dioxide molecule in its entirety), or
::::::**A single and a triple, typically back-to-back as alkynes, ...-C≡C-..., ''or'' something like -C≡N (nitrogen has exactly three bonds!) for a cyano-group, but it's often a strained group.
::::::**A quadruple-bond would be... beyond this basic overview.
::::::**(Benzene rings effectively have 1.5 shared links between the adjacent carbons, or alternating single/double three times round the six Carbon-Carbon links, leaving one "hang off" bond from each of them, without bothering which ring-bonds are single or double.)
::::::**(Graphene sheets effectively have three singles, plus "two halves" weakly bonding to adjacent graphene sheets, in actual graphite; or whatever else fun thing you're doing with graphene/nanotubes/buckyballs ''singly''...)
::::::If you check the "Hackoo", the C has ''five'' bonds (at least until and unless Randall corrects it!), the error most obviously (just from the above knowledge!) because the O in the -OH (i.e. -O-H) has three bonds (...C=O-H) where it should only have two (...C-O-H).
:::::::If I still had access to the university and its DFT calculator, I'd be tempted to do a run how stable the ion HC+=O=O+H would be (HCOOH with two electrons removed, charge at C and O), the only way to make sense of the formula. And write an April article for the regular column of the German Chemists Society Newsletter. Here is the data of the monocation: https://atct.anl.gov/Thermochemical%20Data/version%201.140/species/?species_number=731 ...wait, did I just nerdsnipe myself?[[Special:Contributions/172.71.148.103|172.71.148.103]] 08:48, 21 January 2025 (UTC)
::::::It can perhaps be explained as an interestingly radical-enhanced number of bonds, though you'd notate it differently (in diagram ''and'' formula) and it wouldn't really be the ethanoic/formic acid that Cueball(/Randall) clearly intends it to be. Simple slip of the stylus, maybe, from someone more a physical scientist who [[520: Cuttlefish|isn't always affiliated to chemical sciences]], so may not have realised when glancing at the 'finished' comic. (Or it's yet another (too?) subtle dig at the Cueball character that he's set up to fail/be creatively-wrong.) [[Special:Contributions/172.70.90.108|172.70.90.108]] 07:01, 21 January 2025 (UTC)

Similar to 2492 [[User:Chakra|Chakra]] ([[User talk:Chakra|talk]]) 03:18, 21 January 2025 (UTC)

My favorite hydrocarbons are C6H6 (Bouba) and C5H12 (Kiki) [[Special:Contributions/172.69.70.105|172.69.70.105]] 03:21, 21 January 2025 (UTC)

I assume 'Nackle' is NaCl (Sodium Chloride, aka salt) [[User:Pvnic|Pvnic]] ([[User talk:Pvnic|talk]]) 03:30, 21 January 2025 (UTC)
: for blood pressure reasons I use fake salt = potassium chloride. Note to self: don't say "please pass the kackle" because at best at best I'd get a funny look and a chicken nugget. (Thinking) Or do. Chicken nuggets are good.[[Special:Contributions/172.68.245.179|172.68.245.179]] 04:41, 21 January 2025 (UTC)
::Wouldn't that be more like "kickle" or "keckle"? [[Special:Contributions/162.158.212.173|162.158.212.173]] 07:10, 21 January 2025 (UTC)
And in the meta-humor department, the explanation message "Created by a BORON-OXYGEN-TANTALUM-URANIUM-TITANIUM-MOLYBDENUM-TITANIUM-CARBON-ALUMINUM-LITHIUM" abbreviates to "B O Ta U Ti Mo Ti C Al Li", or "BOT aUTiMoTiCaLLi". [[User:Jordan Brown|Jordan Brown]] ([[User talk:Jordan Brown|talk]]) 04:27, 21 January 2025 (UTC)
: The bot probably drank too much choo-choo-oh (CH₃CH₂OH) [[Special:Contributions/162.158.103.187|162.158.103.187]] 15:57, 22 January 2025 (UTC)
: OH! Thank you. [[Special:Contributions/172.68.245.179|172.68.245.179]] 04:41, 21 January 2025 (UTC)
:: In my family, we actually do (occasionally) call it "nackle", so I updated the explanation accordingly. [[User:Gbisaga|Gbisaga]] ([[User talk:Gbisaga|talk]]) 16:25, 21 January 2025 (UTC)

Guilty as charged! (And I got a Ph.D. in chemistry...) [[Special:Contributions/172.68.195.130|172.68.195.130]] 08:35, 21 January 2025 (UTC)
:nice! which uni? '''[[User:42.book.addict|42.book.addict]][[User talk:42.book.addict|Talk to me!]]''' 22:46, 21 January 2025 (UTC)

The 'put it on a plate' and 'take with a pinch of salt' stuff all seems a bit of a stretch.[[Special:Contributions/172.69.194.59|172.69.194.59]] 10:08, 21 January 2025 (UTC)
:I don't see any sign that anybody would anyone be literally requiring salt, so more probably is one or other figurative use. "Are you upset? I don't ''care'' you're upset. Pass the salt... Mmmmm..." from our Cueball or "Yeah, so I'm hearing what you're telling me, but I'm gonna ignore your inane mutterings, so pass the salt...". Or maybe from a similar sort of vein as "Are you salty about that? I think you're salty, boo-hoo!" sarcastic response. There are plenty of possible phrases using the substance in analogy, and I'm sure others could be imagined by anyone worth their salt. [[Special:Contributions/172.70.91.246|172.70.91.246]] 14:45, 21 January 2025 (UTC)
::There's absolutely no indication that the title text is spoken by anyone in the comic. It's an example of a common phrase with the twist of using the phonetic pronunciation described here. It's supposed to be a secondary punchline of sorts, and overthinking it doesn't make it funnier. [[Special:Contributions/172.68.50.7|172.68.50.7]] 09:19, 22 January 2025 (UTC)
:::Many TTs ''are'' clearly spoken by the comic's characters (some readily identifiable as one or other of the protagonist, antagonists or off-panel voices - restating their initial point and/or following-up their ripostes). Others are the "Voice of (Relative) Sanity" that is Randall, only then emerging out of the fourth wall (as a counterpoint to ''whatever'' his possible avatars on-page might be thinking or saying).
:::And it's also entirely consistent for it to be left flapping in the wind. Either it was left directly ambiguous, or (despite whatever intent), we're able to reinterpret according to our own individual impressions. I think it's not a problem to appreciate the different nuances.
:::The secondary punchline ''might'' be asking for salt as an accompaniment for the vinegar (if this isn't too {{w|Fish and chips#Accompaniments|anglocentric}} for Randall, as a Leftpondian himself who might not actually partake of that particular combination), but it does seem like it lacks any reason for the off-page switch from a 'presentation' on organic chemistry to some random cullinary scenario. As opposed to directly messing about with obtuse language, which flows straight into a metaphorical or figurative derision (from whoever, to whoever).
:::And "overthinking it" is ''very'' on-brand, from both creator and his fandom. I'd personally have no problem suggesting that the salt-request was primarily a put-down phrase, but with the possibility that it was ''actually'' about heretofor unreferenced table-salt, just so that no opinion (or lingering need for further satisfactory explanation) is left unsatisfied. It's all grist to the mill. [[Special:Contributions/141.101.99.99|141.101.99.99]] 15:02, 22 January 2025 (UTC)

I wonder if this is inspired by people in Cyberpunk 2077 pronouncing CHOOH2 (the fuel cars are powered by in universe) as "chew two." [https://cyberpunk.fandom.com/wiki/CHOOH2#:~:text=CHOOH2%20is%20not%20actually%20the%20chemical%20formula%2C%20it%27s%20just%20a%20moniker%20for%20marketing%20purposes. Game wiki page.] [[Special:Contributions/172.69.22.31|172.69.22.31]] 17:50, 21 January 2025 (UTC)

Edible oil analysis is now like B-Box [[User:799571388|799571388]] ([[User talk:799571388|talk]]) 21:04, 21 January 2025 (UTC)

Can we make an emperical formula-to-speech model? [[Special:Contributions/172.70.215.72|172.70.215.72]] 02:42, 22 January 2025 (UTC)
:Oh definitely. I played with a text-to-speech freeware program back in the late '80s/early '90s that used the ''PC speaker'' to say things. Surprisingly well, for its simplicity, but you ideally needed to convert text to its syllabary to not just plough through what ''it'' thought it should, although English is tough ("... pl-a-ow th-r-oo w-ot IT th-or-t it sh-ud, awl-th-oh IN-g-l-isch iz t-uff", or similar, is what it really needed). I'd be surprised if Alexa-era synth software with another 30+ years of development (and actual soundchips, plus clock frequencies greater than at most the tens of megahertz of 286s/386s this would run on) don't have extensive pre-processing that could say something that derives from Cr2(CH3CO2)4(H2O)2 without batting a virtual eyelid ("Cratch Coho"?) — or at least not stumbling and stuttering. Assuming they don't use their amazing internet-connected reference system to look up and say "Chromium-2 acetate hydrate". ;) [[Special:Contributions/172.70.163.11|172.70.163.11]] 16:54, 22 January 2025 (UTC)

There are certainly some chemical formulas that get pronounced this way. {{w|Dioxygen difluoride|FOOF}} comes to mind. [[Special:Contributions/162.158.79.40|162.158.79.40]] 17:12, 22 January 2025 (UTC)
:It's also an onomatopoeia, being the sound you get if you spill it on... pretty much anything. (If you can blot out your own accompanying screams.) [[Special:Contributions/172.69.194.19|172.69.194.19]] 18:51, 22 January 2025 (UTC)

3035: Trimix

2025-01-09T10:25:42Z

172.69.194.19: /* Explanation */ Sorting a word-salad of an edit.

{{comic
| number = 3035
| date = January 8, 2025
| title = Trimix
| image = trimix_2x.png
| imagesize = 436x259px
| noexpand = true
| titletext = You don't want the nitrogen percentage to be too high or you run the risk of eutrophication.
}}

==Explanation==
{{incomplete|Created by a FLOATING TRIMIX SCUBA DIVER - Please change this comment when editing this page. Do NOT delete this tag too soon.}}
{{w|Trimix (breathing gas)|Trimix}} is a gas used in {{w|SCUBA}} tanks that consists of {{w|helium}}, {{w|oxygen}}, and {{w|nitrogen}}. Trimix comes in some standard ratios between the component gases, depending on the required diving depth, for example 21/35/44 (percentage oxygen/helium/nitrogen), 18/45/37 and 15/55/30 for increasing depth. Helium replaces a portion of the nitrogen to minimize nitrogen's narcotic effects at greater depths and to ease the effort required for breathing. This comic jokes that if the helium amount is too high, a diver will float away before reaching the water to start a dive, as a helium balloon will do if not securely tethered.

The reason a helium balloon creates lift is that it can inflate. The balloon has a thin and expandable layer, weighing almost nothing, that allows the intrinsically less dense gas to take up space at not much more than atmospheric pressure. The total weight of the filled balloon is less than the total weight of the air it displaces, thus creating {{w|buoyancy}}. A SCUBA tank is made of metal, is heavy and cannot inflate{{Citation needed}}, which means it will never become lighter on air as you pump more of ''any'' kind of gas into it. (In fact, it will just get heavier, as an inflating helium balloon does, but without the over-compensating increase in volume.) Thus it will never be able to create any kind of lift, no matter the amount of helium or any other gas that is compressed inside of it, and neither could a typical SCUBA tank even attain lift by thoroughly emptying it to try to create a {{w|vacuum balloon}}.

For a standard SCUBA tank to serve as a helium balloon capable of lifting a human diver of average size (not counting extra mass from dive accoutrements such as weight belts), it would need to contain approximately 70 kg of pure helium. This loading is more than an order of magnitude greater than the norm of around 3 kg of gas. It might prove difficult to fit such a tank with a regulator that could deliver the gas evenly and safely, and the absence of oxygen could be detrimental to the diver. Moreover, it would cost on the order of US$2000-4000 to charge the tank, an extra financial burden on an already expensive operation. Consider also that, at a mere 10 atm pressure, the density of helium is greater than that of air, hence a fixed-wall helium-containing tank at that density won't float. Normally-loaded SCUBA tanks are around 150 atm pressure, with a correspondingly higher density of the contained gas, and correspondingly lower likelihood that the tank will float. For these reasons, SCUBA divers floating in air are seldom encountered, the helium content of their tanks notwithstanding.

More to the point, the rise into the air would be caused by Archimede's force, which is proportional to the weigh of the displaced volume. Air being ~ 1,3 g/L, it takes 1m3 to lift 1,3kg, and ~50m3 to lift a 65kg person. Such a volume represents a 2.3m radius sphere, which is obviously way bigger than the helium tank.

The real reason SCUBA divers need to be careful with the amount of helium is to not get too little oxygen or too much nitrogen.

The title text asserts that a trimix diver whose gas mix contains an excess of nitrogen runs "the risk of eutrophication". The term {{w|Eutrophication|eutrophication}} describes the process by which nutrients ("fertilizers") accumulate in an environment, typically a body of water, leading to consequences that are often unfortunate for inhabitants or users of that environment. The human body is an ecosystem, but one that is not typically subject to eutrophication due to its manner of acquiring and jettisoning nutrients. Moreover, the nitrogen in trimix is diatomic elemental nitrogen, not the {{w|Nitrogen_fixation|"fixed"}} nitrogen that serves as a component of eutrophication. The diver would not breathe "fixed" nitrogen unless nitrogen-fixing bacteria were somehow incorporated into the SCUBA gear, a complex feature of dubious utility.

[[Randall]] addressed the question "how much helium is needed to lift a human body" in a [https://what-if.xkcd.com/62/ What if?] article. Helium has also featured in comics [https://xkcd.com/2766/ 2766] and [https://xkcd.com/2972/ 2972].

==Transcript==
:[In a single frame five images of Cueball is shown as a kind of carton, with each image a later time in the process. The first image to the left shows Cueball standing by the shore of a body of water. He is wearing SCUBA gear, goggles, breathing tubes, SCUBA tanks with a small H logo on it on his back, and swimming flippers, which almost touch the water.]

:[In the next four images he has the same equipment on, but with changes. It should be seen as he is still at the edge of the water, but that is not drawn in the next four depictions of Cueball.]

:[In the second image to the right of the first, Cueball's SCUBA tank is beginning to float upwards, so the end that is not teetered to Cueball move out and up, as shown with three small lines beneath the tank.]

:[In the third image the SCUBA tank is now floating above Cueball's head and the strings pull his arms a bit upwards. Cueball has turned his head looking up at the tank floating above and behind his head. Again three small lines beneath the tank indicates it is moving upwards.]

:[In the fourth image Cueball is now being lifted up, so his feet are now off the ground and he is tilting forward. The tank is now pointing it's bottom almost straight up and Cueball is looking down with his arms out the each side as the tank pulls him up. Two lines on either side of the tank indicate that it now wobbles above him as it lifts him up.]

:[In the fifth and last image the SCUBA tank is now pulling a dangling Cueball high above the ground, above his head's height in the first image. The tank is now turned so it points it's bottom to the left with lines on either side indicating wobbling motion. Cueball is floating as lying prone a bit bended on the middle as the tanks straps pulls him up. At this point he yells:]
:Cueball: ''Help!''

:[Caption below the panel:]
:Trimix SCUBA divers need to be careful not to let the helium percentage get too high.

{{comic discussion}}

[[Category:Comics featuring Cueball]]

Talk:3026: Linear Sort

2024-12-23T18:01:15Z

172.69.194.19:

First in linear time![[User:Mr. I|Mr. I]] ([[User talk:Mr. I|talk]]) 13:28, 18 December 2024 (UTC)

Due to the fact that O(nlog(n)) outgrows O(n), the Linear Sort is not actually linear. [[Special:Contributions/162.158.174.227|162.158.174.227]] 14:21, 18 December 2024 (UTC)
:If your sleep() function can handle negative arguments "correctly", then I guess it could work. [[Special:Contributions/162.158.91.91|162.158.91.91]] 16:27, 18 December 2024 (UTC)
::Yes, on a machine where sleep() allowed negative values (somewhat similarly but more limited than [https://esolangs.org/wiki/TwoDucks TwoDucks]), the algorithm would take linear time regardless of the used constant in place of 1e6. Also, with a smaller constant, the so-called linear optimization is not completely dissimilar to [https://en.wikipedia.org/wiki/Radix_sort Radix sort], which has time-complexity of O(mn), where m is the bitlength of the item, which becomes linear for any item of limited bitlength (such as int64_t). In school we were taught that this is effectively linear, but that is deceptive, since the actual sort time grows to log(n) by virtue of requiring longer memory per item to fit more items in such a list, because a radix sort of 16 bit integers would be limited to useful lists of up to 65536 unique values to sort, and you'd need to grow them to 32 bit integers. If the sleep constant was chosen precisely to match the worst case [https://en.wikipedia.org/wiki/Timosrt Timsort] would take - and I pick timsort because in addition to having O(n) best case, equal items won't be swapped or take time for such swaps - the time complexity deception would be identical to that of Radix sort: The algorithm would be linear, but only until you exceed e^(sleeping steps) unique items in the list (same as radix sort, although radix sort becomes unusable, and LinearSort() only becomes slower), and the time wasted is comparable as it in both cases bounded by a number proportional to the bitlength of the (longest) value, which is usually larger than log(n'), and never smaller, if n' are the number of distinct values. So, in some ways, 1e6 is corresponding to m in a radix sort. [[Special:Contributions/172.68.190.145|172.68.190.145]] 12:10, 23 December 2024 (UTC)
:It relies on 1 second being long enough to outcompete the maximum input length provided. The joke is that most sort operations that take an entire second or more are considered too slow to be worth doing. 02:30, 22 December 2024 (UTC)

That was fast... [[User:CalibansCreations|'''Caliban''']] ([[User talk:CalibansCreations|talk]]) 15:35, 18 December 2024 (UTC)

Do I even want to know what Randall's thinking nowadays? [[User:Definitely Bill Cipher|⯅A dream demon⯅]] ([[User talk:Definitely Bill Cipher|talk]]) 16:02, 18 December 2024 (UTC)
:Does anyone every want to know what Randall is thinking nowadays? :P [[Special:Contributions/198.41.227.177|198.41.227.177]] 22:02, 19 December 2024 (UTC)

The title text would be more correct if Randall used e.g. Timsort instead of Mergesort. They both have the same worst-case complexity O(n*log(n)), but the former is linear if the list was already in order, so best-case complexity is O(n). Mergesort COULD also be implemented this way, but its standard version is never linear. [[User:Bebidek|Bebidek]] ([[User talk:Bebidek|talk]]) 16:35, 18 December 2024 (UTC)

According to my estimates extrapolated from timing the sorting of 10 million random numbers on my computer, the break-even point where the algorithm becomes worse than linear is beyond the expected heat death of the universe. I did neglect the question of where to store the input array. --[[Special:Contributions/162.158.154.35|162.158.154.35]] 16:37, 18 December 2024 (UTC)
:If the numbers being sorted are unique, each would need a fair number of bits to store. (Fair meaning that the time to do the comparison would be non-negligible.) If they aren't, you can just bucket-sort them in linear time. Since we're assuming absurdly large memory capacity. [[Special:Contributions/162.158.186.253|162.158.186.253]] 17:14, 18 December 2024 (UTC)

What system was the person writing the description using where Sleep(n) takes a parameter in whole seconds rather than the usual milliseconds? [[Special:Contributions/172.70.216.162|172.70.216.162]] 17:20, 18 December 2024 (UTC)
: First, I don't recognize the language, but sleep() takes seconds for python, C (et. al.), and no doubt many others. Second, the units don't have to be seconds, they just have to be whatever `TIME()` returns, and multiplicable by 1e6 to yield a "big enough" delay. Of course, no coefficient is big enough for this to actually be linear in theory for any size list, so who cares? To be truly accurate, sleep for `e^LENGTH(LIST)`, and it really won't much matter what the units are, as long as they're big enough for `SLEEP(e)` to exceed the difference in the time it takes to sort two items versus one item. Use a language-dependent coefficient as needed. [[User:Jlearman|Jlearman]] ([[User talk:Jlearman|talk]]) 18:02, 18 December 2024 (UTC)
: Usual where, is that the Windows API? The sleep function in the POSIX standard takes seconds. See https://man7.org/linux/man-pages/man3/sleep.3.html . [[Special:Contributions/162.158.62.194|162.158.62.194]] 18:57, 18 December 2024 (UTC)

If I had a nickel for every time I saw an O(n) sorting algorithm using "sleep"… But this one is actually different. The one I usually see feeds the to-be-sorted value into the sleep function, so it schedules "10" to be printed in 10 seconds, then schedules "3" to be printed in 3 seconds, etc., which would theoretically be linear time, if the sleep function was magic. [[User:Fabian42|Fabian42]] ([[User talk:Fabian42|talk]]) 17:25, 18 December 2024 (UTC)

This comic also critiques/points out the pitfalls of measuring time complexity using Big-O notation, such as an algorithm or solution that runs in linear time still being too slow for its intended use case. [[User:Sophon|Sophon]] ([[User talk:Sophon|talk]]) 17:46, 18 December 2024 (UTC)

Current text is incorrect, but I'm not sure how best to express the correction -- there do exist O(n) sorting algorithms, they're just not general-purpose, since they don't work with an arbitrary comparison function. See [https://en.wikipedia.org/wiki/Counting_sort counting sort]. [[Special:Contributions/172.69.134.151|172.69.134.151]] 18:25, 18 December 2024 (UTC)

Hi! I'm just gonna say this before everyone leaves and goes on their merry way. Significant comic numbers coming soon:
Comics 3100, 3200, 3300, etc, Comic 3094 (The total number of frames in 'time'), Comic 4000, Comic Whatever the next April fools day comic will be, and Comic 4096. Wait for it...[[User:DollarStoreBa'al|DollarStoreBa'al]] ([[User talk:DollarStoreBa'al|talk]]) 20:42, 18 December 2024 (UTC)
:Comic 3141.592654[[Special:Contributions/172.70.163.144|172.70.163.144]] 09:16, 19 December 2024 (UTC)

As everyone observed, the stated algorithm is not theoretically linear, but only practically linear (in that the time and space to detect O(n log n) exceeds reasonable (time, space) bounds for this universe). Munroe's solution is much deeper than that though - it trivially generalises to a _constant_ O(1) bound. [run a sort algorithm, wait 20 years, give the answer]. That's the preferred way of repaying loans, too. {{unsigned ip|172.69.195.27|21:46, 18 December 2024 (UTC)}}

Continues comic 3017's theme of worst-case optimization. [[Special:Contributions/172.70.207.115|172.70.207.115]] 00:32, 19 December 2024 (UTC)

It looks as though this function does not actually do the sort in Linear Time, it only returns in Linear Time.
The MERGESORT Function itself looks to only take one parameter and does not have an obvious return value indicating that it performs an in-place sort on the input mutable list.
This means that the list is sorted at the speed of the MERGESORT function, but flow control is only returned after Linear Time.
For a single threaded program calling this function there is no practical difference, but it would make a difference if some other thread was concurrently querying the list.
A clearer linear time sort might look like this:

function LinearSort(list):
StartTime=Time()
SortedList=MergeSort(list)
Sleep(1e6*length(list)-(Time()-StartTime))
return SortedList

Leon {{unsigned ip|172.70.162.70|17:31, 19 December 2024}}
:There's such a thing as pass-by-reference, variously implemented depending upon the actual programming language used. It's even possible to accept both ''list'' (non-reference, to force a return of ''sorted_list'') and ''listRef'' (returns nothing, or perhaps a result such as ''number_of_shuffles made''), for added usefulness, though of course that'd need even more pseudocode to describe. For the above/comic pseudocode, it's not so arbitrary that a programmer shouldn't know how to implement it in their instance.
:I might even set about to do something like use a SetStartTime() and CheckElapsedTime() funtion, if there's possible use; the former making a persistant (private variable) note of what =Time() it is, perhaps to an arbitrary record scoped to any parameterID it is supplied, and the latter returning the 'now' time minus the stored (default or explicitly IDed) moment of record. I could then have freely pseudocoded the extant outline in even briefer format, on the understanding what these two poke/peek functions are. Which is already left open to the imagination for MergeSort(). [[Special:Contributions/172.69.43.182|172.69.43.182]] 18:04, 19 December 2024 (UTC)

There are situations where you want to return in O(1) time or some other time that is not dependent on the input data to prevent side-channel data leaks. While the run-time of Randall's "O(n)" algorithm has an obvious dependencies on the input data, using the "Randall Algorithm" to obscure a different algorithm can reduce the side-channel opportunities. A more sure-fire way would be to have the algorithm return in precisely i seconds, where i is the number of seconds between now and the heat death of the universe. [[Special:Contributions/172.71.167.89|172.71.167.89]] 17:49, 19 December 2024 (UTC)

;Please write an explanation for non-programmers!
I don't understand this explainxkcd. The comic itself was less confusing. Can please someone who really gets this stuff write a section of the explanation that explains the joke to people like me who do not have a theoretical programming degree? I know that is a tall task but right now it reads as rambling and a bunch of 0(n) that makes no sense to me. I can cut and paste a bash script together and make it work. I can understand that putting a sleep for a million seconds in a loop somewhere makes it slow. But a layperson explanation of what makes a sort linear, what is linear, what is funny about that approach, would be better than all the arguing about 0(n) because we don't get it. Thanks in advance! You folks are awesome! [[Special:Contributions/172.71.147.210|172.71.147.210]] 20:51, 19 December 2024 (UTC)
:Maybe this would be a good start:
::--cut here--
::An algorithm is a step-by-step way of doing things.
::A sorting algorithm is a step-by-step way to sort things.
::There are several commonly used sorting algorithms. Some have very little "overhead" (think: set-up time or requiring lots of extra memory) or what I call "molassas" (yes, I just made that up) (think "taking a long time or lots of extra memory for each step") but they really bog down if you have a lot of things that need sorting. These are better if you have a small list of items to sort.

::Others have more "overhead" or "molasses" but don't bog down as much when you have a lot of things that need sorting. These are better if you have a lot of things to sort.

::A linear sorting algorithm would take twice as long to sort twice as many unsorted items. If it took 100 seconds to sort 100 items, then it would take 200 seconds to sort 200, 300 seconds to sort 300, and so on. Algorithms that take "twice as long to do twice as much" are said to run in "Order(n)" or "O(n)" time, where "n" is the number of items they are working on, or in the case of a sorting algorithm, the number of items to be sorted.

::For traditional sorting algorithms that don't use "parallel processing" (that is, they don't do more than one thing in any given moment), a linear sorting algorithm with very little "overhead" or "molasses" would be the "holy grail" of sorting algorithms. For example, a hypothetical linear sorting algorithm that took 1/1000th of a second to "set things up" (low "overhead") and an additional 1 second to sort 1,000,000 numbers (not much "molasses") would be able to sort 2,000,000 numbers in just over 2 seconds, 10,000,000 numbers in just over 10 seconds, and 3,600,000,000 numbers in a hair over an hour.

::The reality is that there is no such thing as a general-purpose linear sorting algorithm that has very little overhead (in both time and memory) and very little "molasses." All practical general-purpose sorting algorithms either use parallel processing, they have a lot of overhead (set-up time or uses lots of memory), a lot of "molasses" (takes a long time or uses lots of memory for EACH item in the list) or they are "slower than linear," which means they bog down when you give them a huge list of things to sort. For example, let's say the "mergesort" in Randall's algorithm doesn't have much "overhead" or "molasses" and it sorts 1,000,000 items in 1 second. It's time is "O(nlog(n))" which is a fancy way of saying if you double the number, you'll more than double the time. This means sorting 2,000,000 items will take more than 2 seconds, and sorting 4,000,000 items will take more than twice as long as it takes to sort 2,000,000. Eventually all of those "more than's" add up and things slow to a crawl.

::The joke is that Randall "pretends" to be the "holy grail" by being a linear sorting algorithm, but he has lots of "molasses" because his linear sorting algorithm takes 1 million seconds for each item in the list, compared to the 1,000,000 items per second in the hypothetical "linear sorting algorithm" I proposed.

::As others in the discussion point out, Randall's "algorithm" is "busted" (breaks, doesn't work, gives undefined results) if the mergesort (which is a very fast sort if you have a large list if items) is sorting a list so big that it takes over 1 million seconds per item to sort anyways. I'll spare you the math, but if the mergesort part of Randall's "algorithm" could do 1,000,000 numbers in 1 second with a 1/1000th of a second to "set things up," it would take a huge list to get it to "bust" Randall's "algorithm."
::--cut here--
:[[Special:Contributions/162.158.174.202|162.158.174.202]] 21:44, 19 December 2024 (UTC)

:Layman's guide to O(n) time, second try:
::--cut here--
::First, "O" is "Order of" as in "order of magnitude." It's far from exact.
::O(1) is "constant time" - the time it takes me to give you a bag that contains 5000 $1 bills doesn't depend on how many bills there are in the bag. It would take the same amount of time if the bag had only 500, 50, or even 5 bills in it.
::O(log(n)) is "logarithmic time" - the time is the time it takes me to write down how many bills are in the bag. If it's 5000, I have to write down 4 digits, if it's 500, 3, if it's 50, 2, if it's 5, only 1.
::O(n) is "linear time" - the time it takes me to count out each bill in the bag depends on how many bills there are. It takes a fixed amount of time to count each bill. If there's 5000 $1 bills it may take me 5000 seconds to count them. If there's 500 $1 bills, it will take me only 500 seconds.
::O(nlog(n)) is "linear times logarithmic time" - the time it takes me to sort a pre-filled bag of money by serial number using a good general-purpose sorting algorithm (most good general-purpose sorting algorithms are O(nlog(n)) time). If it takes me 2 seconds to sort two $1 bills, it will take me about 3 or 4 times 5000 seconds to sort 5000 $1 bills. The "3 or 4" is very approximate, the important thing is that "logarithm of n" (in this case, logarithm of 5000) is big enough to make a difference (by a factor of 3 or 4 in this case) but far less than "n" (in this case, 5000).
::O(n2) is "n squared" time, which is a special case of "polynomial time." "Polynomial time" includes things like O(n3) and O(n1,000,000). Many algorithms including many "naive" sorting algorithms are in this category. If I used a "naive" sorting algorithm to sort 5000 $1 bills by serial number, instead of it taking about 15,000-20,000 seconds, it would take about 5,000 times 5,000 seconds. I don't know about you, but I've got better things to do with 25,000,000 seconds than sort paper money.
::It gets worse (O(2n) anyone? No thanks!), but you wanted to keep it simple.
:[[Special:Contributions/198.41.227.177|198.41.227.177]] 23:30, 19 December 2024 (UTC)
::Personally, I've got better things to do than sort dollar bills, full stop.[[Special:Contributions/172.70.91.130|172.70.91.130]] 09:37, 20 December 2024 (UTC)
:: O() notations is about behavior with large values, not small values. Try the "handing a bag of bills" algorithm with a few million dollar bills. You're going to need a forklift. Getting a forklift is not, in practice, instantaneous. Big N notation is almost always a joke for people trying to solve real problems. It only works on an abstract machine with some really weird (not physically achievable) properties. [[Special:Contributions/162.158.155.141|162.158.155.141]] 20:54, 20 December 2024 (UTC)

Friendly reminder that some users of this site are just here to learn what the joke is, and not to read the entire Wikipedia article on Big O Notation. Perhaps the actual explanation could be moved up a bit, and some of the fiddly Big-O stuff could be moved down? I'd do it myself, but I'm not really sure which is which. [[Special:Contributions/172.70.176.28|172.70.176.28]] 06:42, 20 December 2024 (UTC)
:I mean, it is fairly fundamental to the joke, and therefore to the explanation. It might be possible to slim it down a bit, but I don't think you can explain the joke without ''some'' explanation of Big O.[[Special:Contributions/172.70.91.130|172.70.91.130]] 09:37, 20 December 2024 (UTC)

I've just come to the conclusion that I will never 100% understand 3026. [[User:Dogman15|Dogman15]] ([[User talk:Dogman15|talk]]) 10:14, 20 December 2024 (UTC)
:Tell me that again when you've actually tried the official process...
function Understand(comic):
StartTime=Time()
ReadExplanation(comic)
Sleep(1e12*length(comic)-(Time()-StartTime))
return
:[[Special:Contributions/172.70.162.56|172.70.162.56]] 11:10, 20 December 2024 (UTC)
::The article should start off "This is a joke about Big-O notation and sorting algorithms, a topic in introductory computer science education." then continue with something like "An algorithm is computer code for solving a general problem. Big-O notation is a method for describing the efficiency of algorithms." and maybe something like "Randall has designed an algorithm that appears more efficient than commonly considered possible, claiming to solve a popular challenge of many decades, by trying to game how the Big-O approach to analysis ignores the real speed of an algorithm, instead considering how it changes when the data is changed." [[Special:Contributions/172.68.54.209|172.68.54.209]] 02:43, 22 December 2024 (UTC)

Here's my crack at a shorter explanation of the joke, without explaining the entirety of the Big-O notation Wikipedia article and without getting unnecessarily pedantic. (Please keep this in mind when critiquing this explanation! I probably know whatever simplification you notice.)
:The joke here consists of two parts: (1) a linear-time sort of a list is mathematically impossible, and yet (2) a linear-time algorithm is presented, with it being roughly correct because Big-O notation hides the full picture on purpose. The title-text joke is that someone realizes (1) and investigates (2) because of the purposeful full-picture-hiding.
:Let's start with part (2): how Big-O notation is a bit handwavy and inexact. This is not to say it's not useful in computer science research and explaining differences between algorithms, but it inherently and on purpose hides the full picture. It's kind of like rounding away unnecessary digits when doing a back-of-the-envelope physics calculation, except in Big-O, the thing that is rounded is a mathematical formula. The formula is for calculating the time it takes for an algorithm to run (whether in (nano)seconds or something abstract like "number of operations"), and it will be in terms of ''n'', which is basically "how many things does your algorithm need to process" (in this case, it's the size of a list). An algorithm might be calculated to have a running time of something complicated like 32''n''2.796+1.31''n''+6500, but it's Big-O "rounding" would be expressed as O(''n''2.796). This is because as ''n'' grows larger and larger (into the billions), the extra stuff is irrelevant: except in special cases, an algorithm with a running time of O(''n'') will take less time than an algorithm taking O(''n''2) time, because no matter what the stuff you "rounded away" was, the former will eventually be less than the latter once ''n'' grows big enough.
:With the relevant bits of Big-O notation explained, we can look at the problem of sorting a list. This is a classic problem in computer science and it comes up in coursework all the time, so Randall assumes a lot of his audience will be familiar with it. Part (1) of the joke is that a linear, ''i.e.'' O(''n'') time, sorting of a list is mathematically impossible: just checking whether a list is sorted in the first place requires comparing every pair of elements at least once, taking O(''n'') time, and after this you have to swap elements that are out of place and check again. If you build an algorithm carefully you can get away with doing log(''n'') "scans" back and forth along the list, ending up doing log(''n'') scans of ''n'' time each, which comes to O(''n'' × log(''n'')) time. This "O(''n'' log ''n'')" time is accepted as the lowest general sorting algorithm average-case run-time, and all improvements to sorting algorithms are in improving the stuff that Big-O notation hides – remember how we rounded away all those factors as unnecessarily complicated and irrelevant? Turns out they're actually relevant in practice! They can be fine-tuned for real computers and practical inputs; the mergesort in the comic is special because it's guaranteed to always take the same time, no matter the input.
:Putting both parts together: the "linear sort" presented is "linear", taking O(''n'') time, not because it has actually magically found a way to cheat at math and do sorting faster than is possible, but because O(''n'') notation hides the fact that it just waits for a million (milli)seconds for each item in the list: O(''n'') looks faster than O(''n'' log ''n''), but what's actually going on is that 1,000,000''n'' is way slower than mergesort's O(''n'' log ''n'').
:Curiously, this is actually a thing that [[wikipedia:Galactic algorithm|does happen in computer science]], although not as blatantly as this: there are some problems for which there exists an algorithm with a "better" Big-O-notated time, but which for whatever technical reason run worse in practice on real computers than apparently-slower algorithms.
(And again, please remember that I've on purpose left out irrelevant technical details! I know about radix sort etc., and I know the difference between O, Θ and Ω, and I know about space complexity also; I do actually have a master's degree in this stuff and know what I'm talking about.) [[Special:Contributions/172.69.136.141|172.69.136.141]] 16:09, 23 December 2024 (UTC)
:Actually I already thought of an improvement to this explanation (if it were to be used as the main explanation): it's unnecessary to bring up Big-O notation in the first place, until explaining the title text. The comic itself just talks about linear time, and mergesort (and sorting in general) could just be explained as requiring "more than linear time" because of the repeated comparisons I already mentioned. (O(''n'' log ''n'') is "quasilinear" or "log-linear" time but introducing that term can – and in my opinion should – be avoided). The title text explanation requires explaining that "O(n) means linear", and a bit about how Big-O notation is "rounding" away the complicated parts of the formula. [[Special:Contributions/172.69.136.165|172.69.136.165]] 16:42, 23 December 2024 (UTC)

Why is the prose so terrible on this site? Who writes "As one can image in most contexts one would wish for...." and thinks other people can understand it? Please run your text through ChatGPT, it's free now. [[Special:Contributions/172.71.147.54|172.71.147.54]] 17:31, 23 December 2024 (UTC)

Regarding {{diff|360113|this edit}}, I have my reservations. While Log2 ''may'' be 'logical' in a system using binary, there's no reason why the algorithm cannot be implemented upon a trinary-based "machine code" system, or one in quad (and I actually have created a four-instruction 'ultra-RISC' microcode kernel, of sorts, that used base-4 principles, not base-2), or decimal/BCD, and then byte-size is commonly 8-bit with 16-bit, 32-bit and 64-bit extensions to the basic unit and ''could'' translate to an equivalent higher-base if you are bothered about ''n'' vs. log''x'' ''n'' efficiency at lower ''n''s and higher ''x''s. Could even be natural-log (for reasons entirely unrelated to the hardware/firmware/software it is implemented on, just what it needs to do). Most of the time, we don't care if it's O(log10 ''n'') or O(ln ''n'') or whatever, because the difference is an appropriate constant multiple. That's something generally not retained... we may have O(''m'' log ''n''), for independent variable ''m'', but something like O(2 log ''n'') is treated as O(log ''n'') equivalent, like O(2) is just O(1) in the final analysis, and why the O(1e8*n) reality sneaks through here as O(n). So, ''by actual implementation'', you can't actually say that O(''n'' log ''n'') will be gte O(''n'') always. With 1<''n''<log_base, it won't be. ...Whether or not we're free to consider either generality, though, I definitely won't ask you how algorithms actually stack up next to each other where run under ''n''=0 conditions! But at least O(''n''-1) isn't a common thing... ;) [[Special:Contributions/172.69.194.19|172.69.194.19]] 18:01, 23 December 2024 (UTC)

Talk:3019: Advent Calendar Advent Calendar

2024-12-03T08:49:02Z

172.69.194.19: Question on the title

Would this basically be triangle numbers? So on Christmas Eve you would open 300 windows?[[User:Tommyds|Tommyds]] ([[User talk:Tommyds|talk]]) 16:01, 2 December 2024 (UTC)
:Yes and no. It's not 12 days of Christmas (as mentioned in the title text), so only the overall number of gifts are a triangle number; you open 30 windows on Christmas Day. The 12 days ref is key as the song generates more gifts if taken literally even in 12 days -- 78 on the last day, 66 on the previous day, etc, for a total of 364. [[User:Mneme|Mneme]] ([[User talk:Mneme|talk]]) 16:35, 2 December 2024 (UTC)

Notice that this year The Advent calendars are correct. Normally, Advent calendars start at the 1st of December even if the Advent starts at a different day. But this year the Advent also starts at the 1st of December. [[Special:Contributions/162.158.172.40|162.158.172.40]] 16:55, 2 December 2024 (UTC)

Donald Knuth wrote a paper for April 1984 Communications of the ACM that included an analysis of the complexity of 12 Days of Christmas. It's in the CACM archive https://dl.acm.org/doi/pdf/10.1145/358027.358042. {{unsigned ip|172.70.211.144|16:58, 2 December 2024 (UTC)}}

The explanation currently says "each day, he gets another advent calendar, which each contains 24-25 different items". I don't think that's correct; look at the picture: each day's calendar has one fewer item than the previous one. For example, the 24th only has 2 boxes and the 25th only has one. --[[User:Itub|Itub]] ([[User talk:Itub|talk]]) 17:25, 2 December 2024 (UTC)

Perhaps each smaller advent calendar might also contain a smaller advent calendar and so on ...? [[Special:Contributions/172.70.90.199|172.70.90.199]] 17:51, 2 December 2024 (UTC)
:Since the 1st has a calendar with a 1st, that would mean an infinite number of calendars just on the first day, so probably not. [[Special:Contributions/172.71.154.225|172.71.154.225]] 18:03, 2 December 2024 (UTC)
::It could work out if you don't open the first window of a new advent calendar on the day that it is revealed. So on day 1, you open the first window revealing an advent calendar that starts on day 2. Then on day 2 you open the second window, revealing a second advent calendar and the first window of the day 1 advent calendar, revealing a third advent calendar. ... and so on. If my mental math on that is right, it's doubling every day, so 2^24 =~ 16M calendars in total? (I could be off by a day) [[Special:Contributions/172.71.147.69|172.71.147.69]] 19:38, 2 December 2024 (UTC)

Can we just take a moment to appreciate whoever named the bot for this page? They wrote as follows: Created by 4 ENVELOPE BACKS 3 NERDS A-EDITING, 2 TURTLE BOTS, AND A FUNNY NEW XKCD. [[User:Willintendo|Willintendo]] ([[User talk:Willintendo|talk]]) 23:26, 2 December 2024 (UTC)
:That note is hand-edited on the first couple of edits. Not sure why that rule exists, though. [[User:Fabian42|Fabian42]] ([[User talk:Fabian42|talk]]) 00:50, 3 December 2024 (UTC)

The title text says 'may' twice, "per day may may [sic] seem absurd" --[[Special:Contributions/198.41.236.163|198.41.236.163]] 00:01, 3 December 2024 (UTC)

The German YouTube channel "Malternativ" has actually done this a couple years: Opening one advent calendar every day. He went more and more insane as December went on… [[User:Fabian42|Fabian42]] ([[User talk:Fabian42|talk]]) 00:50, 3 December 2024 (UTC)

Noting that the calendar is entirely correct for the day of publication. Too much to hope for that it is ''kept'' correct for each further day of Advent until (or, rather, 'until and including', as noted at least once above) Christmas Day? Maybe worth checking to see if (at an appropriate time, Randall-time, later today on the 3rd) it hasn't been updated. Or some special sub-page appeared with a revised (Time-like) update. Just in case. And, if Randall doesn't, I'm sure it's not beyond our own wit to make adjustments/animate as a fan-copy. [[Special:Contributions/172.70.91.214|172.70.91.214]] 01:57, 3 December 2024 (UTC)

[https://knowyourmeme.com/memes/xzibit-yo-dawg Yo Dawg], I herd you like advent calendars, so I put an advent calendar in your advent calendar so you can count down while you count down. [[User:Solomon|Solomon]] ([[User talk:Solomon|talk]]) 03:31, 3 December 2024 (UTC)

Wonder how many chocolates you would get if you did this with the life expectancy advent calendar. [[User:N-eh|N-eh]] ([[User talk:N-eh|talk]]) 04:40, 3 December 2024 (UTC)
:At some point, most people would reach the point at which that many chocolates would be a lethal (or at least LD50) quantity, so would be a self-shortening process. For those who reach the end of their LEAC ''without'' it actually being the cause of death, there should be a compensatory (or 'condolances') supply hidden on the back, for entirely guilt-free eating. [[Special:Contributions/172.70.162.200|172.70.162.200]] 06:01, 3 December 2024 (UTC)

Nobody tell Stuart and Dan about this one... [[Special:Contributions/172.71.183.11|172.71.183.11]] 06:56, 3 December 2024 (UTC)

I still don't understand it. Does he not open the first and second door of the second calendar on the second day? If not, does he open the first or the second door of the second calendar. Do the other items stay in the calendar? [[Special:Contributions/162.158.245.162|162.158.245.162]] 07:36, 3 December 2024 (UTC)
:Each next calendar has one fewer doors. So the second calendar starts with door number 2. On 1 December he opens the number 1 door revealing the first subcalendar, where he opens the number 1 door. On 2 December he opens the number 2 door of the first subcalendar and then the second door of the big calendar, revealing the second subcalendar, where he opens the first door, which is the number 2 door, since it has no number 1 door. [[User:Mtcv|Mtcv]] ([[User talk:Mtcv|talk]]) 08:12, 3 December 2024 (UTC)

Is the title correct, from a formal language point of view? I would expected it to be Advent Advent Calendar. OTOH I'm not American and not overtly familiar with this tradition.