1537: Types

2015-06-12T22:17:12Z

173.245.53.238: purge title explanation from transcript

{{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. The (highly technical) audience is unable to correctly guess the results of adding various Javascript types and roars with laughter when they're revealed.

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 addition, but 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 an operation. 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 a normal language, this would result either 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 is adding 2 to the ASCII value of the character <code>"2"</code>, which (interpreted as a string) is <code>"4"</code>. This is (somewhat) consistent with the behavior for item 4.
# <code>"2" + []</code> adds a string to an array (a 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).
# <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>, as if <code>2</code> was added to <code>"N"</code> to produce <code>"P"</code> (as per alphabetical order or ASCII encoding; <code>N</code> is <code>01001110</code>, and adding 2 to this results in <code>01010000</code> which is <code>P</code>).
# <code>""+""</code> looks like it is concatenating (adding) an empty string (i.e. <code>""</code>) to another empty string, which should produce an empty string. However, the entire thing is treated as one string (with the start quote being the first one and the end quote being the very last one), which produces the egregious '<code>"+"</code>'.
# <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> is equivalent to the number <code>12</code>
# <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 make green). 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}}

Talk:953: 1 to 10

2015-04-22T08:16:49Z

173.245.53.238:

1.(1) is the best answer I've got [[User:Halfhat|Halfhat]] ([[User talk:Halfhat|talk]]) 11:53, 5 April 2014 (UTC)

"How likely" it is? As everyone knows, "every base is base 10", since every base number in its own numbering system is written as "10" (2 is 10 in binary, 16 is 10 in hex and so on). So that question could be in EVERY number system possible. There are an '''infinite amount of number systems''' that use the symbols 1 and 0. I suppose the probability is then 1 over an infinite number of systems, then very unlikely, so I'd say (as 0 is not in the range of possible answers) the answer is 1. Which, incidentally, is also an acceptable answer for every system. If we want instead to take into account that Megan doesn't know what a 4 is, the possibilities are only base 2, 3 and 4. So the likeliness is 1/3, which corresponds anyway to 1 in those number systems. --[[Special:Contributions/108.162.229.31|108.162.229.31]] 14:05, 3 June 2014 (UTC)

If we assume '''the question was auditory''' to the questioned, the way '10' was articulated is another source of information: the enquirer can pronounce '10' as ''"ten"'' or ''"one zero"''.
In the first case, if he said ''"ten"'', this points towards the base system being greater than/equal to 10. For example ''"ten"'' would be "10" in decimal (base 10) and "16" in hexadecimal (base 16). The word "ten" stops making sense for bases 2 through 9, which leads us to the conclusion of this case: the probability of the question being base 2 is zero, therefore the closest possible score one can give is 1.
In the case that "10" is pronounced ''"one zero"'': using the same logic as in the first case, the question can use any base 2 through 9. giving us a probability of 1/8, the nearest score again being 1.

So if the question were: "On a scale from one to one zero, how likely is this question using the decimal system?" Could be answered with full confidence

One of correct answers is P = 1 + 1 - |sgn(10 - 1 - 1)|

(|x| is absolute value of x, sgn(x) is 1 when x > 0, 0 when x = 0, and -1 when x < 0)

If 10 = 1 + 1, then P = 10 - |sgn(0)| = 10 - |0| = 10

If 10 > 1 + 1, then P = 1 + 1 - |sgn(10 - 1 - 1)| = 1 + 1 - |1| = 1

If 10 < 1 + 1, then P = 1 + 1 - |sgn(10 - 1 - 1)| = 1 + 1 - |-1| = 1

So P is 10 iif the question was is in binary, and 1 iif it was not in binary.

[[Special:Contributions/93.73.186.104|93.73.186.104]] 16:26, 6 February 2013 (UTC)
:The absolute value is unnecessary. When is 10 ever less than 1+1?[[Special:Contributions/108.162.219.202|108.162.219.202]] 20:28, 3 January 2014 (UTC)

I don't think the explanation is right, I mean i don't know binary but i don't think the joke is that he's saying a 4 as in 100% [[User:Lackadaisical|Lackadaisical]] ([[User talk:Lackadaisical|talk]]) 00:23, 7 November 2013 (UTC)
:A 4 is not 100%, but a 3/4 is always 75%. [[Special:Contributions/108.162.212.206|108.162.212.206]] 22:47, 26 January 2014 (UTC)
:Actually, my comment was in reference to this: "Since 4 in binary is "100" (one-zero-zero) the joke is that it is 100% likely that the question is binary -- or it could simply be 4 of 10 - which means that the question has evolved into recursive ambiguity. Also, the person asking the question does not know what a 4 is since there is no 4 in binary." The problem I had with it was taken care of in a previous edit (The quote was taken from the 31 December 2013 edit.)--[[User:Lackadaisical|Lackadaisical]] ([[User talk:Lackadaisical|talk]]) 22:03, 26 March 2015 (UTC)

It seems that the best answer to this question is 1.11111... because it approaches 10 in binary, and is very low in almost any other number system. {{unsigned ip|173.245.54.169}}

explain xkcd - User contributions [en]

1537: Types

Talk:953: 1 to 10