explain xkcd - User contributions [en]

Talk:2671: Rotation

2022-09-15T07:40:43Z

162.158.222.211: Multiple devices & lossy compression

For extra credit: Waht is the resolution of the phone screen? [[Special:Contributions/172.71.94.135|172.71.94.135]] 18:59, 12 September 2022 (UTC)

:IMHO 400px. Note SMALLER. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 19:53, 12 September 2022 (UTC)

:From the image you can assume an 9/20 aspect ratio. Assuming each rotation reduces the image dimensions by that fraction after 9 rotations the dimensions would be reduced 1322 times so the resolution would be something between 1322x595 pixels (anything less than that would made it require 8 rotations or less) to 2935x1321 pixels (anything beyond that would require 10 rotations or more). 1600x720 or 2400x1080 maybe? Applying the same formula for the phone width and assuming atoms are typically around 100 picometers across then the phone width is close to 4.67 cm, too small, but maybe that's because rounding. In the other hand that formula does not work with Planck length at all: using it the phone width would be 1.69 meters. If you assume a width of 7 cm and 97 rotations you get pretty close to Planck length, but the comic says 101, not 97. Something is wrong with my calculations, I don't know what. [[Special:Contributions/162.158.63.160|162.158.63.160]] 21:03, 12 September 2022 (UTC)

