Talk:Base32/Archive 1

Archive 1

Cyclic Redundancy Check (CRC) for a Base32 string

Just wondered if any CRC experts could provide some insight into what the best CRC scheme would be to check for errors in a user-inputted Base32 string. The algorithms listed under [Crc32] are optimised for checking for individual bit errors rather than errors on a 5-bit block (i.e. the user typed the wrong Base32 character). —Preceding unsigned comment added by 86.14.113.26 (talk) 00:16, 11 June 2009 (UTC)

A n-bit CRC will detect any single error burst not longer than n bits. So if you have some arbitrary bits, append 32 bits of CRC32 to the end, and then encode the resulting packet with base32, the receiver is guaranteed to detect that an error occurred as long as there are at most 4 characters between the first wrong Base32 and the last wrong Base32 digit. (More than that, and the CRC detects most errors, but not all).

Reed–Solomon error correction is an algorithm optimized for checking for symbol errors -- such as typing the wrong Base32 character. If multiple bits in a Reed-Solomon symbol are corrupted, it only counts as a single error. The number of check symbols C is a design parameter. If the locations of the errors are not known in advance, then a Reed-Solomon code can correct up to C/2 mistyped characters. A Base32 Reed-Solomon encoder would send data as encoded blocks of up to 31 Base32 symbols per block. For example, if you choose C = 8 check digits, you can send up to 23 characters of arbitrary data followed by 8 Reed-Solomon check digits per block, and the receiver could not only detect but also automatically correct up to 4 mistyped digits anywhere in the block. And the receiver is guaranteed to detect that an error occurred as long as there are at most 8 errors anywhere in the block. (More than that, and a Reed-Solomon receiver detects most errors, but not all).

--DavidCary (talk) 05:03, 26 June 2014 (UTC)

Finger counting

I have removed this recent addition from the article:

Base32 can also be used for counting binary, and then each hand represents a digit. With one hand you can count to 31 and with two you can count to 1023. This is how I do it: Since it's hard to keep down the ring finger while having the little and middle finger up, I figured out that keeping them all down (except the thumb), and to indicate that one finger is down, you touch the pawn. The thumb is kept right up, apart from the hand and index finger, and to indicate it's down you touch the index finger.

If any other sources describe this as a procedure used by more people than the author, this may be relevant, though I think it would be more so at Binary. As it stands, unsourced, I don't think it belongs here.--Niels Ø 11:50, 7 August 2006 (UTC)

I do that, too! Of course that doesn't mean that it should be in the article; it's certainly WP:OR, and thus unfortunatly no material for Wikipedia. But since we're talking about it here, I'd like to relate my way of doing it: I rest my hand on a surface such as a table or my thigh. Thumb represents the lowest digit. Touching the surface means 1. I start counting with 0 by moving all fingers up. I use that method of counting when I'm analyzing music; it's amazing how many arrangements fit to the binary scheme - each finger corresponds to a certain level of change or repetition in the music. — Sebastian 19:24, 10 May 2007 (UTC)    (I stopped watching this page. If you would like to continue the talk, please do so here and ping me.)

Closest encoding relation

"Its closest encoding relation is Base30 that is used by the Natural Area Code." What does this even mean? In what sense is base 32 closely related to base 30? Is it just because 30 is close to 32? 31 and 33 are closer. Do they not could because they're not commonly used? So, what if 30 is close to 32 in terms of the difference between them? Isn't it more important to consider the factors? 30 = 2 × 3 × 5 but 32 = 2⁵ thus base 2, base 4, base 8, base 16, base 64, base 128, etc. are more closely related than base 30. Jimp 01:20, 6 October 2015 (UTC)

Looking at Natural Area Code, I think it's because they both assign a custom combination of letters and numbers to their numerical ranges and they both exclude characters that could be confused with each other. What differentiates these two from other bases like base-31 and base-33 is that they are encodings; base-16 (hexadecimal) just indiscriminately converts to a different radix. Of course you could argue its more analogous to Base64, but that has some extra rules related to padding that the former two don't have and also includes the full alphabet. "Closest to" is a subjective phrase anyway. Opencooper (talk) 11:07, 6 October 2015 (UTC)

Perhaps that could be explained in the article. I'm not about to try explain it, I'm not familiar with these encoding systems. Jimp 06:27, 15 October 2015 (UTC)

Agreed, considering that it's the second sentence in the lead a reader might assume the comparison is important. I think a general "Comparison to other encodings" subsection might be appropriate considering what we mentioned. The lead needs attention in general to better summarize the article points as well as the rest of the article considering half of it is on alternative versions. (I might not get to it personally though) Opencooper (talk) 10:55, 15 October 2015 (UTC)