This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
|
|
The part about the 32-sided polygon sounds like pure weapons-grade balonium to me. Anyone for killing it? -- tcsetattr ( talk / contribs) 21:08, 24 February 2008 (UTC)
In reality, the only interesting thing one can say about this base is its use in Base32. In my opinion, the article Base 32 should be "merge" to this article in accordance with Wikipedia:Notability (numbers). QQ ( talk) 11:19, 23 May 2008 (UTC)
This does not seem a good idea. The two subjects, Base 32 and Base32 encoding, are very different. Merging the two would only result in replacing two clear and concise articles with a single long and confusing article. —Preceding unsigned comment added by 194.221.133.226 ( talk) 11:26, 26 June 2008 (UTC)
This is incredibly un-noteworthy original research, why is this even in here? Vote remove. — Preceding unsigned comment added by 81.129.57.239 ( talk) 22:59, 16 July 2013 (UTC)
Shouldn't
padding =
be better placed at the bottom of the last column in the table? Jidanni ( talk) 03:41, 8 April 2020 (UTC)
I was trying to identify the variant this coding (see element "base32 ...") uses but it appears to be none of the listed one. 50.68.41.27 ( talk) 23:28, 7 January 2022 (UTC)
Ever since this edit the article has mixed a bulleted RFC in with a footnoted reflist. I'm not sure that's ideal. ReadOnlyAccount ( talk) 06:49, 24 October 2023 (UTC)
If this edit is correct, then it would seem that entire section possibly doesn't even belong here, since this article does not seem to be about any and all thirty-something bases, but only about base-32. ReadOnlyAccount ( talk) 13:50, 24 October 2023 (UTC)
PS: In other words, this article is about the duotrigesimal numeral system and its various notations, not about the untrigesimal numeral system. (The latter is mentioned on https://en.wiktionary.org/wiki/Appendix:Number_bases.) — Preceding unsigned comment added by ReadOnlyAccount ( talk • contribs) 13:53, 24 October 2023 (UTC)
The example that was added via
these two
edits seems not very good. First of all, it says it's "using the previously described 32-character set", but what's previously described in the lede is "using (...) the twenty-two upper-case letters A–V and the digits 0-9", which is base32hex, and that is not what this example actually uses, since it contains the letters W, Y and Z, which are not in base32hex. (NB: It seems
this edit is to blame for the mismatch.) Secondly, this example string appears to be RFC 4648 Base32 encoded, but decoding the ciphertext string as that yields hex/binary data, not just a simple (and more easily understandable) text string. It appears to be a somewhat random bunch of bytes, so what does that tell the reader? Really not much. (I mean, if you can make sense of 08 0b 80 91 02 cc a4 21 c8 32 f9 4b 0c f7 a0 94 06 5d c9 95 f2 96 2b 6c ce 2c b3 5b 2f 00 88 91 cf 84 c5 df
, be my guest.) Worse, the preceding sentence reads: "The rest of this article discusses the use of Base32 for representing byte strings, not unsigned integer numbers, similar to the way
Base64 works." Depending on what is meant by "byte strings"—and the language is fuzzy—a
reasonable reader could expect text strings (made from bytes!), which at least this example doesn't seem to encode. Besides, any byte could be interpreted as a signed or unsigned number, so the sentence may be more of a diary entry of a light bulb going on above its author's head, without being similarly illuminating to anyone else. Also, providing only the encoded string without the corresponding decoded form makes the example a lot less useful, especially in an encyclopædic context. A decent example would use text only, and provide both the plaintext and ciphertext. Or, if you really needed to demonstrate the encoding of binary data, you would include better context as to what exactly that binary data represents. The context provided here is that the example string is an "
IPFS CIDv1 in Base32 upper-case encoding". That's great. What's a CIDv1? Oh, look: Even the linked article doesn't answer that question. And even disregarding the fact that this is a bit of an unsolved riddle, why have an example in the lede at all? Especially since despite the argument from authority provided by the RFCs, it's not yet clear which duotrigesimal notation will become universally accepted (if any). In the case of the hexadecimal numeral system, it also used to be the case that people had different ideas as to notation early on, but there the dust has long since settled, and despite some differences on ancillary details like 0x2F vs 2Fh, fundamentally just about everybody agrees how hexadecimal is written. The same cannot be said for duotrigesimal. Far from everybody agrees how to write base-32, and it's not even clear whether the RFC's base32 or base32hex will ultimately win out over the other. That makes putting an example in the lede even worse, because now you're
picking favourites. —
ReadOnlyAccount (
talk)
17:57, 24 October 2023 (UTC)
First, see above for my earlier critique of the sentence in question (in the lede).
Secondly, note that it can also be parsed one of two different ways (parentheses added):
ReadOnlyAccount ( talk) 18:34, 24 October 2023 (UTC)
At the peril of offending fans of Gertrude Stein, the phrasing "Base32 is the base-32 numeral system" strikes me as particularly inelegant. The problem is, it was introduced in the context of a not well-settled low-heat edit direction dispute over whether this page is for the numeral system, computer implementations, or both (see the rest of this Talk page). Anyway, this edit is to blame for the near-tautology. ReadOnlyAccount ( talk) 18:17, 25 October 2023 (UTC)
It's probably not ideal that of the six major encoding tables currently in the article, two are horizontally arranged while the other four are vertically arranged, and there also are some subtle and unnecessary differences between the respective tables' layouts, etc. Is there a table format everybody can agree on?
—
ReadOnlyAccount (
talk)
04:25, 27 October 2023 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
|
|
The part about the 32-sided polygon sounds like pure weapons-grade balonium to me. Anyone for killing it? -- tcsetattr ( talk / contribs) 21:08, 24 February 2008 (UTC)
In reality, the only interesting thing one can say about this base is its use in Base32. In my opinion, the article Base 32 should be "merge" to this article in accordance with Wikipedia:Notability (numbers). QQ ( talk) 11:19, 23 May 2008 (UTC)
This does not seem a good idea. The two subjects, Base 32 and Base32 encoding, are very different. Merging the two would only result in replacing two clear and concise articles with a single long and confusing article. —Preceding unsigned comment added by 194.221.133.226 ( talk) 11:26, 26 June 2008 (UTC)
This is incredibly un-noteworthy original research, why is this even in here? Vote remove. — Preceding unsigned comment added by 81.129.57.239 ( talk) 22:59, 16 July 2013 (UTC)
Shouldn't
padding =
be better placed at the bottom of the last column in the table? Jidanni ( talk) 03:41, 8 April 2020 (UTC)
I was trying to identify the variant this coding (see element "base32 ...") uses but it appears to be none of the listed one. 50.68.41.27 ( talk) 23:28, 7 January 2022 (UTC)
Ever since this edit the article has mixed a bulleted RFC in with a footnoted reflist. I'm not sure that's ideal. ReadOnlyAccount ( talk) 06:49, 24 October 2023 (UTC)
If this edit is correct, then it would seem that entire section possibly doesn't even belong here, since this article does not seem to be about any and all thirty-something bases, but only about base-32. ReadOnlyAccount ( talk) 13:50, 24 October 2023 (UTC)
PS: In other words, this article is about the duotrigesimal numeral system and its various notations, not about the untrigesimal numeral system. (The latter is mentioned on https://en.wiktionary.org/wiki/Appendix:Number_bases.) — Preceding unsigned comment added by ReadOnlyAccount ( talk • contribs) 13:53, 24 October 2023 (UTC)
The example that was added via
these two
edits seems not very good. First of all, it says it's "using the previously described 32-character set", but what's previously described in the lede is "using (...) the twenty-two upper-case letters A–V and the digits 0-9", which is base32hex, and that is not what this example actually uses, since it contains the letters W, Y and Z, which are not in base32hex. (NB: It seems
this edit is to blame for the mismatch.) Secondly, this example string appears to be RFC 4648 Base32 encoded, but decoding the ciphertext string as that yields hex/binary data, not just a simple (and more easily understandable) text string. It appears to be a somewhat random bunch of bytes, so what does that tell the reader? Really not much. (I mean, if you can make sense of 08 0b 80 91 02 cc a4 21 c8 32 f9 4b 0c f7 a0 94 06 5d c9 95 f2 96 2b 6c ce 2c b3 5b 2f 00 88 91 cf 84 c5 df
, be my guest.) Worse, the preceding sentence reads: "The rest of this article discusses the use of Base32 for representing byte strings, not unsigned integer numbers, similar to the way
Base64 works." Depending on what is meant by "byte strings"—and the language is fuzzy—a
reasonable reader could expect text strings (made from bytes!), which at least this example doesn't seem to encode. Besides, any byte could be interpreted as a signed or unsigned number, so the sentence may be more of a diary entry of a light bulb going on above its author's head, without being similarly illuminating to anyone else. Also, providing only the encoded string without the corresponding decoded form makes the example a lot less useful, especially in an encyclopædic context. A decent example would use text only, and provide both the plaintext and ciphertext. Or, if you really needed to demonstrate the encoding of binary data, you would include better context as to what exactly that binary data represents. The context provided here is that the example string is an "
IPFS CIDv1 in Base32 upper-case encoding". That's great. What's a CIDv1? Oh, look: Even the linked article doesn't answer that question. And even disregarding the fact that this is a bit of an unsolved riddle, why have an example in the lede at all? Especially since despite the argument from authority provided by the RFCs, it's not yet clear which duotrigesimal notation will become universally accepted (if any). In the case of the hexadecimal numeral system, it also used to be the case that people had different ideas as to notation early on, but there the dust has long since settled, and despite some differences on ancillary details like 0x2F vs 2Fh, fundamentally just about everybody agrees how hexadecimal is written. The same cannot be said for duotrigesimal. Far from everybody agrees how to write base-32, and it's not even clear whether the RFC's base32 or base32hex will ultimately win out over the other. That makes putting an example in the lede even worse, because now you're
picking favourites. —
ReadOnlyAccount (
talk)
17:57, 24 October 2023 (UTC)
First, see above for my earlier critique of the sentence in question (in the lede).
Secondly, note that it can also be parsed one of two different ways (parentheses added):
ReadOnlyAccount ( talk) 18:34, 24 October 2023 (UTC)
At the peril of offending fans of Gertrude Stein, the phrasing "Base32 is the base-32 numeral system" strikes me as particularly inelegant. The problem is, it was introduced in the context of a not well-settled low-heat edit direction dispute over whether this page is for the numeral system, computer implementations, or both (see the rest of this Talk page). Anyway, this edit is to blame for the near-tautology. ReadOnlyAccount ( talk) 18:17, 25 October 2023 (UTC)
It's probably not ideal that of the six major encoding tables currently in the article, two are horizontally arranged while the other four are vertically arranged, and there also are some subtle and unnecessary differences between the respective tables' layouts, etc. Is there a table format everybody can agree on?
—
ReadOnlyAccount (
talk)
04:25, 27 October 2023 (UTC)