I had this exact situation at work when they shipped millions of devices with serial numbers, and didn't leave out any letter or number. Customers had so much trouble reading them accurately, I had to make a regex script that generated every possible typ0 permutation of what the customer said, and then it would list only matches from the factory database. From there, folks would try to correlate other info like dates to figure out what their real serial number probably was. It was a nightmare. Ironically several of the digits never changed, and some were just 0 1 or 2 to represent which factory made it, so there was no need for the entire character set in the first place. They seem to have been convinced we'd produce 8 quadrillion devices.
> They seem to have been convinced we'd produce 8 quadrillion devices.
While I'm not arguing that their decisions were wise nor that they shouldn't have been able to foresee and prevent the issues they caused you and your colleagues, I would add this one thought in response to the line quoted:
It's often either beneficial or at least considered beneficial to prevent business information leaking through serial numbers, the simplest example being that if you start labelling your products with 1, 2, 3.. and never deviate, then it's fairly easy to take a sample of not many serial numbers and estimate how high they go and therefore how many have been sold. Sometimes it can also be beneficial to make it harder to guess a valid serial number (eg it prevent customers from pretending to have a valid one to get a refund, or whatever).
Of course, even if you have these concerns and want to mitigate them, it doesn't prevent you from also taking steps to prevent difficulty reading the correct characters. If anything it should make them more aware of the potential issues you faced since it means someone is already actually thinking specifically about what system to use, as opposed to what likely happened in your case of someone spending 30 seconds going "we need serial numbers, using X digits means we'll never run out, job done".
> if you start labelling your products with 1, 2, 3.. and never deviate, then it's fairly easy to take a sample of not many serial numbers and estimate how high they go and therefore how many have been sold.
I bought some software many years back. The serial number had 6 or so digits in it. At one point, I contacted the developer for some other purpose, and pointed out that I had made my purchase as soon as I heard about the product. He told me I was the first customer, and that he had decided to make up long serial numbers to avoid this counting problem.
It also works great as a checksum. See IBAN numbers for a great example - they are all multiples of 97 plus 1 which makes accidental typos much less possible.
Encoding should also depend on the user. Base 32 (crockford & rfc 4648) has a nice unambiguous alphabet for compact representation and explanation of why. However if your users are speaking aloud you might want a word list representation, “TIDE ITCH SLOW REIN RULE MOT”, like s/key rfc 1751. DO NOT invent your own word lists; there are an infinite number of dragons lying in wait for idioms, homophones, dialects, etc. Dont be like me and unintentionally create a major incident like “wet clam butterfly.”
> However if your users are speaking aloud you might want a word list representation, “TIDE ITCH SLOW REIN RULE MOT”, like s/key rfc 1751. DO NOT invent your own word lists; there are an infinite number of dragons lying in wait for idioms, homophones
An unfortunate example. That's TIED HITCH SLOE REIGN RULE MOW? With only two parity bits, you can't even be sure this decoding is invalid.
RFC 1751 [0], from which this example comes, doesn't envisage the encoding being used in oral communication. Instead, it makes codes easier the user to "read, remember, and type in".
For oral transmission among professionals, sticking to the 26 upper case letters and relying on the NATO alphabet for encoding is a reasonable choice. Getting codes from untrained users in a lossy oral environment is still an unsolved problem.
My personal experience says that the most commonly understood phonetic alphabet in the US among laypeople is the 1946 ARRL alphabet using American first and last names, for example A as in Adam, N as in Nancy. NATO phonetic alphabet confuses almost everyone I've tried it on.
One day while sick, I distracted myself from being sick by writing up a silly module to do arithmetic in arbitrary bases. And, because it was easy I stuck it on CPAN. https://metacpan.org/pod/Math::Fleximal is the module.
Of all of the silly things I'd done, I would have sworn that this is the one that should never generate a support request. But it did! Why? Well I'd included a demonstration of how to turn hexadecimal into an alphanumeric code. And someone had the bright idea of using the same thing to turn long numbers into readable codes!
My module worked, but I was still a bit flabbergasted that THIS wound up in production somewhere!!
The author makes a point of avoiding letters that are hard to distinguish even when spelled out in handwriting, but the example table includes the number 7. I can not count the number of times I have found it hard to distinguish between someone's 7 and 1.
It helps if you draw a horizontal bar on the 7 but many don't, so you can never really be sure if a 7 is in fact a 1 with the serif or vice versa.
It might be based on the handwriting standards used in your country. Where I live we were taught at school to draw a horizontal bar on 7 and avoid the serif on 1:
No chance of confusion. This seems to have prompted some to add the serif to their 1 for stylistic reasons or whatever, since it's still distinguishable from 7 with a bar.
But then again people following older or newer conventions drop the bar from their 7:
This makes a singular 1 with sloppily drawn serif hard to distinguish from a 7 without horizontal bar unless you can also see how the same person draws the other digit in their style.
An alternative way, that makes the "1"s a bit less ambiguous, is to draw a bar at the bottom. So even if you put the serif on the 1, and write it sloppy, you still have the bar at the bottom.
My handwriting has always been pretty sloppy. My 9s come out like your 7s when I don't close the loop properly (I start at the bottom).
People confuse my lowercase r's for n's all the time too for a similar reason. Either I loop a little too much or I drag down the overhang so it basically is an n.
Suggestion: after "a longer ID with a lower chance of visual ambiguity" show how many characters that will be needed to have the same number of IDs as 53^8 using the 22 encoding.
I.e. for a given number of IDs, how many characters are needed in the 53 versus 22 encoding (people who are not good at math might assume it is more than twice as many).
The article also mentioned the difficult-to-distinguish aurally "B" (Bravo) and "P" (Papa).
But it did not mention the most similar-sounding pair "F" (Foxtrot) and "S" (Sierra), which are nearly indistinguishable.
While one could use the NATO/Aviation standard alphabet (Alpha, Bravo, Charlie, Delta...), unless you have a very specifically constrained customer base,it won't help much. Best to also avoid those combinations.
Definitely better to have a slightly longer ID_String and maximal ability to read and speak/hear the characters. It'll save FAR more time and aggravation.
There are many of these ambiguous pairs: B/P, F/S, D/T, M/N, Q/U, ...
The end-to-end transmission can get really bad when you combine several different filter stages, such as a speaker's mouth being injured or obscured, a narrow channel like telephone or radio, noise, and a listener's ear losing parts of the spectrum.
As the sound transmission gets worse, you can get more rhyming ambiguities. Effectively, the consonants are lost in a bad channel and only the vowels come through. In an American English accent, I think these are the groups corresponding to different vowel sounds: A/H/J/K, B/C/D/E/G/P/T/V/Z, I/Y, O, Q/U, F/L/M/N/S/X, R. "W" stands alone with multiple syllables.
Depending on the kind of transmission problem, these groups can start to split apart into smaller subgroups based on which of their sonic differences make it through to the listener.
> But it did not mention the most similar-sounding pair "F" (Foxtrot) and "S" (Sierra), which are nearly indistinguishable.
My family name begins with a 'F' and, indeed, I can't count the number of times where people write a 'S' instead. I've got invoices with a 'S' instead of a 'F'!
That's interesting. I've never encountered a 1 that looks like 7 in handwriting. Usually it's I and l that mess with 1. In what style of handwriting is 1 similar to 7? I'd imagine the top bar on 7 is a sufficient differentiator.
>I've never encountered a 1 that looks like 7 in handwriting. [...] In what style of handwriting is 1 similar to 7? I'd imagine the top bar on 7 is a sufficient differentiator.
Here's a deep link to someone in Germany writing down what visually looks like "77.5 :7:7" but his narration says it's actually "11.5 :1:1"
This just looks like obviously 11.5 :1:1 to me, the slant would be totally wrong for 7s. I had to check back your comment to be sure you were really talking about these 1s as looking like 7s :)
But this thread reminds me of when I lived in Canada for a while (coming from France) and I did misread numbers very often, which was totally unexpected to me. Yes, 7s and 1s looks very different between Canada (and the US I guess) and France (and probably the rest of Europe).
I haven't had this problem with Belgium though I'm not surprised if the standard here had been chosen to be the same as in France.
They might be obvious ones in the context of this one person. But they are trivially not obvious next to someone who writes one like "|" and then seven is just "|" with any sort of hat. Your slant heuristic immediately fails.
It's "obvious" because 7 is always slanted here. But I know it's not the case in North America and I have a good experience on how numbers can be misinterpreted, as I said.
I was just saying it was obvious to me and it even takes effort to see how they could be misinterpreted. But I know they can be.
in some countries' handwritings the digit one is not a vertical bar but it has a little ascending hook, like a digit seven turned vertical, but with a shorter roof.
so 'muricans mistook my German ones for sevens, all the time, and I had to force myself to write what looks like a pipe symbol vertical bar to me instead of my trusted one.
and to disambiguate, we cross the seven like a lower case eff or tee is crossed.
The handwriting of numbers and letters being confusing between countries is something that's easy to not think about until you've actually faced the issue multiple times.
I'm English, and I can't honestly remember which country it was that I've lived in (I think France...) where there were a couple of numbers that even after living there for a year I still wasn't confident reading when hand-written on things like café menus. And I don't think I would have thought of that being a systemic issue rather than just blaming an individual's handwriting before I lived there, despite having taken over 100 trips to France before moving to live there for a year.
I was born in Europe so I put a horizontal line midway through 7. But now I'm in Canada and nobody else does. It can be a really tiny angular difference between a 1 and a 7 for a lot of people! :)
Same experience, I wilfully switched my handwriting to American 1 (one) as a single vertical line with the European 7 (seven) having an horizontal line midway for disambiguation in a multicultural work environment.
Crossed 7's are fairly common among science majors in American universities. I also cross z's. Again, also fairly common among science majors. (Mine was chemistry.)
If you use both upper and lower case, you are likely to eventually be surprised by some third party system or protocol that is case insensitive. I even found a commercial system which allowed users to choose IDs with case sensitivity (iD and id being distinct) but if you query it for one which does not exist they do case insensitive matching and return the wrong data.
When I reported this bug they said it was for convenience!
I thought this was good neat UX: on the Nintendo Switch I was entering a serial number for some DLC, and the on-screen keyboard had all the ambiguous character keys disabled, which means that the serial numbers are generated without any ambiguous characters.
I'm not sure if this UX was built into the OS, or just part of the game I was playing (Mario + Rabbids Sparks of Hope).
KeepassXC (open source password manager application) uses colour to make passwords more readable. They use one color for each "class" of character: uppercase, lowercase, numbers, symbols, ...
This is a extremely simple idea, but especially with random passwords this helps a lot even if the font is already hyperlegible.
Bitwarden also uses an unambiguous font with 3 colors (default for letters, blue for numbers, red for symbols); I love it. It baffles me when any password-focused software allows itself to render characters in an ambiguous font without any color differentiation.
You can also add a list of exclusions easily in the KeepassXC password generator. I do because when you type in a long password on a TV remote, or similar interface, and then realise the l1|I were confused it's soooo0 infuriating.
I advocate for accessibility and inclusivity constantly, but not implementing additional measures which are helpful to most due to some not being able to make use of that one aid is not the way to go. Direct your hate elsewhere.
Yeah, why? Because the additional information layer benefits some people? Depending one your type of color-blindness and the choice of colors this might even be an improvement that works for color-blind people.
We are not talking about encoding information only in color (= bad idea), we are talking about encoding information that is already present additionally in the color. And if your app has accessability settings (it should) this would be a thing that you could switch on and off.
It's an additional layer on top of other ones like using a non-ambiguous font, large size display, alternating background shades, character index numbers under each character, etc.
So cool to read an article discussing a problem I run into on a regular basis.
Whenever I'm creating a 2FA backup on a piece of paper, anxiety hits me every time I cross over certain characters, o/0, v/u, 5/S, etc. I've come to add some fanciness to how I write these characters for this exact reason.
On "Phonetic similarity", reminds me of how I chose my wifi password. I wanted a common word with multiple consonants that a 3rd grader could spell, so I could share the password with a single phrase and have it be unambiguous. Ended up choosing "vacation".
> Whenever I'm creating a 2FA backup on a piece of paper, anxiety hits me every time I cross over certain characters, o/0, v/u, 5/S, etc. I've come to add some fanciness to how I write these characters for this exact reason.
My convention is that I put a dot '.' below every digit (this solves the 5/S, 0O, 8/B etc. issues [the actually problematic ones shall depend on your handwriting]).
If I'm really unsure, I add the NATO/aviation alphabet [1]. There's a 'U', I'll write 'Uniform' (in diagonal, starting from the 'U').
It only requires some discipline. I've done that since more than ten years now, never lost a single 2FA code.
[1] nitpicking about the actual difference between the NATO and aviation codes can safely be send to /dev/null
2fa backup codes? Yeah, I’d be surprised at people writing those out by hand. They’re long and gibberish, odds of an unnoticed error are high. I’d also be surprised at people typing them by hand (as a way to record them, not to input them) for similar reasons.
> They’re long and gibberish, odds of an unnoticed error are high.
That's why you "whitelist" those you wrote down and re-used with success: a little checkbox, which when checked means "Successfully re-initialized an authenticator with this 2FA?", works wonder.
A "dot" underneath a character means it's a number (so I'm sure not to mistake '5' with 'S', for example).
> That's why you "whitelist" those you wrote down and re-used with success: a little checkbox, which when checked means "Successfully re-initialized an authenticator with this 2FA?", works wonder.
I just bake the whitelisting into every 2FA code I handwrite. Instead of scanning the QR into the phone and then writing down the backup, I just start by writing down the backup, and then input it manually from the note into my phone. Once successfully used, I know the handwritten 2FA code is valid.
> A "dot" underneath a character means it's a number (so I'm sure not to mistake '5' with 'S', for example).
That one's good, I'll start doing that from now on! I also found writing letters partially in cursive to help too.
> My "paper 2FAs" then go to the bank, in a safe.
Yep same, I got a bank SD box back in 2017 during my first crypto wave. Have found the $100/yr to be incredibly useful. More recently I've created a sort of "defense in depth" for my passwords/codes. Least important things are available a button click away on Bitwarden Chrome extension, more important things are non-cloud-synced google-authenticator on my phone with 2FA backup in bank SD box. Most important things (i.e. crypto private keys) are sharded into pieces and distributed amongst multiple SD boxes.
I love conversations like this. These are arguably not the most cutting edge or exciting topics but hold a lot of significance and power to make life easier for humans (and machines too).
Some of these are areas of best practices that, when done really well -- people may not even notice it. That's an unfortunate fact of life that comes up often -- where the attention to detail and sincerity that people bring to the table often gets lumped under "obviously it should be that way, nothing special to see or applaud here".
> not only to avoid visually ambiguous characters, but also to avoid spelling words in common languages.
Or you should do the opposite - use real dates/words in ID and your visual confusion almost disappears (though there is a bunch of ambiguity here as well in similar pronunciation, so also not perfect). Humans aren't robots, so shouldn't be forced to read meaningless list of random letters
(example of geospatial system of coordinates based on that is what3words)
A few years ago I had to call an ambulance for someone (in the UK) and began giving coordinates, only to hear 'oh do you have what3words it's easier that way' which I found very surprising! I don't love the idea of a proprietary coordinate system either, companies come and go but normal coordinates are universally understood.
Or we could agree that that's ridiculous and not allow companies to own such things.
Free speech is a right. Interopability should be a right. Any infringement of those rights better gave a damned good reason. It's profitable isn't a good reason.
I think it’s also a good example of increasing computer dependency by ‘human centric’ design: I can quickly and manually sort through a bunch of packages with coordinates or pluscodes written on them with some sense of locality. What3Words is designed to give a sense of familiarity but require an API lookup for every single address.
Letters and numbers also translate directly in most languages, words don’t (take bow as an example. Is it when someone leans over, an archer’s weapon of choice, or a cutesy headpiece?), so the familiarity aspect is limited to people with a good grasp of English.
Its main feature is that it can be commercialized, unlike regular coordinate systems.
This post has some overlap with work I did a while back on a "coupon code" system that is optimised for users taking a code printed on paper and entering it into a web form. A number of measures were employed to avoid/correct transcription errors.
For years I thought that Doug McIlroy had a very odd name, until I watched some presentation on YouTube and first heard his name being pronounced – "ah, so that's an i and not a double L!"
It probably doesn't help much that both Lain and Lan are fairly famous fictional characters now (Serial Experiments Lain and al'Lan Mandragoran from Wheel of Time).
Funny story, I was named "Steven" and yet I've been called Steve my whole life, at my preference.
Recently I went through the process of changing my name legally, because I'd fallen into a bad habit of writing "Steve" when asked for my name on some documents, but then remembering my "official" name was "Steven" on others.
Having multiple IDs with different names, especially after moving to a new country, was just too much of a pain - for example my official residence permit name didn't match my passport name, which caused some fun at airports.
The first thing gifted was life, and though that was not bestowed with consent, it's one thing I'd argue for retaining as long as possible. Everything else is fair game to discard in service of making that life a good one.
I'm an American living in Germany. When I first arrived, the way Germans write the digit 1 surprised me. They write it with the upper hook thing very long, almost like a capital lambda (Λ), which sometimes makes 1 and A visually ambiguous. This isn't really a problem, just something funny about moving to a new country.
I use 1 with a long hook except when I write binary numbers where I use just a | for 1.
I have some other context dependent characters/letters.
I write small z like that in normal writing, but as a mathematical variable I write it as ƶ. (To disambiguate from 2.)
I write small t like † in normal writing, but as a mathematical variable I write it as t. (To disambiguate from + (plus).)
I write q like that in normal writing, but as a mathematical variable I write it with a stroke, which does not display on the iPhone, a ꝗ, a bit similar to a ɋ. (To disambiguate from a (ɑ).)
It’s all about disambiguation, and sometimes having different letter shapes for isolated characters.
This seems slightly flawed in that it completely removes all members of a similar set rather than normalizing to a single element per similar set.
Thus after normalization, '1lI' would become '111'. This allows you to add seven characters back to the author's code generation alphabet without re-introducing any ambiguity.
However, if you don't need them, I would remove them so that the user doesn't have to spend any time wondering which character it is. Even though you're processing them all after they type them and fixing them, the user has spent time and effort that they didn't need to, just picking which one it is.
IIRC, I chose to keep them when I did something like this, but I don't think I thought to accept the others and convert them automatically. That project is sunset now, so it's not an issue.
If you control the system for generating the codes and the system for verifying the codes (which is generally the case for these kinds of codes), then nobody needs to know you've done anything. It's the same normalizing to upper/lowercase characters when you parse a non-case sensitive code.
Years ago I worked support at an ISP who had usernames which was a 12 digit number. Most regular users and 1st level support do no know the NATO phonetic alphabet. An easy trick is trick is then to read back the number for confirmation but use another grouping of digits. Most users read 1 digit at a time so I would read back 2. One-Two becomes twelve. If they used 2 digits I would for ease use 3 rather then 1. This is a very easy way to do a fake "checksumming" regular people.
Tangent: All number started with 12 which in effect made them 10 digits. They worked together with a banking system and the bank folks thought 10 digits was not secure enough so they complied and added 12 in front of everything.
> Tangent: All number started with 12 which in effect made them 10 digits. They worked together with a banking system and the bank folks thought 10 digits was not secure enough so they complied and added 12 in front of everything.
I have realized that there is a big design space here, as I recently did a write-up of my take, Id30. 30 bits of information encoded base 32 into six chars, eg bpv3uq, zvaec2 or rfmbyz, with some handling of ambiguous chars on decoding.
Related reading, from the font designer's side: “Oh, oh, zero!” by Charles Bigelow (of Bigelow and Holmes, makers of typefaces like Lucida and Wingdings), published in TUGboat the journal of the TeX users group: https://tug.org/TUGboat/tb34-2/tb107bigelow-zero.pdf
> Related reading, from the font designer's side: “Oh, oh, zero!” by Charles Bigelow
I don't know. People tend to use the letter 'O' a lot. And people tend to use zero '0' a lot too.
Who gives a fuck about "Oh"? I mean, seriously, which percentage of articles, blog, PDFs, webpages, products etc. throughout the world have have 'O' and '0' that can be mistaken one for another? And which percentage have "Oh"?
When was the last time a user had to read a product ID over the phone and did misread big O / "Oh" for 0?
I don't even think there was a last time, because nobody is using "Oh" in identifiers.
While, on the other hand, it's perfectly fine to use a slashed-zero for zero, to be sure nobody mistakes it for the letter 'O'.
So basically: your link and TFA aren't that related.
I'm not sure I understand your comment, because at first glance it seems to be making a distinction between "Oh" and "O", when Bigelow's article is using "Oh" as the name/vocalization of the letter 'O' (as should be clear from the very first sentence, even if not the title).
So, assuming (still not clear from your comment) that you do understand "oh" to mean the letter 'O', as intended, still your comment is surprising, because some of your own other comments talk about O/0, and the submitted post here too starts with that very example:
> What are visually ambiguous characters?
> O / 0 - The letter O and the number 0 can look very similar
So surely the article is relevant to (at least the first example of) the post? I admit it goes much deeper into just this one example, and only a bit into other examples like 1/l/I and 2/Z or 5/S, but still it's relevant and of value as a representative example I think.
An alternative would be to print IDs using https://en.wikipedia.org/wiki/FE-Schrift, which was specifically designed to make normally similar characters to look different.
> In some cases, you might also want to avoid characters that sound similar when spoken. For example, b and p can sound similar when spoken out loud. This can be especially important in situations where IDs are communicated verbally.
In many cases these kinds of IDs are just an encoding of a ground-truth that is a big integer or a sequence of bytes, and that mean we don't have to use ASCII-character granularity, we can also use words.
True, that creates a certain cultural bias for wherever you get the words from, but it opens up new possibilities for error correction and detection, both by the computer and also by the humans transcribing things.
I'll happily boycott that for-profit company which is masquerading as a public utility, but charging money and going after anyone who reverse engineers what words are what locations.
This is exactly the sort of thing that shouldn't be a private company, just like Lat/Lon coordinates and street addresses are effectively public domain, any suitable replacement for lat/lon should also be public domain.
Yeah, ideally the dictionary first would undergo rather rigorous pruning based on things like phonetic similarity or how easily a typo might move between two valid words.
That scoring/clustering process makes for interesting problems in their own right, especially if one throws accents into the mix.
The problem with words is that their encoding density is much lower, so it requires more space to store. Suppose you create an alphabet A that consists of the N most common English words. Then, what might be Q characters in base 58 would instead require Q*ln(58)/ln(N)*((avg word length in A)+1)-1 characters. For N=1000 and assuming that the average word length is 5, this gives a factor of ~3.5x increase in storage space required (e.g. a 20 character base-58 ID would map to a ~70 character string of words).
That is true. But is it really a storage problem? Could you not store in whatever base-N arithmetic that has high encoding density, and "just" use the words for display/printing and such?
Probably it is more a problem of restricting the range of representable numbers because users are unable to handle pages over pages of random words...
You then have to currate a list of words which also don't have similar sounds, are comprised of subwords, aren't offensive, or other gotchas.
I don't think words work well for codes that aren't meant to memorized. They make it harder to currate a unambiguous list since that list needs to be several orders of magnitude larger and the ambiguity can accent dependent. Of course, if memorization may be needed, then that is effort may be worthwhile.
Error detection with codes isn't hard, that's why checksums exist.
Thanks, that's a neat resource to making hexadecimal numbers for memorizable and easier to transmit phonetically with some built in error checking from the odd/even list alternation.
However, for the core purpose of the phonetic transmission, it seems needlessly verbose and cumbersome. The short wordlist combines with some fairly long component words to make the phonetic representation unnecessarily long. Additionally, I'm not super into some of the fairly obscure names and words included on that list. If I don't need memorability and hexadecimal atomicity, it doesn't seem worth using.
On linux you can use Theodore Ts'o pwgen tool with the -B arg.
-B, --ambiguous
Don't use characters that could be confused by the user when printed, such as 'l' and '1', or '0' or 'O'. This reduces the number of possible passwords significantly, and as such reduces the quality of the passwords. It may be useful for users who have bad vision, but in general use of this option is not recommended.
Doesn't help when you have to match the person's name and they have these characters in them. My name contains the letter "o" and I once had a lot of trouble getting something done at the bank. Multiple staff had to crowd around the computer to figure it out. Eventually somebody discovered that when I had opened my account, that o had been entered as a 0 for some reason and the font they were using, also for printing, showed them looking almost identical.
The Latin/English alphabet is common but not universal. I believe this challenge is why TOTP codes use Arabic numerals. The user's keyboard can type these reasonably. Spoken is always a challenge. Even an English speaking audience will pronounce "0" as zero, oh, or zed.
Term: ASCII digits
Example: 0123456789 U+0030..U+0039
Explanation/Description:
Commonly used with Latin, Greek, Cyrillic and many other scripts, including some non-European scripts. Used in alternation with native digits in scripts that have them. (Some scripts with native digits make only limited use of ASCII digits.) Infrequently used in many of the remaining scripts.
Synonyms: Western digits, Latin digits, European digits
> European Digits. Forms of decimal digits first used in Europe and now used worldwide. Historically, these digits were derived from the Arabic digits; they are sometimes called “Arabic numerals,” but this nomenclature leads to confusion with the real Arabic-Indic digits. Also called "Western digits" and "Latin digits." See Terminology for Digits for additional information on terminology related to digits.
Well sure, but the previous poster was making a proposal ("I think"), and just doing a link dump implies ignorance, which fairly obviously isn't the case.
I think anyone who has dealt with both Arabic numerals (as used in Europe) and Arabic numerals (as used in parts of the Arabian world) feels the naming is unfortunate. Arguably this is not the best place to bring that up, but I certainly stopped using "Arabic numerals" after working with some i18n code which supported both Arabic and Arabic numerals.
Maybe not the best names, but I've taken to calling them Western Arabic, Arabic Arabic, and Persian or Urdu Arabic. I typically only deal with the Unicode representation, so the differences between Persian and Urdu numerals are invisible to me (but very visible if you display them with the wrong language context for the viewer!)
In handwriting there is a difference between European and American. In Europe we don't really have problem with 1 vs 7 or g vs 9. But our nines and ones do look like gs and sevens to Americans.
I heard an American making a joke that
"I have gg problems but European handwriting ain't 7 of them."
A few years ago, I created a system that generates a serial number from a prefix and a 32-bit unsigned integer and fixes up this kind of input error when passing the serial.
UuidExtensions[1], a C# library, has a way of generating / encoding IDs that has several useful properties:
1. IDs can be generated anywhere (client-side, server-side, etc.) and are still unique
2. IDs are ordered by time
3. IDs don't use L and O because those can be confused for other characters
Modern bitcoin addresses use a base-32 character set that leaves out some of the most ambiguous pairs and also permutes the address ordering so that the most visually similar remaining characters produce single bit errors which are better handled by the addresses error detecting (and potentially correcting) code.
“Oh By”[1], The universal shortener, has had protections for this built in from the very beginning.
Since the whole point is the ability to convey a message in the physical world end with chalk or pencil or whatever – we needed to make sure that characters were unambiguous.
So there are no zeros or ‘o’ characters or ones or ‘l’ characters… I think there were one or two other rules that govern this but I can’t think of them right now…
Honestly, stuff like this is why I stick with (case-insensitive) hexadecimal for user-facing IDs. I find hex to be the sweet spot between "decently sized alphabet to keep ID lengths down" and "easy to read, communicate, and enter manually". It's also fairly resistant to accidentally generating IDs which will offend your users (unless your users are 1337-speaking time-traveling pre-teens from 2002 who are going to snicker at "b00b5"), which is a nice perk.
Also do not use the same character repeated in a "long" sequence. I hate this with IBANs. Too often there's something like '000000' right in the middle of an IBAN and in case copy and paste is not possible I end up counting the number of zeroes at least thrice. Groups of four characters separated by spaces would help in this case but that's another topic.
I did my PhD on (malicious) visual impersonation of domain names using many of the techniques described here. There are many references to other visual doppelganger techniques included in my paper here: https://par.nsf.gov/servlets/purl/10256904
My research focused solely on the .com domain name space, so our character set was limited.
An approach we are trying is speakable IDs. Three characters for the type of thing, then four random words from a list of clean words with 5 characters:
You'll want to be careful to consider homophones while also taking accents into account. E.g. if your dictionary contains "deary", it probably shouldn't also contain "dairy".
That was my first thought, but the section on case sensitivity already discussed the impact of a reduced alphabet and pointed out adding more characters takes care of that quickly. So I assume the reason is something else.
And TFA doesn't even mention Unicode, scripts, ASCII, Latin, nothing. As you can imagine it all gets much worse with Unicode (though through no fault of the Unicode Consortium). See Unicode TR#39 [0].
> However, as the number of members in the set increases, the number of possible IDs increases exponentially.
Case-sensitive: 53^8 = 62,259,690,411,361
Case-insensitive: 22^8 = 54,875,873,536
Nitpick, but isn't this polynomial to the members of the set?
This is why longer password are more efficient than complex passwords: to gain the same security effect of doubling the password length you would need to square the alphabet
You've the proper definitions but are missing the context. An exponential with larger base still has an exponential multiplicative difference compared to an exponential with a smaller base.
We're comparing the growth rate of of two exponentials representing variable-length identifiers. We're not looking at a constant-length identifier (which is what you're doing with only looking at a^n). Notice the context of where exponential is used in the article: we are changing n from 5 to 8.
A friend told me about how his work had some senior IT mgrs, who'd clearly been playing with their iPhones too long, decide that the firm shouldn't use Ids at all any more, and started pushing this without consulting the business, even though it was totally inappropriate given how widely they were needed... Caused mayhem and needles arguments!
I have one on my passport number. I still dont know which it is so I alternate. Hasn't been a problem to anyone yet when registering for planes and crossing borders: the picture is clear, it can be both lol
Out of curiosity, anyone knows why would this post be removed from the front page?
I was excited see that the post is getting engagement. I saw it in 3 position. Then checked an hour later and it is nowhere to be seen.
I am assuming this is some sort of opportunistic algorithm at play that gives a chance to a post, but removes it if it is not performing, but curious if anyone has more details.
HN submissions tend to be in the front page when they receive a bit of early votes within (roughly) the first hour, but they disappear rather quickly without further votes. Given that this submission was only 3 hours old when you posted this comment, it is quite expectable. (For the record it's now in the fifth place, suggesting that it has eventually received enough votes to stay in the front page later.)
reply