Talk:1685: Patch - Revision history

172.70.91.153: /* he predicted dall-e ai */ new section

2023-12-04T14:34:23Z

‎he predicted dall-e ai: new section

NiceGuy1 at 10:06, 9 June 2017

2017-06-09T10:06:51Z

These Are Not The Comments You Are Looking For: Commented on Photoshop pricing

2016-05-29T22:44:29Z

Commented on Photoshop pricing

Dansiman at 15:48, 28 May 2016

2016-05-28T15:48:32Z

Davidy22 at 03:59, 27 May 2016

2016-05-27T03:59:24Z

141.101.98.43 at 03:37, 27 May 2016

2016-05-27T03:37:57Z

173.245.52.69: Add reply

2016-05-27T00:04:47Z

Add reply

141.101.80.121: /* Resemblance to Xerox number mangling issue */

2016-05-26T22:26:52Z

‎Resemblance to Xerox number mangling issue

173.245.52.69: Add comment

2016-05-26T22:20:13Z

Add comment

162.158.252.185: /* Resemblance to Xerox number mangling issue */ new section

2016-05-26T21:25:42Z

‎Resemblance to Xerox number mangling issue: new section

← Older revision		Revision as of 14:34, 4 December 2023
Line 47:		Line 47:

	I think the party of the explanation that details OCR is more in depth than it really needs to be. Considering that the comic itself makes no reference to OCR, these details should be trimmed down considerably, or at least moved to a later point in the explanation after the more salient details. [[User:Dansiman\|Dansiman]] ([[User talk:Dansiman\|talk]]) 15:48, 28 May 2016 (UTC)		I think the party of the explanation that details OCR is more in depth than it really needs to be. Considering that the comic itself makes no reference to OCR, these details should be trimmed down considerably, or at least moved to a later point in the explanation after the more salient details. [[User:Dansiman\|Dansiman]] ([[User talk:Dansiman\|talk]]) 15:48, 28 May 2016 (UTC)
		+
		+	== he predicted dall-e ai ==
		+
		+	ain't no way--[[Special:Contributions/172.70.91.153\|172.70.91.153]] 14:34, 4 December 2023 (UTC)

@@ Line 1: / Line 1: @@
 <!--Please sign your posts with ~~~~-->
-Hey, I'm first! Guessing the Bot only JUST created this, it was mere minutes after midnight EST when I landed on this page. Unfortunately this is a comic I'm less capable of explaining. From the looks of it, his Photoshop Patch turned what looks like C code into gobbledegook by filling in several of the spaces (and I think even changing some of the characters, possible with characters which fill more of the space). - NiceGuy1 [[Special:Contributions/108.162.218.77|108.162.218.77]] 04:24, 25 May 2016 (UTC)
+Hey, I'm first! Guessing the Bot only JUST created this, it was mere minutes after midnight EST when I landed on this page. Unfortunately this is a comic I'm less capable of explaining. From the looks of it, his Photoshop Patch turned what looks like C code into gobbledegook by filling in several of the spaces (and I think even changing some of the characters, possible with characters which fill more of the space). - NiceGuy1 [[Special:Contributions/108.162.218.77|108.162.218.77]] 04:24, 25 May 2016 (UTC) I finally signed up! This comment is mine. [[User:NiceGuy1|NiceGuy1]] ([[User talk:NiceGuy1|talk]]) 10:06, 9 June 2017 (UTC)
 This appears to be Python code. Note the "def" keyword, how "for i in [garbled]:" is used rather than C's for syntax, and how there are no semicolons or braces. --[[User:Sherlock9|Sherlock9]] ([[User talk:Sherlock9|talk]]) 05:03, 25 May 2016 (UTC)

