Talk:1275: int(pi) - Revision history

81.179.199.253 at 01:50, 14 February 2026

2026-02-14T01:50:10Z

SeaDragon1 at 22:42, 13 February 2026

2026-02-13T22:42:30Z

172.71.178.65 at 03:42, 15 March 2023

2023-03-15T03:42:27Z

172.71.158.230 at 00:53, 15 March 2023

2023-03-15T00:53:08Z

141.101.98.202 at 21:29, 25 October 2017

2017-10-25T21:29:33Z

141.101.98.202 at 21:28, 25 October 2017

2017-10-25T21:28:19Z

199.27.130.180 at 17:59, 22 September 2015

2015-09-22T17:59:43Z

199.27.130.180 at 17:34, 22 September 2015

2015-09-22T17:34:26Z

108.162.216.172 at 06:19, 23 August 2015

2015-08-23T06:19:29Z

141.101.98.237 at 18:34, 4 January 2015

2015-01-04T18:34:10Z

← Older revision		Revision as of 01:50, 14 February 2026
Line 65:		Line 65:

	One reason the program might not work is that ^ is the bitwise or operator. So x^y isn't x to y, it's x bitor y. To use powers, do x**y. [[User:SeaDragon1\|SeaDragon1]] ([[User talk:SeaDragon1\|talk]]) 22:42, 13 February 2026 (UTC)		One reason the program might not work is that ^ is the bitwise or operator. So x^y isn't x to y, it's x bitor y. To use powers, do x**y. [[User:SeaDragon1\|SeaDragon1]] ([[User talk:SeaDragon1\|talk]]) 22:42, 13 February 2026 (UTC)
		+	:Depends upon the dialect of code you're using.
		+	:From memory, your typical Pascal (and/or Delphi, been a while since I've used either) would interpret the ^ as pointer-handler, and you'd probably have to resort to using an actual <code>power(x,y)</code> function at the appropriate point. I don't think COBOL ''had'' native exponentiation. I've a feeling Python probably uses a function/method, too, but I'm still more a Perl-person (where it is , and you can also ''really'' have fun with the perlops), and the closer a language is to C then... yes... you're probably more likely to code it as (and I hazily remember Ada as using it). But there's no sign that this isn't just pseudocode, which you'll trivially translate into the right keypresses for the final development platform of choice. [[Special:Contributions/81.179.199.253\|81.179.199.253]] 01:50, 14 February 2026 (UTC)

← Older revision		Revision as of 22:42, 13 February 2026
Line 63:		Line 63:
	:Ignore case restraints, it being xkcd all-uppercase (whether Caps or SmallCaps). Much of the statement is typical of most languages with 'normal' mathematical operands (rule out LISP and Forth, for Polish/Reverse Polish notation). There are many computer languages that assign values with "=" (as opposed to ":=", e.g. those in the Pascal family), so only partly helps. Though it looks a bit like a function-definition such as found in BASIC (should have DEFFN keyword, in the version I used), perhaps it's assigning the calculation to array-item 'R' in a language that uses ()s for array-indexing. Or it ''could'' even be a Fortran-dialect masked array on the LHS of the assignment.		:Ignore case restraints, it being xkcd all-uppercase (whether Caps or SmallCaps). Much of the statement is typical of most languages with 'normal' mathematical operands (rule out LISP and Forth, for Polish/Reverse Polish notation). There are many computer languages that assign values with "=" (as opposed to ":=", e.g. those in the Pascal family), so only partly helps. Though it looks a bit like a function-definition such as found in BASIC (should have DEFFN keyword, in the version I used), perhaps it's assigning the calculation to array-item 'R' in a language that uses ()s for array-indexing. Or it ''could'' even be a Fortran-dialect masked array on the LHS of the assignment.
	:Easier to say what it isn't, I suspect. [[Special:Contributions/172.71.178.65\|172.71.178.65]] 03:42, 15 March 2023 (UTC)		:Easier to say what it isn't, I suspect. [[Special:Contributions/172.71.178.65\|172.71.178.65]] 03:42, 15 March 2023 (UTC)
		+
		+	One reason the program might not work is that ^ is the bitwise or operator. So x^y isn't x to y, it's x bitor y. To use powers, do x**y. [[User:SeaDragon1\|SeaDragon1]] ([[User talk:SeaDragon1\|talk]]) 22:42, 13 February 2026 (UTC)

← Older revision		Revision as of 03:42, 15 March 2023
Line 59:		Line 59:


−	What programming language is it?	+	What programming language is it? {{unsigned ip\|172.71.158.230\|00:53, 15 March 2023}}
		+	:Might be pseudocode. But I imagine there are a number of possible 'real' codings it could be.
		+	:Ignore case restraints, it being xkcd all-uppercase (whether Caps or SmallCaps). Much of the statement is typical of most languages with 'normal' mathematical operands (rule out LISP and Forth, for Polish/Reverse Polish notation). There are many computer languages that assign values with "=" (as opposed to ":=", e.g. those in the Pascal family), so only partly helps. Though it looks a bit like a function-definition such as found in BASIC (should have DEFFN keyword, in the version I used), perhaps it's assigning the calculation to array-item 'R' in a language that uses ()s for array-indexing. Or it ''could'' even be a Fortran-dialect masked array on the LHS of the assignment.
		+	:Easier to say what it isn't, I suspect. [[Special:Contributions/172.71.178.65\|172.71.178.65]] 03:42, 15 March 2023 (UTC)

← Older revision		Revision as of 00:53, 15 March 2023
Line 57:		Line 57:

	In CLC-INTERCAL, if you use the default/example library, 3 is the only constant you can't overload (unless you first redefine or abstain various seemingly unrelated things). Also, the slat operator is for operand overloading, and the sharkfin operator is for unary add without carry; I don't know why anyone would think they're for division and power or xor. [[Special:Contributions/199.27.130.180\|199.27.130.180]] 17:59, 22 September 2015 (UTC)		In CLC-INTERCAL, if you use the default/example library, 3 is the only constant you can't overload (unless you first redefine or abstain various seemingly unrelated things). Also, the slat operator is for operand overloading, and the sharkfin operator is for unary add without carry; I don't know why anyone would think they're for division and power or xor. [[Special:Contributions/199.27.130.180\|199.27.130.180]] 17:59, 22 September 2015 (UTC)
		+
		+
		+	What programming language is it?

@@ Line 17: / Line 17: @@
 : Actual line of code from a commercially released ZX Spectrum game: (''Cricket Captain'', D&H Games, 1988)
-PRINT AT VAL "21",NOT PI;"Your bid has been accepted": LET YP=YP+SGN PI: LET Y$(YP)=P$(SC,N(M(SC,KK))): LET RZ=N(M(SC,KK): FOR Z=SGN PI TO INT PI: GO SUB VAL "9002"+Z:LET Y(YP,Z)=BZ: NEXT Z: FOR Z=VAL "4" TO VAL "6": GO SUB VAL "8996"+Z: LET Y(YP,Z)=BZ: NEXT Z: LET MO=MO-VAL Z$: GO SUB VAL "995"
+PRINT AT VAL "21",NOT PI;"Your bid has been accepted": LET YP=YP+SGN PI: LET Y$(YP)=P$(SC,N(M(SC,KK))): LET RZ=N(M(SC,KK)): FOR Z=SGN PI TO INT PI: GO SUB VAL "9002"+Z:LET Y(YP,Z)=BZ: NEXT Z: FOR Z=VAL "4" TO VAL "6": GO SUB VAL "8996"+Z: LET Y(YP,Z)=BZ: NEXT Z: LET MO=MO-VAL Z$: GO SUB VAL "995"
 : '''shudder''' [[Special:Contributions/141.101.98.202|141.101.98.202]] 21:28, 25 October 2017 (UTC)

@@ Line 15: / Line 15: @@
 I can give you one '''rational''' reason for spelling out things like INT(PI) in programming. Back in the ancient times, there was a piece of electronics dubbed then a ''personal computer'' with an NSA code name of ZXSPECTRUM. It had a built-in interpreter of the ancient language codenamed BASIC. Memory was very precious in those times, every single byte counted. The creators of the interpreter did a (somewhat) clever thing - all keywords of this particular dialect of the BASIC language were stored in memory as single-byte codes, and were only spelled out by text display routines. On the other hand, CPU cycles were precious, too, so they did another (not so) clever thing by storing number constants (like the cursed number mentioned above) twofold - both in an ASCII decimal form for display purposes and in a 6-byte internal binary form for computing purposes. Therefore each number occupied the space of six bytes plus the number of digits (or other characters like sign, decimal point, etc.) BASIC hackers exploited this (mis)features to save a few bytes on some commonly-used constants by saying INT PI (parentheses were not needed), NOT PI (to get 0) or SGN PI (to get 1), thus using only 2 bytes of memory instead of 7 if the numbers were used directly. Another trick to use with larger numbers was VAL "12345", which saved 3 bytes for each number spelled this way (number of digits plus three bytes for the VAL keyword and two quote marks instead of number of digits plus six bytes of internal representation). [[Special:Contributions/89.174.214.74|89.174.214.74]] 08:43, 9 October 2013 (UTC)
 : Actually the internal binary form of the number was 5 bytes, but there was a special prefix byte used for two purposes, a) when listing the program the text display routines would simply skip the six bytes b) when a digit character was encountered at run time, the prefix byte was located instead of parsing the number again. It was even possible to patch the source code to replace all the digits with a single decimal point because the syntax wasn't checked at runtime. Also the trick was originally used with the ZX81 as it was slower and had less memory. I don't think the sign was stored with the number though, as that would have caused confusion with the unary minus operator. (All of the space-saving tricks mentioned above would slow the program down, of course. Even PI had to be calculated as internally the ZX81/Spectrum only knew the value of π/2.) --[[Special:Contributions/81.138.95.57|81.138.95.57]] 10:43, 9 October 2013 (UTC)
 I suspect in many languages 4/INT(pi) is 1 (as it does integer division) [[Special:Contributions/193.34.186.165|193.34.186.165]] 08:51, 9 October 2013 (UTC)

