Talk:Base36

Uses in practice:Dell Express Service Code from the Service Tag {{Fact}}

Re:{{Fact}} -Any one with a Dell Express Service Code can enter the digits here and the result will tally with the Service Tag. Proving thats the system Dell uses.--Trounce 15:29, 11 July 2007 (UTC)[reply]

Your intentions are good, but Wikipedia article pages are not allowed to cite Wikipedia talk pages as references... AnonMoos 01:02, 12 July 2007 (UTC)[reply]

The system id used for installation can be found in C:\DELL\SYSINFO.DAT. This can be viewed remotely via the hidden C$ Administrative share as something like \\Computername\C$\DELL\SYSINFO.DAT .

The system tag with a "D", for Dell, prefix is used as the Computer's default networking name, so a "NET VIEW" command will often show a few Dell System Tags :-) Lent (talk) 18:18, 10 January 2008 (UTC)[reply]

Using Base36 in Java:

   long value = 1854479759125471116L;
   String base36 = Long.toString(value, 36); // "e37y7k86u5xo"

   String base36 = "e37y7k86u5xo";
   long value = Long.parseLong(base36, 36); // 1854479759125471116

-- 74.92.22.18 (talk)

Bugs in sample code

Both the C# and the Python code have bugs - they are missing the case where the value == 0. Both loops should be converted to do-whiles to fix said boundary condition. —Preceding unsigned comment added by 68.13.56.115 (talk) 01:37, 12 May 2009 (UTC)[reply]

Good catch. I've fixed the C# example. I'm not sufficiently familiar with python syntax to feel comfortable messing with the python example. 203.171.85.67 (talk) 02:42, 21 June 2009 (UTC)[reply]

Actually, the python example already explicitly checks for value==0. Guess someone's already fixed it. 203.171.85.67 (talk) 02:46, 21 June 2009 (UTC)[reply]

Another bug/deficiency in Python base64encode example: infinite loop occurs where the value is negative. There might also be a similar bug in the C# example, but I'm unable to test that one. In any case, both of these examples appear to assume a positive input value, but neither of them appear to enforce their assumption; and both appear to accept a signed value while not being able to handle it appropriately. 203.171.85.67 (talk) 02:53, 21 June 2009 (UTC)[reply]

who?

who invented it? name names. — Preceding unsigned comment added by 174.58.93.63 (talk • contribs)

There were a lot of restricted character sets in telegraphy and the early days of computing: Baudot code, Fieldata, DEC Radix-50, etc... Using alphanumerics only is a natural idea when you don't want to bother with non-alphanumerics. AnonMoos (talk) 13:08, 15 December 2014 (UTC)[reply]

case insensitive

Most of the code samples given are not case insensitive. I'm even guilty of this having modified the C# example to match the case-sensitivity of the C example. The question is, is string representation supposed to be upper or lower case? Or is it supposed to be immune to upper and lower case. If the latter is true, then many of the examples are broken. War (talk) 15:56, 8 May 2013 (UTC)[reply]

It depends on the particular application... AnonMoos (talk) 13:09, 15 December 2014 (UTC)[reply]

Lower case in practice

It must be noted that in practice lower case characters are easier to recognize from some number. Typical case are confusion between the number zero '0' and upper letter 'O', between number '1' and letter 'I', between number '8' and letter 'B', and between number '5' and letter 'S'. — Preceding unsigned comment added by 213.221.150.139 (talk) 18:55, 2 October 2013 (UTC)[reply]

It occurs to me that perhaps the idea of compression would work better if the compressed digits looked more like the senary double-digit counterparts. So "5" would be instead written something like "0͜5", "8" would be "1͜2", and "X" would be "5͜3" at first occurrence. (The ties are being used as a quick solution.) Then we would introduce the idea of alphanumerics, once the idea of compression has been fully understood by the reader. Double sharp (talk) 14:51, 29 January 2015 (UTC)[reply]

Unify Sample Algorithms

The C sample is optimized for Base36 and only Base36. The C# is made to work with any base. Subsequently the C version is considerably faster than the C# version. I worry that people will assume this is a language limitation when in fact this article is implementing two entirely different algorithms in the two languages. I'd liked to see this article use the same goal in all samples. By goal I mean, "fastest" or "most general purpose" or "easiest to read" and apply this standard to all the language examples.War (talk) 13:55, 4 October 2013 (UTC)[reply]

I think that one psuedocode example of an imperative, table-based algorithm would be sufficient. A functional example would also make sense. This article should not be a repository of base36 implementations. Leave that to each programming language to solve itself. —C45207 | Talk 23:22, 17 November 2017 (UTC)[reply]