@@ Line 34: / Line 34: @@
 It might be worth explaining the [pivot] * (len(a) - (len(l) + len(r))) since that threw me when I first saw it. Since l has the elements of a < pivot, and r has the elements of a > pivot, len(a) - (len(l) + len(r)) will be the number of elements in a that = pivot (which must be in the range [1, len(a)]), and these are then 'spliced' into the result between the result of quicksorting l and r.
 [[User:Jstout|Jstout]] ([[User talk:Jstout|talk]]) 19:48, 26 May 2016 (UTC)
 ;Resemblance to Xerox number mangling issue

← Older revision		Revision as of 15:48, 28 May 2016
Line 43:		Line 43:
	:A couple of decades ago, the firm I was working for suddenly realised that one of its dot-matrix printers was causing problems. It was being used to print out specific validation information for archival, but the centre pin of the (vertical)print-head pin array was no longer striking. Out of 9 or perhaps 13 pins, it didn't represent much difference in the output ''normally'', but the difference between a 0 and a 8 was whether that pin's contribution was two separated pixels, the middle of the two long verticals in the zero*, or a short horizontal sequence of dots representing the contact between the two small circles in the eight. The way the hardly-noticed absent row caused the character to be read meant that both read as zero, with no difference. (Other characters had problems, but usually did not look like anything else. There were no hyphens/minus-signs, but they might have rendered as whitespace if there had been.) This was not an ideal situation, and a different printer was swapped in ASAP.		:A couple of decades ago, the firm I was working for suddenly realised that one of its dot-matrix printers was causing problems. It was being used to print out specific validation information for archival, but the centre pin of the (vertical)print-head pin array was no longer striking. Out of 9 or perhaps 13 pins, it didn't represent much difference in the output ''normally'', but the difference between a 0 and a 8 was whether that pin's contribution was two separated pixels, the middle of the two long verticals in the zero*, or a short horizontal sequence of dots representing the contact between the two small circles in the eight. The way the hardly-noticed absent row caused the character to be read meant that both read as zero, with no difference. (Other characters had problems, but usually did not look like anything else. There were no hyphens/minus-signs, but they might have rendered as whitespace if there had been.) This was not an ideal situation, and a different printer was swapped in ASAP.
	: * - This typeface's zero did not have a diagonal bar, of the type I even habitually ''handwrite'', but confusion with O-for-Oscar characters was already not an issue due to context... [[Special:Contributions/141.101.98.43\|141.101.98.43]] 03:37, 27 May 2016 (UTC)		: * - This typeface's zero did not have a diagonal bar, of the type I even habitually ''handwrite'', but confusion with O-for-Oscar characters was already not an issue due to context... [[Special:Contributions/141.101.98.43\|141.101.98.43]] 03:37, 27 May 2016 (UTC)
		+
		+	I think the party of the explanation that details OCR is more in depth than it really needs to be. Considering that the comic itself makes no reference to OCR, these details should be trimmed down considerably, or at least moved to a later point in the explanation after the more salient details. [[User:Dansiman\|Dansiman]] ([[User talk:Dansiman\|talk]]) 15:48, 28 May 2016 (UTC)

@@ Line 35: / Line 35: @@
 [[User:Jstout|Jstout]] ([[User talk:Jstout|talk]]) 19:48, 26 May 2016 (UTC)
-== Resemblance to Xerox number mangling issue ==
+;Resemblance to Xerox number mangling issue
-To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning
+To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning {{unsigned ip|162.158.252.185}}
 :Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69|173.245.52.69]] 22:20, 26 May 2016 (UTC)
 ::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121|141.101.80.121]] 22:26, 26 May 2016 (UTC)