← Older revision		Revision as of 17:59, 22 September 2015
Line 50:		Line 50:

	Could have something to do with 0,1,n... though i suppose that would make the forbidden number '2'. [[Special:Contributions/108.162.216.172\|108.162.216.172]] 06:19, 23 August 2015 (UTC)		Could have something to do with 0,1,n... though i suppose that would make the forbidden number '2'. [[Special:Contributions/108.162.216.172\|108.162.216.172]] 06:19, 23 August 2015 (UTC)
		+
		+	In CLC-INTERCAL, if you use the default/example library, 3 is the only constant you can't overload (unless you first redefine or abstain various seemingly unrelated things). Also, the slat operator is for operand overloading, and the sharkfin operator is for unary add without carry; I don't know why anyone would think they're for division and power or xor. [[Special:Contributions/199.27.130.180\|199.27.130.180]] 17:59, 22 September 2015 (UTC)

@@ Line 18: / Line 18: @@
 I suspect in many languages 4/INT(pi) is 1 (as it does integer division) [[Special:Contributions/193.34.186.165|193.34.186.165]] 08:51, 9 October 2013 (UTC)
 :This is true in C and python and many others. I think it is standard.[[Special:Contributions/96.251.85.48|96.251.85.48]] 18:18, 9 October 2013 (UTC)
 Why is the number 3 cursed? [[Special:Contributions/109.90.202.41|109.90.202.41]] 18:15, 9 October 2013 (UTC)
 :I don't remember all the details, but it involves Alan Turing and an ancient vampire.[[Special:Contributions/96.251.85.48|96.251.85.48]] 18:18, 9 October 2013 (UTC)