::I took almost the reverse approach. Estimate phone height is 0.2 metres, Planck length is 1.6e-35 metres, ratio is 1.25e34, then take the 101th root. That would give about 2.176 as the reduction factor, which is also the screen aspect ratio. Then ask, "how far off might this be?" I assumed the 101th reduction is just barely smaller than the Planck length, it could be almost another reduction and still work. In other words, the aspect ratio is constrained to be between the 101th root and the 102nd root of the screen height in Planck units. With a 20 cm high screen, that puts the aspect ratio between 2.159 and 2.176 -- so the 9:20 aspect ratio (2.222) is completely ruled out. However <s>all the</s> [https://mediag.com/blog/popular-screen-resolutions-designing-for-all/ latest iPhone sizes] work just fine: 1792/828=2.164, <s>2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165</s>. I'll just guess that Randall has one of those. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 06:41, 13 September 2022 (UTC)
::Adding: I forgot to apply your method to constrain the width in pixels. 1125 and 1242 is ruled out because they are bigger than 2.159^9. In fact all the phone dimensions in that list I linked are ruled out except one: '''iPhone XR, 828x1792 pixels'''. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 07:01, 13 September 2022 (UTC)

: This question assumes it is the same phone screen being used for every screenshot. That seems to be unlikely to me. Wouldn't the reason for taking a screenshot be to share it with others? Also, my Samsung phone saves screenshots as JPEG images, which are lossy. Does the iPhone save screenshots lossless? I would love to see the image degradation caused by so many repeated lossy saves! [[Special:Contributions/162.158.222.211|162.158.222.211]] 07:40, 15 September 2022 (UTC)

This seems like it could actually be really cool. Can anyone do this and put the picture here as an example? Also, if possible, include an AI upscale of the one pixel. [[Special:Contributions/172.69.90.83|172.69.90.83]] 19:07, 12 September 2022 (UTC)

There's a '''minor''' counting error: instead of pointing to the 9th rotation, the 'nine rotations' statement points to the 8th as the first phone has no rotations.[[Special:Contributions/172.70.90.77|172.70.90.77]] 19:10, 12 September 2022 (UTC)
:That error is also on the 25 rotation, in both cases he counts the first screen with, and thus is one rotation behind. Also there are only 99 screens and thus 98 rotations so he missed the last 3 rotations, and screens, as there should have been 102 screens. --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 09:06, 13 September 2022 (UTC)

Anyone getting a 404? Seems like the comic has disappeared. EDIT: ...aaaand it's back. [[Special:Contributions/172.70.100.54|172.70.100.54]] 19:34, 12 September 2022 (UTC)

Just putting https://www.codeguru.com/multimedia/rotate-a-bitmap-image/ here. [[Special:Contributions/172.69.134.131|172.69.134.131]] 20:12, 12 September 2022 (UTC)
: Microsoft C#, and not the original HAKMEM or Smalltalk 80? Please! You might as well be using C++: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-plgblt [[Special:Contributions/162.158.166.173|162.158.166.173]] 20:21, 12 September 2022 (UTC)
:: I see your trivial software squabble, and raise one peer reviewed open access article citation: https://link.springer.com/article/10.1007/s10648-010-9144-5 [[Special:Contributions/172.69.22.5|172.69.22.5]] 22:03, 12 September 2022 (UTC)
:::I'll see your humorously ambiguous reference, and raise you a slightly more on-topic chapter encompassing both: https://journalspress.com/LJRHSS_Volume17/208_The-Geometric-Progression.pdf [[Special:Contributions/162.158.166.125|162.158.166.125]] 22:10, 12 September 2022 (UTC)

Tiktok [[Special:Contributions/108.162.246.68|108.162.246.68]] 20:40, 12 September 2022 (UTC)

Where would the rotated photograph bar be on [[1909: Digital Resource Lifespan]]? [[Special:Contributions/172.70.211.50|172.70.211.50]] 22:14, 12 September 2022 (UTC)

Doing this with an jpeg does the same. When rotating an image and saving it the lossy compression will lose more pixels. This makes it more blurry each step. [[Special:Contributions/162.158.203.38|162.158.203.38]] 22:41, 12 September 2022 (UTC)

:Who said it had to be something like JPEG? Since the information added at each step is known and finite, you could easily devise an iterated rotated image format that perfectly preserves the detail at every level down to the Planck length, and provide the possibility of zooming in on the screen all the way down. Of course you couldn't *display* all the detail at every level at the same time, but you could certainly store it in a hypothetical IRI (tm) format. [[Special:Contributions/172.70.162.147|172.70.162.147]] 16:00, 13 September 2022 (UTC)

I'm skeptical of "details at a sub-pixel level but that would have been significant if recorded at a greater resolution ''cannot'' emerge" -- this is subjective at a couple levels, and not as entirely impossible as opposed to just vaguely unlikely as the italics imply. [[Special:Contributions/172.69.22.119|172.69.22.119]] 00:43, 13 September 2022 (UTC)
:Well, after finding the context... Using pixel-multiplying techniques on low-res pixels (either direct, a poor imaging source, or upon previously downsampled high-res one) will either never recreate features 'lost' in the lower resolution or will ''always'' do (or at least always in a given non-zero proportion of pixel-patternations indistinguishable from the more justified one) even in situations where there was no justification for such an algorithmically-invoked artefact.
:But I suppose the most perfect fractal-compression, if it matches 'reality' well enough, could be rediscovered by the statistical pixel analysis which then extrapolates (or interpolates) all kinds of image details that were never even present even in the rawest of raw digital images but were always there to be discovered in the real-world had only the correct zoom level and framing been used. And, if you've got something that can do that, I'll up the stakes with the Photo Enhancer/Inferrer thing that Rick Deckard used... It can even interpolate ''around corners''! [[Special:Contributions/172.71.178.65|172.71.178.65]] 02:33, 13 September 2022 (UTC)
The title text reminds me of the CSI TV show where a reflection of a faint image would be zoomed in on and the tiny text on the original could be read clearly.[[Special:Contributions/172.70.100.136|172.70.100.136]] 11:13, 13 September 2022 (UTC)
:After casually getting links to potentially follow up on 172.71.178.65, above, one of the interesting ones is: https://www.google.com/amp/s/scifiinterfaces.com/2020/04/29/deckards-photo-inspector/amp/ [[Special:Contributions/172.70.162.77|172.70.162.77]] 13:17, 13 September 2022 (UTC)

I thought Randall was poking fun at all the dumb movies and TV programs that have the magic ability to “enhance” images and recover sub-pixel detail. It’s such an egregious plot point that you can recognize computer scientists by their groans in movie theaters. There’s even a TV Trope about it: https://tvtropes.org/pmwiki/pmwiki.php/Main/EnhanceButton — Also, the infinitely regressing image is called a ''Droste Image''. --[[User:Dúthomhas|Dúthomhas]] ([[User talk:Dúthomhas|talk]]) 08:08, 14 September 2022 (UTC)

This comic reminds me a lot of [[1683: Digital Data]], which is also about degradation of images through re-posting screenshots. [[Special:Contributions/162.158.222.211|162.158.222.211]] 09:27, 14 September 2022 (UTC)
: Absolutely no question, I spent half an hour looking for that one. Added; thanks! [[Special:Contributions/172.70.211.162|172.70.211.162]] 21:03, 14 September 2022 (UTC)

Talk:2671: Rotation

2022-09-14T09:29:53Z

162.158.222.211:

For extra credit: Waht is the resolution of the phone screen? [[Special:Contributions/172.71.94.135|172.71.94.135]] 18:59, 12 September 2022 (UTC)

:IMHO 400px. Note SMALLER. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 19:53, 12 September 2022 (UTC)

:From the image you can assume an 9/20 aspect ratio. Assuming each rotation reduces the image dimensions by that fraction after 9 rotations the dimensions would be reduced 1322 times so the resolution would be something between 1322x595 pixels (anything less than that would made it require 8 rotations or less) to 2935x1321 pixels (anything beyond that would require 10 rotations or more). 1600x720 or 2400x1080 maybe? Applying the same formula for the phone width and assuming atoms are typically around 100 picometers across then the phone width is close to 4.67 cm, too small, but maybe that's because rounding. In the other hand that formula does not work with Planck length at all: using it the phone width would be 1.69 meters. If you assume a width of 7 cm and 97 rotations you get pretty close to Planck length, but the comic says 101, not 97. Something is wrong with my calculations, I don't know what. [[Special:Contributions/162.158.63.160|162.158.63.160]] 21:03, 12 September 2022 (UTC)

::I took almost the reverse approach. Estimate phone height is 0.2 metres, Planck length is 1.6e-35 metres, ratio is 1.25e34, then take the 101th root. That would give about 2.176 as the reduction factor, which is also the screen aspect ratio. Then ask, "how far off might this be?" I assumed the 101th reduction is just barely smaller than the Planck length, it could be almost another reduction and still work. In other words, the aspect ratio is constrained to be between the 101th root and the 102nd root of the screen height in Planck units. With a 20 cm high screen, that puts the aspect ratio between 2.159 and 2.176 -- so the 9:20 aspect ratio (2.222) is completely ruled out. However <s>all the</s> [https://mediag.com/blog/popular-screen-resolutions-designing-for-all/ latest iPhone sizes] work just fine: 1792/828=2.164, <s>2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165</s>. I'll just guess that Randall has one of those. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 06:41, 13 September 2022 (UTC)
::Adding: I forgot to apply your method to constrain the width in pixels. 1125 and 1242 is ruled out because they are bigger than 2.159^9. In fact all the phone dimensions in that list I linked are ruled out except one: '''iPhone XR, 828x1792 pixels'''. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 07:01, 13 September 2022 (UTC)

This seems like it could actually be really cool. Can anyone do this and put the picture here as an example? Also, if possible, include an AI upscale of the one pixel. [[Special:Contributions/172.69.90.83|172.69.90.83]] 19:07, 12 September 2022 (UTC)

There's a '''minor''' counting error: instead of pointing to the 9th rotation, the 'nine rotations' statement points to the 8th as the first phone has no rotations.[[Special:Contributions/172.70.90.77|172.70.90.77]] 19:10, 12 September 2022 (UTC)
:That error is also on the 25 rotation, in both cases he counts the first screen with, and thus is one rotation behind. Also there are only 99 screens and thus 98 rotations so he missed the last 3 rotations, and screens, as there should have been 102 screens. --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 09:06, 13 September 2022 (UTC)

Anyone getting a 404? Seems like the comic has disappeared. EDIT: ...aaaand it's back. [[Special:Contributions/172.70.100.54|172.70.100.54]] 19:34, 12 September 2022 (UTC)

Just putting https://www.codeguru.com/multimedia/rotate-a-bitmap-image/ here. [[Special:Contributions/172.69.134.131|172.69.134.131]] 20:12, 12 September 2022 (UTC)
: Microsoft C#, and not the original HAKMEM or Smalltalk 80? Please! You might as well be using C++: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-plgblt [[Special:Contributions/162.158.166.173|162.158.166.173]] 20:21, 12 September 2022 (UTC)
:: I see your trivial software squabble, and raise one peer reviewed open access article citation: https://link.springer.com/article/10.1007/s10648-010-9144-5 [[Special:Contributions/172.69.22.5|172.69.22.5]] 22:03, 12 September 2022 (UTC)
:::I'll see your humorously ambiguous reference, and raise you a slightly more on-topic chapter encompassing both: https://journalspress.com/LJRHSS_Volume17/208_The-Geometric-Progression.pdf [[Special:Contributions/162.158.166.125|162.158.166.125]] 22:10, 12 September 2022 (UTC)

Tiktok [[Special:Contributions/108.162.246.68|108.162.246.68]] 20:40, 12 September 2022 (UTC)

Where would the rotated photograph bar be on [[1909: Digital Resource Lifespan]]? [[Special:Contributions/172.70.211.50|172.70.211.50]] 22:14, 12 September 2022 (UTC)

Doing this with an jpeg does the same. When rotating an image and saving it the lossy compression will lose more pixels. This makes it more blurry each step. [[Special:Contributions/162.158.203.38|162.158.203.38]] 22:41, 12 September 2022 (UTC)

:Who said it had to be something like JPEG? Since the information added at each step is known and finite, you could easily devise an iterated rotated image format that perfectly preserves the detail at every level down to the Planck length, and provide the possibility of zooming in on the screen all the way down. Of course you couldn't *display* all the detail at every level at the same time, but you could certainly store it in a hypothetical IRI (tm) format. [[Special:Contributions/172.70.162.147|172.70.162.147]] 16:00, 13 September 2022 (UTC)

I'm skeptical of "details at a sub-pixel level but that would have been significant if recorded at a greater resolution ''cannot'' emerge" -- this is subjective at a couple levels, and not as entirely impossible as opposed to just vaguely unlikely as the italics imply. [[Special:Contributions/172.69.22.119|172.69.22.119]] 00:43, 13 September 2022 (UTC)
:Well, after finding the context... Using pixel-multiplying techniques on low-res pixels (either direct, a poor imaging source, or upon previously downsampled high-res one) will either never recreate features 'lost' in the lower resolution or will ''always'' do (or at least always in a given non-zero proportion of pixel-patternations indistinguishable from the more justified one) even in situations where there was no justification for such an algorithmically-invoked artefact.
:But I suppose the most perfect fractal-compression, if it matches 'reality' well enough, could be rediscovered by the statistical pixel analysis which then extrapolates (or interpolates) all kinds of image details that were never even present even in the rawest of raw digital images but were always there to be discovered in the real-world had only the correct zoom level and framing been used. And, if you've got something that can do that, I'll up the stakes with the Photo Enhancer/Inferrer thing that Rick Deckard used... It can even interpolate ''around corners''! [[Special:Contributions/172.71.178.65|172.71.178.65]] 02:33, 13 September 2022 (UTC)
The title text reminds me of the CSI TV show where a reflection of a faint image would be zoomed in on and the tiny text on the original could be read clearly.[[Special:Contributions/172.70.100.136|172.70.100.136]] 11:13, 13 September 2022 (UTC)
:After casually getting links to potentially follow up on 172.71.178.65, above, one of the interesting ones is: https://www.google.com/amp/s/scifiinterfaces.com/2020/04/29/deckards-photo-inspector/amp/ [[Special:Contributions/172.70.162.77|172.70.162.77]] 13:17, 13 September 2022 (UTC)

I thought Randall was poking fun at all the dumb movies and TV programs that have the magic ability to “enhance” images and recover sub-pixel detail. It’s such an egregious plot point that you can recognize computer scientists by their groans in movie theaters. There’s even a TV Trope about it: https://tvtropes.org/pmwiki/pmwiki.php/Main/EnhanceButton — Also, the infinitely regressing image is called a ''Droste Image''. --[[User:Dúthomhas|Dúthomhas]] ([[User talk:Dúthomhas|talk]]) 08:08, 14 September 2022 (UTC)

This comic reminds me a lot of [[1683: Digital Data]], which is also about degradation of images through re-posting screenshots. [[Special:Contributions/162.158.222.211|162.158.222.211]] 09:27, 14 September 2022 (UTC)

Talk:2671: Rotation

2022-09-14T09:27:22Z

162.158.222.211: 1683: Digital Data

For extra credit: Waht is the resolution of the phone screen? [[Special:Contributions/172.71.94.135|172.71.94.135]] 18:59, 12 September 2022 (UTC)

:IMHO 400px. Note SMALLER. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 19:53, 12 September 2022 (UTC)

:From the image you can assume an 9/20 aspect ratio. Assuming each rotation reduces the image dimensions by that fraction after 9 rotations the dimensions would be reduced 1322 times so the resolution would be something between 1322x595 pixels (anything less than that would made it require 8 rotations or less) to 2935x1321 pixels (anything beyond that would require 10 rotations or more). 1600x720 or 2400x1080 maybe? Applying the same formula for the phone width and assuming atoms are typically around 100 picometers across then the phone width is close to 4.67 cm, too small, but maybe that's because rounding. In the other hand that formula does not work with Planck length at all: using it the phone width would be 1.69 meters. If you assume a width of 7 cm and 97 rotations you get pretty close to Planck length, but the comic says 101, not 97. Something is wrong with my calculations, I don't know what. [[Special:Contributions/162.158.63.160|162.158.63.160]] 21:03, 12 September 2022 (UTC)

::I took almost the reverse approach. Estimate phone height is 0.2 metres, Planck length is 1.6e-35 metres, ratio is 1.25e34, then take the 101th root. That would give about 2.176 as the reduction factor, which is also the screen aspect ratio. Then ask, "how far off might this be?" I assumed the 101th reduction is just barely smaller than the Planck length, it could be almost another reduction and still work. In other words, the aspect ratio is constrained to be between the 101th root and the 102nd root of the screen height in Planck units. With a 20 cm high screen, that puts the aspect ratio between 2.159 and 2.176 -- so the 9:20 aspect ratio (2.222) is completely ruled out. However <s>all the</s> [https://mediag.com/blog/popular-screen-resolutions-designing-for-all/ latest iPhone sizes] work just fine: 1792/828=2.164, <s>2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165</s>. I'll just guess that Randall has one of those. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 06:41, 13 September 2022 (UTC)
::Adding: I forgot to apply your method to constrain the width in pixels. 1125 and 1242 is ruled out because they are bigger than 2.159^9. In fact all the phone dimensions in that list I linked are ruled out except one: '''iPhone XR, 828x1792 pixels'''. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 07:01, 13 September 2022 (UTC)

This seems like it could actually be really cool. Can anyone do this and put the picture here as an example? Also, if possible, include an AI upscale of the one pixel. [[Special:Contributions/172.69.90.83|172.69.90.83]] 19:07, 12 September 2022 (UTC)

There's a '''minor''' counting error: instead of pointing to the 9th rotation, the 'nine rotations' statement points to the 8th as the first phone has no rotations.[[Special:Contributions/172.70.90.77|172.70.90.77]] 19:10, 12 September 2022 (UTC)
:That error is also on the 25 rotation, in both cases he counts the first screen with, and thus is one rotation behind. Also there are only 99 screens and thus 98 rotations so he missed the last 3 rotations, and screens, as there should have been 102 screens. --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 09:06, 13 September 2022 (UTC)

Anyone getting a 404? Seems like the comic has disappeared. EDIT: ...aaaand it's back. [[Special:Contributions/172.70.100.54|172.70.100.54]] 19:34, 12 September 2022 (UTC)

Just putting https://www.codeguru.com/multimedia/rotate-a-bitmap-image/ here. [[Special:Contributions/172.69.134.131|172.69.134.131]] 20:12, 12 September 2022 (UTC)
: Microsoft C#, and not the original HAKMEM or Smalltalk 80? Please! You might as well be using C++: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-plgblt [[Special:Contributions/162.158.166.173|162.158.166.173]] 20:21, 12 September 2022 (UTC)
:: I see your trivial software squabble, and raise one peer reviewed open access article citation: https://link.springer.com/article/10.1007/s10648-010-9144-5 [[Special:Contributions/172.69.22.5|172.69.22.5]] 22:03, 12 September 2022 (UTC)
:::I'll see your humorously ambiguous reference, and raise you a slightly more on-topic chapter encompassing both: https://journalspress.com/LJRHSS_Volume17/208_The-Geometric-Progression.pdf [[Special:Contributions/162.158.166.125|162.158.166.125]] 22:10, 12 September 2022 (UTC)

Tiktok [[Special:Contributions/108.162.246.68|108.162.246.68]] 20:40, 12 September 2022 (UTC)

Where would the rotated photograph bar be on [[1909: Digital Resource Lifespan]]? [[Special:Contributions/172.70.211.50|172.70.211.50]] 22:14, 12 September 2022 (UTC)

Doing this with an jpeg does the same. When rotating an image and saving it the lossy compression will lose more pixels. This makes it more blurry each step. [[Special:Contributions/162.158.203.38|162.158.203.38]] 22:41, 12 September 2022 (UTC)

:Who said it had to be something like JPEG? Since the information added at each step is known and finite, you could easily devise an iterated rotated image format that perfectly preserves the detail at every level down to the Planck length, and provide the possibility of zooming in on the screen all the way down. Of course you couldn't *display* all the detail at every level at the same time, but you could certainly store it in a hypothetical IRI (tm) format. [[Special:Contributions/172.70.162.147|172.70.162.147]] 16:00, 13 September 2022 (UTC)

I'm skeptical of "details at a sub-pixel level but that would have been significant if recorded at a greater resolution ''cannot'' emerge" -- this is subjective at a couple levels, and not as entirely impossible as opposed to just vaguely unlikely as the italics imply. [[Special:Contributions/172.69.22.119|172.69.22.119]] 00:43, 13 September 2022 (UTC)
:Well, after finding the context... Using pixel-multiplying techniques on low-res pixels (either direct, a poor imaging source, or upon previously downsampled high-res one) will either never recreate features 'lost' in the lower resolution or will ''always'' do (or at least always in a given non-zero proportion of pixel-patternations indistinguishable from the more justified one) even in situations where there was no justification for such an algorithmically-invoked artefact.
:But I suppose the most perfect fractal-compression, if it matches 'reality' well enough, could be rediscovered by the statistical pixel analysis which then extrapolates (or interpolates) all kinds of image details that were never even present even in the rawest of raw digital images but were always there to be discovered in the real-world had only the correct zoom level and framing been used. And, if you've got something that can do that, I'll up the stakes with the Photo Enhancer/Inferrer thing that Rick Deckard used... It can even interpolate ''around corners''! [[Special:Contributions/172.71.178.65|172.71.178.65]] 02:33, 13 September 2022 (UTC)
The title text reminds me of the CSI TV show where a reflection of a faint image would be zoomed in on and the tiny text on the original could be read clearly.[[Special:Contributions/172.70.100.136|172.70.100.136]] 11:13, 13 September 2022 (UTC)
:After casually getting links to potentially follow up on 172.71.178.65, above, one of the interesting ones is: https://www.google.com/amp/s/scifiinterfaces.com/2020/04/29/deckards-photo-inspector/amp/ [[Special:Contributions/172.70.162.77|172.70.162.77]] 13:17, 13 September 2022 (UTC)

I thought Randall was poking fun at all the dumb movies and TV programs that have the magic ability to “enhance” images and recover sub-pixel detail. It’s such an egregious plot point that you can recognize computer scientists by their groans in movie theaters. There’s even a TV Trope about it: https://tvtropes.org/pmwiki/pmwiki.php/Main/EnhanceButton — Also, the infinitely regressing image is called a ''Droste Image''. --[[User:Dúthomhas|Dúthomhas]] ([[User talk:Dúthomhas|talk]]) 08:08, 14 September 2022 (UTC)

This comic reminds me a lot of [[1683: Digital Data]], which is also about degradation of images through digital processes. [[Special:Contributions/162.158.222.211|162.158.222.211]] 09:27, 14 September 2022 (UTC)

2658: Coffee Cup Holes

2022-08-13T21:37:11Z

162.158.222.211: /* Explanation */

{{comic
| number = 2658
| date = August 12, 2022
| title = Coffee Cup Holes
| image = coffee_cup_holes.png
| titletext = Theoretical physicist: At the Planck length, uncountably many.
}}

==Explanation==
{{incomplete|Created by a CAFFEINE MOLECULE WITH A HOLE DRILLED IN ITS SIDE. Do NOT delete this tag too soon.}}

This comic depicts people in different fields of study answering the question, "How many holes are there in a coffee cup?" This question can have multiple interpretations, in particular concerning the definition of a hole.

[[File:Mug and Torus morph.gif|thumb|200px|The coffee mug and donut shown in this animation both have topological genus one.]]

[[Ponytail]], a {{w|topology|topologist}}, states the coffee cup belongs in the {{w|Genus (mathematics)#Topology|genus}} of one hole. A common joke is that topologists can't tell the difference between a coffee cup and a donut since they're homeomorphic to each other — they have the same genus. From the topologist's point of view, the coffee cup definitely has one hole. See [[2625: Field Topology]] for more information about topology.

[[Hairy]], a normal person, is not sure (the acronym "IDK" stands for "I don't know") and asks for clarification about whether the opening at the top counts as a hole. This shows flaws in the question, which suffers from the mathematically imprecise, ambiguous common usage of the word hole. Topologists would refer to the opening as a concavity, not a hole, and while they consider such geometrical properties generally outside their field, most practical applications of topology do involve geometric components.

[[File:Double torus illustration.png|thumb|left|200px|A genus two surface]]

[[Hairbun]], a philosopher, answers the question with an elucidating counter-question, considering a hypothetical scenario. Drilling a new hole should increase the number of holes by one, and after the hole has been drilled, a common teacup or mug has two holes according to topologists. Since drilling a hole increases the number of holes by one,{{cn}} the philosopher's question requires the original questioner to reveal the answer to their own question. (Also, she asks how many holes there are ''now'' rather than ''after we do that'', an ambiguity.)

[[Image:Point cloud torus.gif|thumb|200px|A point cloud of a genus one surface]]

[[Cueball]], a chemist, looks at the coffee in the cup on a molecular level, which means it has very many holes: 1,000,000,000,000,000,000,000 (10<sup>21</sup> or 1 sextillion) “in the [https://chemapps.stolaf.edu/jmol/jmol.php?model=CN1C%3DNC2%3DC1C%28%3DO%29N%28C%28%3DO%29N2C%29C caffeine] alone.” An implication is that there are more holes in the cup itself, with which normal people and topologists would probably disagree. Also, the coffee itself could have other holes, depending on the type of coffee. For example, espresso contains significant amounts of niacin and riboflavin, each of which has at least one hole in its chemical structure. However, this ignores the fact that bonds are not discrete sticks as portrayed in many molecular models. The "holes" in the middle of a caffeine molecule are not completely empty but instead merely have lower electron densities/probabilities. So the point-cloud duality of {{w|Bonding molecular orbital|electron orbitals and bonds}} might not satisfy a topologist's, normal person's, or philosopher's criteria for a connected substrate in which holes may be formed.

If one molecule of caffeine has two holes then Cueball is talking about 500 quintillion molecules. Molar mass of caffeine is [https://en.wikipedia.org/wiki/Caffeine 194.194 g/mol], so this amount of caffeine weights 161 mg. This is a normal amount of caffeine in one cup (although this number varies a lot).

[[Image:World lines and world sheet.svg|left|thumb|200px|{{w|String theory}} describes the {{w|worldline}}s of point-like particles as {{w|worldsheet}}s of "closed strings," forming topological holes.]]

In the title text, a theoretical physicist looks even deeper, at the subatomic scale of {{w|Planck units}}. Since fundamental particle interaction is governed by fundamental forces and collision (per the {{w|Pauli exclusion principle}}) instead of tensile or ductile solid connectedness, the theoretical physicist posits that any definition providing for a single hole would also describe a number of holes akin to the factorial of the number of particles in the universe, or at least within the cup's {{w|light cone}}, which is a number impractical to accurately count, but not uncountable in a mathematical sense.

Part of the joke could be that all five methods of inquiry don't discern between a {{w|cup}} (as described) and a {{w|mug}} (as depicted), the cliché being that topologists are unusual because they don't. Or, as many people use the terms interchangeably, [[Randall]] may too.

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

:[The first panel has text only. The "Q:" below is a large letter Q representing a question, not a character name.]
:Q:
:How many holes are there in a coffee cup?

:[Each of the next four panels has a caption at the top to indicate the kind of person answering the question.]
:Caption: Topologist
:[Ponytail stands holding a coffee mug.]
:Ponytail: One.

:Caption: Normal person
:[Hairy stands to the right of Ponytail, holding a coffee mug at an angle to look into it.]
:Hairy: IDK, does the opening count as a hole?

:Caption: Philosopher
:[Hairbun is shown in closeup, with two drawings of coffee mugs to her left.]
:Hairbun: To answer that question, consider another: If we drill a hole in the side, how many holes are there now?

:Caption: Chemist
:[Cueball stands with a drawing of a caffeine molecule above him and to the right.]
:Cueball: 10<sup>21</sup> in the caffeine alone

{{comic discussion}}
[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring Hairy]]
[[Category:Comics featuring Hairbun]]
[[Category:Comics featuring Cueball]]
[[Category:Math]]
[[Category:Food]]
[[Category:Science]]
[[Category:Chemistry]]
[[Category:Philosophy]]