I would agree broadly with that, but would avoid pseudocode. We should use one clear example (it's not a rocket surgery algorithm), but keep it to a language that is compilable and testable, not pseudocode. The clearest here at present seems to be the Python example. Andy Dingley (talk) 00:50, 18 November 2017 (UTC)[reply]

I wrote the C code sample and yes it's for base 36, but if you look more closely, you will find that it's very easy to make it universal by adding an unsigned argument 'base' to the function and to replace the occurrence of the value 36 by the variable 'base'. The character table must still hold all the characters up to the biggest base you want to use. The C version is fast not because it is optimized for a specific base, but because it directly fill a temporary static buffer big enough to hold the biggest conversion so there is not need to use any complex string operation but for copying the result to be returned. This optimization is possible in any language that allow direct character buffer manipulation. --213.221.150.139 (talk) 18:07, 23 October 2013 (UTC)[reply]

Wolfram Alpha

From the python example, type "convert AQF8AA0006EH base 36 to decimal" in the entry box (wolframalpha.com, essentially Mathematica) to return 1412823931503067241.--Billymac00 (talk) 03:46, 10 January 2014 (UTC)[reply]

Why not to use Base 96?

The digits can be written as:

Base 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	39	40	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95
Base 96	0	1	2	3	4	5	6	7	8	9	ᘔ	Ɛ	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S	T	U	V	W	X	Y	Z	!	"	#	$	%	&	'	(	)	*	+	,	-	.	/	:	;	<	=	>	?	@	`	a	b	c	d	e	f	g	h	i	j	k	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z	[	\	]	^	_	{	\|	}	~

Base 96

1/1=1

1/2=0.+

1/3=0.U

1/4=0.M

1/5=0.HHHHHH......

1/6=0.E

1/7=0.Bh;vP$Bh;vP$Bh;vP$......

1/8=0.A

...... -- 08:27, 10 April 2014‎ 140.113.136.218

140.113.136.218 -- There are 94 visible characters in ASCII (characters 33-126, not including 127) and 95 "printing" characters (32-126). This was the basis of the "Rot47" scheme mentioned on the "Rot13" article, and (with the precautionary omission of some characters) of the Ascii85 encoding scheme. Not sure that it's ever been used as a numeric base, or why people would want to... AnonMoos (talk) 09:44, 16 April 2014 (UTC)[reply]

Wouldn't characters like "+" and "=" make this very confusing? Double sharp (talk) 14:48, 29 January 2015 (UTC)[reply]

The java code is incorrect. negative values result in a minus sign in the base36 output. — Preceding unsigned comment added by 113.197.125.40 (talk) 05:40, 29 August 2014 (UTC)[reply]

Zero is missing

In the "conversion table" there should be a value for representing zeroes. So that it would range 0..35--213.121.207.158 (talk) 10:17, 15 December 2014 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Base36. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20081202234630/http://www.mediawiki.org/wiki/FileStore to http://www.mediawiki.org/wiki/FileStore

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:06, 27 October 2016 (UTC)[reply]

Enough exmples

I look forward to the conversion algorithm expressed in Plankalkul and Befunge and Brainfuck and other languages. COBOL, anyone? FORTRAN? Eniac assembler? TI58 programmable calculator? Difference engine? After the first 20 or 30 different examples, we're in danger of going blinid. --Wtshymanski (talk) 03:05, 7 February 2018 (UTC)[reply]

Agreed. Although of the rag-bag of samples, I'd prefer the Python one as an example, just because it was the cleanest implementation in terms of expressing the algorithm. The current C one is nasty because of C's need to explicitly manage pointers and null termination. Andy Dingley (talk) 03:48, 7 February 2018 (UTC)[reply]

We need another example in INTERCAL - I could probably fake it but I don't have a cat to walk on the keyboard. --Wtshymanski (talk) 04:23, 7 February 2018 (UTC)[reply]

For anyone curious visiting from the future, these are the examples referenced above.

- Jim Grisham (talk) 06:18, 14 November 2022 (UTC)[reply]

conversion

Currently the article says "Signed 32- and 64-bit integers will only hold at most 6 or 13 base-36 digits, respectively", which seems to me to be contradict the fact that many 13-digit base-36 integers -- such as "3Y2P0IJ32E8E8" and "ZZZYYYXXXWWWV" -- cannot be held in a 64-bit integer (whether signed or unsigned); although some 13-digit base-36 integers -- such as "1Y2P0IJ32E8E7" -- will fit in a mere 63 bits.

In the conversion routines, it's important to know what's the maximum number of base-36 digits that will be produced from some input, but I don't know if it's more relevant to have signed 64-bit integers, unsigned 64-bit integers, or etc.

How can we clarify this? --DavidCary (talk) 00:00, 3 November 2018 (UTC)[reply]

It would also be nice to say something about using Base36 to encode arbitrary binary strings instead of just integers. Is the input to be treated as a large integer written as a base-256 numeral? Is there some chunking done? What makes this a Binary-to-text encoding that's different from writing a base-10 numeral? — Preceding unsigned comment added by 222.153.155.22 (talk) 22:33, 2 August 2020 (UTC)[reply]