1551: Pluto

2015-07-14T20:13:42Z

Nealmcb: may not be craters

1551: Pluto

2015-07-14T20:12:39Z

Nealmcb: artifacts

1537: Types

2015-06-13T12:50:40Z

Nealmcb: copyedit

{{comic
| number = 1537
| date = June 12, 2015
| title = Types
| image = types.png
| titletext = colors.rgb("blue") yields "#0000FF". colors.rgb("yellowish blue") yields NaN. colors.sort() yields "rainbow"
}}

==Explanation==
{{incomplete|Title text not explained. More details before the list.}}

This comic is a series of programming jokes about a ridiculous new programming language, perhaps inspired by [https://www.destroyallsoftware.com/talks/wat Gary Bernhardt's CodeMash 2012 lightning talk] on JavaScript's unpredictable typing. In the talk, the (highly technical) audience was unable to correctly guess the results of adding various JavaScript types and roared with laughter when they were revealed. The programming language shown in this comic has types even more unpredictable than JavaScript.

Most regular programming languages distinguish a number of types, e.g. integers, strings, lists… all of which have different behaviours. The operation "+" is conventionally defined over more than one of these types. Applied to two integers, it returns their sum. Applied to two strings (denoted by being enclosed in quotes) it concatenates them:

<code>> 2 + 3

5

> "123" + "abc"

"123abc"</code>

While these behaviours are standard, conventional, and intuitive, there is a huge amount of variation among programming languages when you apply an operation like "+" to different types. One logical approach is to always return an error in all cases of type mixing, but it is often practical to allow some case mixing, since it can hugely simplify expressions. Variation and lack of a clearly more intuitive behaviour leads some languages to have weird results when you mix types.

# <code>2 + "2"</code> uses the <code>+</code> operator on a number and a string. In some programming languages, this might result in the number <code>4</code> (addition), or <code>"22"</code> (string concatenation); however, the new language converts the string to an integer, adds them to produce <code>4</code> and converts back to a string. Alternately, it may instead be adding 2 to the ASCII value of the character <code>"2"</code> (50), resulting in the character <code>"4"</code> (52). This is (somewhat) consistent with the behavior for item 4.
# <code>"2" + []</code> adds a string to an array or list. This first inexplicably converts the string to a number again, and then it literally adds the number to the list by appending it (this would make sense if it was <code>[] + 2</code>, but usually not the other way around). And then the result (the entire array) is converted to a string again.
# <code>(2/0)</code> divides <code>2</code> by <code>0</code> and quite reasonably results in <code>NaN</code> (not a number), though in most languages, as prescribed by the IEEE 854 standard for floating point numbers, dividing a nonzero number by zero would instead return an infinity value.
# <code>(2/0)+2</code> adds <code>2</code> to <code>NaN</code>. <code>2</code> is "added" to the string <code>"NaN"</code> (again, the number is converted to a string for apparently no reason), which produces <code>"NaP"</code>. If the language's convention is to add to the ASCII value of a character or string, then in this case it added 2 to the character <code>"N"</code> (78), resulting in <code>"P"</code> (80).
# <code>""+""</code>: In many languages, two consecutive double-quote characters denote an empty string, so this expression would concatenate two empty strings, resulting in an empty string. However, it appears that this language treats only the outermost quotes of the expression as the string boundary, so all of the characters between them become part of the literal string, producing '<code>"+"</code>' (In many programming languages, you can use both <code>"</code> or <code>'</code> to delimit strings and both behave similar if not identical).
# <code>[1,2,3]+2</code> seems to test whether it's sound to append <code>2</code> to the list <code>[1,2,3]</code>, and concludes that it doesn't fit the pattern, returning the boolean value <code>false</code>. It could conceivably also be the result of an attempt to add <code>2</code> to the ''set'' <code>[1,2,3]</code>, which already contains that element (although <code>{1,2,3}</code> would be a more common notation for sets).
# <code>[1,2,3]+4</code> returns <code>true</code> for much the same reason.
# <code>2/(2-(3/2+1/2))</code> is a floating point joke. Floating point numbers are notoriously imprecise. With precise mathematics, <code>(3/2+1/2)</code> would be exactly 2, hence the entire thing would evaluate to <code>2/0</code> or <code>NaN</code> in Randall's new language. However, the result of <code>(3/2+1/2)</code> is "just slightly off," which makes the result "just slightly off" of <code>NaN</code>, which would be ridiculous in a real language. The ironic thing is that fractions with 2 in the denominator are ''not'' the kind of numbers that typically suffer from floating point impreciseness. Additionally, if there was indeed a rounding error, the actual calculation becomes something like <code>2/0.0000000000000013</code>, which should not return a <code>NaN</code> since it is not division by zero.
# <code>range(" ")</code> normally wouldn't make any sense. However, the new language appears to interpret it as ASCII, and in the ASCII table, character #32 is space, #33 is <code>!</code>, and #34 is <code>"</code>. So, instead of interpreting <code>" "</code> as a string, it seems to be interpreted as <code>34, 32, 34</code> (in ASCII), and then <code>range</code> appears to transform this into <code>34, 33, 32, 33, 34</code> (the "ranges" between the numbers), which, interpreted as ASCII, becomes <code>['"', '!', ' ', '!', '"']</code>.
# <code>+2</code> refers to the Chinese/Japanese (Kanji) number system, where the plus sign is instead the symbol <code>十</code>. In Chinese, this symbol represents the number ten, and if you translate the <code>2</code> into Chinese, you get <code>二</code>. Therefore, in full Chinese the code is <code>十二</code>, which is equivalent to the number <code>12</code>. Alternately, it could simply be attempting to add 2 to the line number 10 to get 12.
# <code>2+2</code> would normally be <code>4</code>. However, the interpreter takes this instruction to mean that the user wishes to increase the actual value of the number <code>2</code> (aka the "literal value") by <code>2</code> for the remainder of the program, making it <code>4</code> and then reports that the work is "Done". The result can be seen in the subsequent lines where all <code>2</code>s are replaced by <code>4</code>s. This could be a reference to languages like Fortran where [http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN literals could be assigned new values].
# <code>range(1,5)</code> would normally return <code>[1, 2, 3, 4, 5]</code>. However, since the value of <code>2</code> has been changed to <code>4</code>, it returns <code>[1, 4, 3, 4, 5]</code>, and this even affects the line number (which is 14 instead of 12).
# <code>floor(10.5)</code> should return <code>10</code> (the "floor" of a decimal number is that number rounded down). However, it instead returns {{w|ASCII art}} of the number on a "floor."

The title text contains three further examples relating to color. <code>color.rgb("blue")</code> returns the hexadecimal code for pure blue (as would be used in HTML, for example), which is how a real programming language might work. The lookup for "yellowish blue" returns "NaN" (Not a Number) again, which makes sense at one level because there is no such color as "yellowish blue" (yellow and blue are opposites on the color wheel, making yellowish-blue an {{w|impossible colour}}, which can only be perceived with great difficulty through contrived figures). However a more typical result would have been a failure indicating that the color database does not include the name, in the same way that a typo such as "bluw" would. Similarly sorting the colors would normally produce some defined ordering, such as alphabetical, but in this language it generates the string "rainbow". It seems that Randall's new language understands color theory in an unusually deep way.

==Transcript==
My new language is great, but it has a few quirks regarding type:
<pre>
[1]> 2+"2"
=> "4"
[2]> "2"+[]
=> "[2]"
[3] (2/0)
=> NaN
[4]> (2/0)+2
=> NaP
[5]> ""+""
=> '"+"'
[6]> [1,2,3]+2
=> FALSE
[7]> [1,2,3]+4
=> TRUE
[8]> 2/(2-(3/2+1/2))
=> NaN.0000000000000013
[9]> range(" ")
=> ('"','!'," ","!",'"')
[10]> +2
=> 12
[11]> 2+2
=> DONE
[14]> RANGE(1,5)
=> (1,4,3,4,5)
[13]> FLOOR(10.5)
=> |
=> |
=> |
=> |___10.5___
</pre>
{{comic discussion}}
[[Category:Programming]]
[[Category:Language]]

1537: Types

2015-06-13T12:48:22Z

Nealmcb: conventional term

{{comic
| number = 1537
| date = June 12, 2015
| title = Types
| image = types.png
| titletext = colors.rgb("blue") yields "#0000FF". colors.rgb("yellowish blue") yields NaN. colors.sort() yields "rainbow"
}}

==Explanation==
{{incomplete|Title text not explained. More details before the list.}}

This comic is a series of programming jokes about a ridiculous new programming language, perhaps inspired by [https://www.destroyallsoftware.com/talks/wat Gary Bernhardt's CodeMash 2012 lightning talk] on JavaScript's unpredictable typing. In the talk, the (highly technical) audience was unable to correctly guess the results of adding various JavaScript types and roared with laughter when they were revealed. The programming language shown in this comic has types even more unpredictable than JavaScript.

Most regular programming languages distinguish a number of types, e.g. integers, strings, lists… all of which have different behaviours. The operation "+" is conventionally defined over more than one of these types. Applied to two integers, it returns their sum. Applied to two strings (denoted by being enclosed in quotes) it concatenates them:

<code>> 2 + 3

5

> "123" + "abc"

"123abc"</code>

While these behaviours are standard, conventional, and intuitive, there is a huge amount of variation among programming languages when you apply an operation like "+" to different types. One logical approach is to always return an error in all cases of type mixing, but it is often practical to allow some case mixing, since it can hugely simplify expressions. Variation and lack of a clearly more intuitive behaviour leads some languages to have weird results when you mix types.

# <code>2 + "2"</code> uses the <code>+</code> operator on a number and a string. In some programming languages, this might result in the number <code>4</code> (addition), or <code>"22"</code> (string concatenation); however, the new language converts the string to an integer, adds them to produce <code>4</code> and converts back to a string. Alternately, it may instead be adding 2 to the ASCII value of the character <code>"2"</code> (50), resulting in the character <code>"4"</code> (52). This is (somewhat) consistent with the behavior for item 4.
# <code>"2" + []</code> adds a string to an array or list, this time. This first inexplicably converts the string to a number again, and then it literally adds the number to the list by appending it (this would make sense if it was <code>[] + 2</code>, but usually not the other way around). And then the result (the entire array) is converted to a string again.
# <code>(2/0)</code> divides <code>2</code> by <code>0</code> and quite reasonably results in <code>NaN</code> (not a number), though in most languages, as prescribed by the IEEE 854 standard for floating point numbers, dividing a nonzero number by zero would instead return an infinity value.
# <code>(2/0)+2</code> adds <code>2</code> to <code>NaN</code>. <code>2</code> is "added" to the string <code>"NaN"</code> (again, the number is converted to a string for apparently no reason), which produces <code>"NaP"</code>. If the language's convention is to add to the ASCII value of a character or string, then in this case it added 2 to the character <code>"N"</code> (78), resulting in <code>"P"</code> (80).
# <code>""+""</code>: In many languages, two consecutive double-quote characters denote an empty string, so this expression would concatenate two empty strings, resulting in an empty string. However, it appears that this language treats only the outermost quotes of the expression as the string boundary, so all of the characters between them become part of the literal string, producing '<code>"+"</code>' (In many programming languages, you can use both <code>"</code> or <code>'</code> to delimit strings and both behave similar if not identical).
# <code>[1,2,3]+2</code> seems to test whether it's sound to append <code>2</code> to the list <code>[1,2,3]</code>, and concludes that it doesn't fit the pattern, returning the boolean value <code>false</code>. It could conceivably also be the result of an attempt to add <code>2</code> to the ''set'' <code>[1,2,3]</code>, which already contains that element (although <code>{1,2,3}</code> would be a more common notation for sets).
# <code>[1,2,3]+4</code> returns <code>true</code> for much the same reason.
# <code>2/(2-(3/2+1/2))</code> is a floating point joke. Floating point numbers are notoriously imprecise. With precise mathematics, <code>(3/2+1/2)</code> would be exactly 2, hence the entire thing would evaluate to <code>2/0</code> or <code>NaN</code> in Randall's new language. However, the result of <code>(3/2+1/2)</code> is "just slightly off," which makes the result "just slightly off" of <code>NaN</code>, which would be ridiculous in a real language. The ironic thing is that fractions with 2 in the denominator are ''not'' the kind of numbers that typically suffer from floating point impreciseness. Additionally, if there was indeed a rounding error, the actual calculation becomes something like <code>2/0.0000000000000013</code>, which should not return a <code>NaN</code> since it is not division by zero.
# <code>range(" ")</code> normally wouldn't make any sense. However, the new language appears to interpret it as ASCII, and in the ASCII table, character #32 is space, #33 is <code>!</code>, and #34 is <code>"</code>. So, instead of interpreting <code>" "</code> as a string, it seems to be interpreted as <code>34, 32, 34</code> (in ASCII), and then <code>range</code> appears to transform this into <code>34, 33, 32, 33, 34</code> (the "ranges" between the numbers), which, interpreted as ASCII, becomes <code>['"', '!', ' ', '!', '"']</code>.
# <code>+2</code> refers to the Chinese/Japanese (Kanji) number system, where the plus sign is instead the symbol <code>十</code>. In Chinese, this symbol represents the number ten, and if you translate the <code>2</code> into Chinese, you get <code>二</code>. Therefore, in full Chinese the code is <code>十二</code>, which is equivalent to the number <code>12</code>. Alternately, it could simply be attempting to add 2 to the line number 10 to get 12.
# <code>2+2</code> would normally be <code>4</code>. However, the interpreter takes this instruction to mean that the user wishes to increase the actual value of the number <code>2</code> (aka the "literal value") by <code>2</code> for the remainder of the program, making it <code>4</code> and then reports that the work is "Done". The result can be seen in the subsequent lines where all <code>2</code>s are replaced by <code>4</code>s. This could be a reference to languages like Fortran where [http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN literals could be assigned new values].
# <code>range(1,5)</code> would normally return <code>[1, 2, 3, 4, 5]</code>. However, since the value of <code>2</code> has been changed to <code>4</code>, it returns <code>[1, 4, 3, 4, 5]</code>, and this even affects the line number (which is 14 instead of 12).
# <code>floor(10.5)</code> should return <code>10</code> (the "floor" of a decimal number is that number rounded down). However, it instead returns {{w|ASCII art}} of the number on a "floor."

The title text contains three further examples relating to color. <code>color.rgb("blue")</code> returns the hexadecimal code for pure blue (as would be used in HTML, for example), which is how a real programming language might work. The lookup for "yellowish blue" returns "NaN" (Not a Number) again, which makes sense at one level because there is no such color as "yellowish blue" (yellow and blue are opposites on the color wheel, making yellowish-blue an {{w|impossible colour}}, which can only be perceived with great difficulty through contrived figures). However a more typical result would have been a failure indicating that the color database does not include the name, in the same way that a typo such as "bluw" would. Similarly sorting the colors would normally produce some defined ordering, such as alphabetical, but in this language it generates the string "rainbow". It seems that Randall's new language understands color theory in an unusually deep way.

==Transcript==
My new language is great, but it has a few quirks regarding type:
<pre>
[1]> 2+"2"
=> "4"
[2]> "2"+[]
=> "[2]"
[3] (2/0)
=> NaN
[4]> (2/0)+2
=> NaP
[5]> ""+""
=> '"+"'
[6]> [1,2,3]+2
=> FALSE
[7]> [1,2,3]+4
=> TRUE
[8]> 2/(2-(3/2+1/2))
=> NaN.0000000000000013
[9]> range(" ")
=> ('"','!'," ","!",'"')
[10]> +2
=> 12
[11]> 2+2
=> DONE
[14]> RANGE(1,5)
=> (1,4,3,4,5)
[13]> FLOOR(10.5)
=> |
=> |
=> |
=> |___10.5___
</pre>
{{comic discussion}}
[[Category:Programming]]
[[Category:Language]]

1533: Antique Factory

2015-06-06T14:18:08Z

Nealmcb: paradoxical

{{comic
| number = 1533
| date = June 3, 2015
| title = Antique Factory
| image = antique_factory.png
| titletext = WARNING: This item was aged by the same inexorable passage of time that also processes nuts.
}}

==Explanation==
[[Beret Guy]] has a new job with a paradoxical premise. When asked where he works, he says “{{w|Antique}} factory!” which seems to be a contradiction since you cannot build an antique object directly in a factory. Only when the item is old enough to be worth more than the original price, (and will often have been in use during this time period) can it be called an antique.

Beret Guy walks up to a chair, a table, and a small cabinet, sits down in the chair, and does nothing else. Of course, one does not simply make antiques. Instead, one must wait. Beret Guy appears to be doing exactly this. The implication is that the “antique factory” is simply a place where furniture is stored until it becomes old enough to be considered “antique,” and that Beret Guy doesn’t perform any useful function (except perhaps using the items to make them look old and worn or keeping an eye on the inventory so it won’t be stolen).

The title text refers to allergy warning labels saying ''May contain nuts''. More specifically, they may say “Manufactured in a facility which also processes nuts,” “Manufactured on equipment that processes products containing nuts,” “Manufactured on equipment that uses nuts,” or similar. These warnings indicate that bits of powder and oil from nuts may have been mixed into the product, creating a hazard to people with nut allergies. Sometimes these warnings are used for allergens besides nuts, but nuts may be the most common.

The joke here is that of course the time that has passed for a specific antique item will be the same time that has also passed while some nuts somewhere have grown. Thus the time that has [[wiktionary:inexorable#Adjective|inexorably]] passed to make a specific item antique will also have processed nuts.

Beret Guy has previously "traveled" into the future in [[209: Kayak]].

==Transcript==
:[Beret Guy is leaving with a briefcase in hand.]
:Beret Guy: Gotta go - I'm late for work.
:Off-screen voice: Oh, where are you working now?
:Beret Guy: Antique factory!

:[Beret Guy arrives and pulls out a chair in front of a table and a small cabinet.]

:[Beret Guy sits on the chair in front of the table. He has placed the briefcase behind the chair.]

:[An almost identical panel is repeated once more.]

{{comic discussion}}
[[Category:Comics featuring Beret Guy]]

1532: New Horizons

2015-06-02T13:10:27Z

Nealmcb: not protoplanets

{{comic
| number = 1532
| date = June 1, 2015
| title = New Horizons
| image = new_horizons.png
| titletext = Last-minute course change: Let's see if we can hit Steve's house.
}}

==Explanation==
''{{w|New Horizons}}'' is a NASA mission launched in 2006 to study the dwarf planet {{w|Pluto}} and its moons. Its closest approach to Pluto will be on July 14, 2015 [http://www.nasa.gov/mission_pages/newhorizons/main/index.html]. In April and May 2015, it captured the first images of Pluto with enough resolution to see some details on Pluto's surface [http://www.nasa.gov/feature/nasa-s-new-horizons-sees-more-detail-as-it-draws-closer-to-pluto]. These images are similar to the second pane of the comic, with Pluto shown as a gray dot only a few pixels wide.

''{{w|Dawn (spacecraft)|Dawn}}'' is a NASA mission launched in September 2007 to study the asteroid {{w|4 Vesta|Vesta}} and dwarf planet {{w|Ceres (dwarf planet)|Ceres}}. Its closest approach to Vesta began on July 16, 2011 [http://en.wikipedia.org/wiki/Dawn_(spacecraft)#Vesta_approach], and entered orbit around Ceres on 6 March 2015.

On the day this comic was published, ''New Horizons'' was at 0.34 AU from Pluto and 32.55 AU from the Sun [http://pluto.jhuapl.edu/Mission/Where-is-New-Horizons/index.php]. One AU ({{w|Astronomical unit}}) is the approximate distance of Earth from the Sun, or about 150 million kilometers.

Distances from the Sun ({{w|semi-major axis}}): Vesta 2.36 AU; Ceres 2.77 AU; Jupiter 5.20 AU; Pluto 39.26 AU.

A {{w|Gravity assist|slingshot maneuver}} is a technique where a spacecraft is maneuvered or accelerated with the help of a gravitational field. In the comic, presumably someone named Steve made the calculations for the New Horizons spacecraft to accelerate toward Pluto using {{w|Jupiter}}'s gravity.

In the first panel we see Cueball and Ponytail standing in front of a computer monitor and observing a series of images sent back from ''New Horizons'' as it approaches the planet. As the image resolution increases, it's obvious that the spacecraft is in fact approaching Earth, not Pluto. They blame this unexpected result on Steve, who apparently miscalculated the Jupiter slingshot maneuver, leading the probe to slingshot back on an incorrect trajectory towards Earth instead of towards Pluto. Needless to say, this is a huge embarrassment, especially in front of the successful ''Dawn'' team, who were the first to get a probe to visit a dwarf planet.

The title text suggests the team is considering crashing the probe into Steve's house as punishment for his errors.

This is likely the same Steve from [[809: Los Alamos]] (set in 1945), given the similar contexts. If so, his calculations may be even more erroneous due to senile dementia.

==Transcript==
:<nowiki>[</nowiki>[[Cueball]] and [[Ponytail]] are standing in front of a large computer console. Cueball's hands are on the keyboard; both are looking at the screen.<nowiki>]</nowiki>
:Cueball: We made it! After all these years, ''New Horizons'' is finally revealing the surface of Pluto!
:Ponytail: Take ''that'', ''Dawn'' team.

:<nowiki>[</nowiki>In the next four frames, we see photos, entirely black except for a circle in the middle. The circle is initially small, indistinct and appears in shades of grey; the successive circles are larger showing more color and shade variation. In the last, we see a blurry but recognizable outline of Africa, the Middle East and part of Western Asia, along with some clouds. The lighting pattern suggests that it is daytime in Africa, sometime in the northern summer.<nowiki>]</nowiki>

:Cueball: OK, who did the calculations for the Jupiter slingshot maneuver?
:Ponytail: (facing away from the computer console) Dammit, Steve...

{{comic discussion}}


[[Category:Comics with color]]
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Ponytail]]
[[Category:Space]]

882: Significant

2015-05-28T16:44:23Z

Nealmcb: p-hacking, rearrange for clarity, and in real life: How, and why, a journalist tricked news outlets into thinking chocolate makes you thin

{{comic
| number = 882
| date = April 6, 2011
| title = Significant
| image = significant.png
| titletext = So, uh, we did the green study again and got no link. It was probably a-- "RESEARCH CONFLICTED ON GREEN JELLY BEAN/ACNE LINK; MORE STUDY RECOMMENDED!"
}}

==Explanation==
This comic is about {{w|Data dredging}} (aka p-hacking), and the misrepresentation of science and statistics in the media. [[Megan]] and [[Cueball]] commission some research on the link between jelly beans and acne, and the result is bad news reporting.

First some basic statistical theory. Let's imagine you are trying to find out if jelly beans cause acne. To do this you could find a group of people and randomly split them into two groups - one group who you get to eat lots of jelly beans and a second group who are banned from eating jelly beans. After some time you compare whether the group that eat jelly beans have more acne than those who do not. If more people in the group that eat jelly beans have acne then you might think that jelly beans cause acne. However, there is a problem.

Some people will suffer from acne whether they eat jelly beans or not and some will never have acne even if they do eat jelly beans. There is an element of chance in how many people prone to acne are in each group. What if, purely by chance, all the group we selected to eat jelly beans would have had acne anyway while those who didn't eat jelly beans were the lucky sort of people who never get spots? Then, even if jelly beans did not cause acne, we would conclude that jelly beans did cause acne. Of course it is very unlikely that all the acne prone people end up in one group by chance, especially if we have enough people in each group. However, to give more confidence in the result of this type of experiment, scientists use statistics to see how likely it is that the result they find is purely by chance. This is known as {{w|statistical hypothesis testing}}. Before we start the experiment, we choose a threshold known as the significance level. In the comic the scientists choose a threshold of 5%. If they find that more of the people who ate jelly beans had acne and the chance it was a purely random result is less than 1 in 20, they will say that jelly beans do cause acne. If however, the chance that their result was purely by random chance is greater than 5% they will say they have found no evidence of a link. The important point is this - '''there could still be a 1 in 20 chance that this result was purely a statistical fluke'''.

At first the scientists do not want to stop playing the addictive game {{w|Minecraft}} (which has been referenced in a [[861|previous xkcd]]), but they do eventually start.

The scientists find no link between jelly beans and acne (the probability that the result is by chance is more than 5% i.e. p > 0.05) but then Megan and Cueball ask them to see if only one colour of jelly beans is responsible. They test 20 different colors each at a significance level of 5%. If the probability that each trial gives a false positive result is 1 in 20, then by testing 20 different colors it is now likely that at least one jelly bean test will give a false positive. To be precise, the probability of having ''no'' false positive in 20 tests is (0.95)^20 = 35.85%. Probability of having ''no'' false positive in 21 tests (counting the test without color discrimination) is (0.95)^21 = 34.06%. In this case they find that green jelly beans do cause acne.

This leads to a big newspaper headline saying '''GREEN JELLY BEANS CAUSE ACNE''' but when the scientists {{w|Reproducibility|repeat the experiment}} (another key part of the scientific method) they find no evidence for a link. They try to tell the reporter that it was probably a coincidence but that is not news. Instead it leads to another major headline saying '''RESEARCH CONFLICTED'''.

This can be an issue with more serious matters than jelly beans and acne - at any one time there are many studies about possible links between substances (e.g. red wine) and illness (e.g. cancer). Because only the positive results get reported, this limits the value any single study has - especially if the mechanism linking the two things is not known.

=== p-hacking and bad news reporting in real life ===
In 2015 some journalists demonstrated the same problem: just how gullible other news outlets are with the same sort of flawed "experimental design": [http://www.washingtonpost.com/news/morning-mix/wp/2015/05/28/how-and-why-a-journalist-tricked-news-outlets-into-thinking-chocolate-makes-you-thin/?hpid=z5 How, and why, a journalist tricked news outlets into thinking chocolate makes you thin - The Washington Post]

==Transcript==
:[Ponytail runs up to another person, who subsequently points off-panel where there are presumably scientists.]
:Ponytail: Jelly beans cause acne!
:Another: Scientists! Investigate!
:Scientists: But we're playing Minecraft! ...Fine.

:[Two scientists. Cueball has safety goggles, Megan has a sheet of notes.]
:Cueball: We found no link between jelly beans and acne (p > 0.05).

:[Back to the original two.]
:Another: That settles that.
:Ponytail: I hear it's only a certain color that causes it.
:Another: Scientists!
:Scientists: But Miiiinecraft!

:[20 near identical small panels follow, 4 rows 5 columns.]
:Cueball: We found no link between purple jelly beans and acne (p > 0.05).

:Cueball: We found no link between brown jelly beans and acne (p > 0.05).

:Cueball: We found no link between pink jelly beans and acne (p > 0.05).

:Cueball: We found no link between blue jelly beans and acne (p > 0.05).

:Cueball: We found no link between teal jelly beans and acne (p > 0.05).

:Cueball: We found no link between salmon jelly beans and acne (p > 0.05).

:Cueball: We found no link between red jelly beans and acne (p > 0.05).

:Cueball: We found no link between turquoise jelly beans and acne (p > 0.05).

:Cueball: We found no link between magenta jelly beans and acne (p > 0.05).

:Cueball: We found no link between yellow jelly beans and acne (p > 0.05).

:Cueball: We found no link between grey jelly beans and acne (p > 0.05).

:Cueball: We found no link between tan jelly beans and acne (p > 0.05).

:Cueball: We found no link between cyan jelly beans and acne (p > 0.05).

:Cueball: We found a link between green jelly beans and acne (p < 0.05).
:Off-panel: ''WHOA!''

:Cueball: We found no link between mauve jelly beans and acne (p > 0.05).

:Cueball: We found no link between beige jelly beans and acne (p > 0.05).

:Cueball: We found no link between lilac jelly beans and acne (p > 0.05).

:Cueball: We found no link between black jelly beans and acne (p > 0.05).

:Cueball: We found no link between peach jelly beans and acne (p > 0.05).

:Cueball: We found no link between orange jelly beans and acne (p > 0.05).

:[Newspaper front page.]
:NEWS Green Jelly Beans Linked To Acne! 95% Confidence
:[There is a picture of 3 green jelly beans.]
:Only 5% chance of coincidence!
:Scientists...

{{comic discussion}}
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Megan]]
[[Category:Comics featuring Ponytail]]
[[Category:Comics with color‏‎]]
[[Category:Statistics]]
[[Category:Video games]]

55: Useless

2015-05-18T18:08:11Z

Nealmcb: move t-shirt note after initial overview

{{comic
| number = 55
| date = January 27, 2006
| title = Useless
| image = useless.jpg
| titletext = Even the identity matrix doesn't work normally
}}

==Explanation==
[[Randall]] is attempting to apply mathematics to the concept of love to no avail. Specifically, he is attempting his "normal approach" which is a term used in mathematics for the method one typically uses to solve a certain type of problem. However, as love is not a well-defined mathematical, his normal approach is useless. Simply put: he's saying he has found no way of describing love, using only the tools of mathematics.

From the top, going right, he tries the {{w|square root}} of love; the {{w|cosine}} of love; the {{w|derivative}} of love with respect to x; he left-multiplies love by a 2x2 {{w|identity matrix}}, and finally he defines a {{w|Function (mathematics)|function}} of love as a {{w|Fourier transform}}. These are all "normal approaches" to solving certain math problems.

The long and the short of the comic is that for someone who uses math to solve all their problems, this might be their thinking when they discover love. It also echoes the idea that love is not always a rational phenomenon.

This comic has been made into a [http://store.xkcd.com/products/useless t-shirt] in the xkcd store, with a {{w|Laplace transform}} in place of the bottom integral.

===Basic explanations of the functions===
:''Note: The Wikipedia links will provide far more detailed explanations of the mathematics.''
*The square root of x is the number which, when multiplied by itself, equals x.
*Cosine is a {{w|trigonometric function}} which, when given the measure of an angle in a {{w|right triangle}} as an input, outputs the ratio of the lengths of two sides of that triangle (for cosine it is the non-{{w|hypotenuse}} side adjacent to the angle and the hypotenuse).
*A derivative of a function is the rate of change of that function at a given value of x. It is a primary focus of {{w|calculus}}. A basic example is where "velocity" is the rate of change of displacement at a given time, the derivative of velocity is "acceleration" which is the rate of change of velocity at a given time.
*Identity matrices are matrices which consist of only zeros and ones, with zeros everywhere except along the {{w|main diagonal}}. Multiplying a matrix by the equal-sized identity matrix will result in the same output in the same way that multiplying a non-matrix by 1 does not change the original term. The title text suggests that multiplying love by the identity matrix does not return the same "love" value.
*A {{w|Fourier transform}} converts a function from one (sophisticated) function into an endless continuous series of (more simple) functions, where each next part is bringing the equation closer to the real result. This means that you can stop your calculations after a few iterations and you are very close to the real result, and it also can be used to deconstruct signals.

==Transcript==
:[Different mathematic equations, all with heart on left side, and all equal question mark. Below is a caption.]
:√♥ = ?
:cos ♥ = ?
:d/dx ♥ = ?
:[10]♥ =?
:[01]
:F{♥} = 1/√2π ∫∞-∞f(t)eit♥dt = ?
:My normal approach is useless here

==Trivia==
*This was the 52nd and last comic originally posted to [[LiveJournal]].
**The previous was [[53: Hobby]].
*This comic kept it's original title: "Useless"
**It is part of the last six comics on LiveJournal which all had a title without the word "Drawing" in it.
**Five of these had exactly the same title on both sites.
**Only 11 comics have the same title on both sites.
**Apart from the [[:Category:First day on LiveJournal|thirteen first comics]] posted to LiveJournal, there were only three other comics without the word "Drawing" in the title before these last six.
*There were no original [[Randall]] quote for this comic.
*This comic was the last of the last 11 comics posted on LiveJournal.
**These 11 comics were [[:Category:Posted on LiveJournal after xkcd|posted both on LiveJournal and xkcd]] after the [[xkcd]] site opened on the 1st of January 2006.
**The first six comics were posted on both sites on the same day.
**And then this first happened again with this last comic.
*The version used on the [http://store.xkcd.com/products/useless t-shirt] and in ''[http://store.xkcd.com/products/xkcd-volume-0 xkcd: volume 0]'' is slightly different. The derivative is with respect to time (''t'') instead of ''x'', and the function at the bottom is a {{w|Laplace transform}}.
*This comic was adapted to a wedding cake featured on [http://www.cakewrecks.com/home/2011/6/26/sunday-sweets-geek-wedding-cakes.html an installment of "Sunday Sweets"], a regular feature on popular blog [http://cakewrecks.com Cake Wrecks].

{{comic discussion}}

[[Category:Comics posted on livejournal| 52]]
[[Category:Posted on LiveJournal after xkcd]]
[[Category:Romance]]
[[Category:Math]]