← Older revision		Revision as of 06:19, 23 August 2015
Line 45:		Line 45:

	I have heard that in several placed the number three is unlucky. Firstly, the number of the beast - 666 - is three sixes and a multiple of three. Secondly the superstition of [http://en.m.wikipedia.org/wiki/Three_on_a_match_%28superstition%29 Three on a Match]. [[Special:Contributions/141.101.98.237\|141.101.98.237]] 18:34, 4 January 2015 (UTC)		I have heard that in several placed the number three is unlucky. Firstly, the number of the beast - 666 - is three sixes and a multiple of three. Secondly the superstition of [http://en.m.wikipedia.org/wiki/Three_on_a_match_%28superstition%29 Three on a Match]. [[Special:Contributions/141.101.98.237\|141.101.98.237]] 18:34, 4 January 2015 (UTC)
		+
		+	Could have something to do with 0,1,n... though i suppose that would make the forbidden number '2'. [[Special:Contributions/108.162.216.172\|108.162.216.172]] 06:19, 23 August 2015 (UTC)

← Older revision		Revision as of 18:34, 4 January 2015
Line 42:		Line 42:
	*Said that instead there "should be a constant defined like "THREE=3"", which isn't the workaround used in the comic (And violates the 'don't use 3' rule at least once)		*Said that instead there "should be a constant defined like "THREE=3"", which isn't the workaround used in the comic (And violates the 'don't use 3' rule at least once)
	I hope the resulting explanation is a little more closely linked to the actual comic, and makes a bit more sense --[[User:Pudder\|Pudder]] ([[User talk:Pudder\|talk]]) 11:18, 22 October 2014 (UTC)		I hope the resulting explanation is a little more closely linked to the actual comic, and makes a bit more sense --[[User:Pudder\|Pudder]] ([[User talk:Pudder\|talk]]) 11:18, 22 October 2014 (UTC)
		+
		+
		+	I have heard that in several placed the number three is unlucky. Firstly, the number of the beast - 666 - is three sixes and a multiple of three. Secondly the superstition of [http://en.m.wikipedia.org/wiki/Three_on_a_match_%28superstition%29 Three on a Match]. [[Special:Contributions/141.101.98.237\|141.101.98.237]] 18:34, 4 January 2015 (UTC)