← Older revision		Revision as of 03:37, 27 May 2016
Line 41:		Line 41:
	::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121\|141.101.80.121]] 22:26, 26 May 2016 (UTC)		::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121\|141.101.80.121]] 22:26, 26 May 2016 (UTC)
	:::Wow. that's intense.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 00:04, 27 May 2016 (UTC)		:::Wow. that's intense.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 00:04, 27 May 2016 (UTC)
		+	:A couple of decades ago, the firm I was working for suddenly realised that one of its dot-matrix printers was causing problems. It was being used to print out specific validation information for archival, but the centre pin of the (vertical)print-head pin array was no longer striking. Out of 9 or perhaps 13 pins, it didn't represent much difference in the output ''normally'', but the difference between a 0 and a 8 was whether that pin's contribution was two separated pixels, the middle of the two long verticals in the zero*, or a short horizontal sequence of dots representing the contact between the two small circles in the eight. The way the hardly-noticed absent row caused the character to be read meant that both read as zero, with no difference. (Other characters had problems, but usually did not look like anything else. There were no hyphens/minus-signs, but they might have rendered as whitespace if there had been.) This was not an ideal situation, and a different printer was swapped in ASAP.
		+	: * - This typeface's zero did not have a diagonal bar, of the type I even habitually ''handwrite'', but confusion with O-for-Oscar characters was already not an issue due to context... [[Special:Contributions/141.101.98.43\|141.101.98.43]] 03:37, 27 May 2016 (UTC)

← Older revision		Revision as of 00:04, 27 May 2016
Line 40:		Line 40:
	:Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 22:20, 26 May 2016 (UTC)		:Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 22:20, 26 May 2016 (UTC)
	::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121\|141.101.80.121]] 22:26, 26 May 2016 (UTC)		::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121\|141.101.80.121]] 22:26, 26 May 2016 (UTC)
		+	:::Wow. that's intense.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 00:04, 27 May 2016 (UTC)

← Older revision		Revision as of 22:26, 26 May 2016
Line 39:		Line 39:
	To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning		To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning
	:Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 22:20, 26 May 2016 (UTC)		:Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 22:20, 26 May 2016 (UTC)
		+	::So ''that's'' what it was! I wondered why all the copies I could find of ''Concrete Mathematics'' had random font changes all over (and half the formulas came out wrong). [[Special:Contributions/141.101.80.121\|141.101.80.121]] 22:26, 26 May 2016 (UTC)

← Older revision		Revision as of 22:20, 26 May 2016
Line 38:		Line 38:

	To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning		To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning
		+	:Now that you mention it... Although here it's a person intentionally doing harm to the image.[[Special:Contributions/173.245.52.69\|173.245.52.69]] 22:20, 26 May 2016 (UTC)

← Older revision		Revision as of 21:25, 26 May 2016
Line 34:		Line 34:
	It might be worth explaining the [pivot] * (len(a) - (len(l) + len(r))) since that threw me when I first saw it. Since l has the elements of a < pivot, and r has the elements of a > pivot, len(a) - (len(l) + len(r)) will be the number of elements in a that = pivot (which must be in the range [1, len(a)]), and these are then 'spliced' into the result between the result of quicksorting l and r.		It might be worth explaining the [pivot] * (len(a) - (len(l) + len(r))) since that threw me when I first saw it. Since l has the elements of a < pivot, and r has the elements of a > pivot, len(a) - (len(l) + len(r)) will be the number of elements in a that = pivot (which must be in the range [1, len(a)]), and these are then 'spliced' into the result between the result of quicksorting l and r.
	[[User:Jstout\|Jstout]] ([[User talk:Jstout\|talk]]) 19:48, 26 May 2016 (UTC)		[[User:Jstout\|Jstout]] ([[User talk:Jstout\|talk]]) 19:48, 26 May 2016 (UTC)
		+
		+	== Resemblance to Xerox number mangling issue ==
		+
		+	To me, this reminds me of the problem that a large set of Xerox copiers had. Their faulty use of image compression when scanning could cause portions of images to be replaced with similar portions, but the threshold of similarity was loose enough that numeric data would be subtly corrupted. For example, building plans and spreadsheet data could have numbers copied incorrectly, either of which could certainly have disastrous consequences. Documents were corrupted for a period as much as eight years before the problem was corrected, making legal archive data unreliable for this period, and some of the faulty machines may still be in use. http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning