h a l f b a k e r yProfessional croissant on closed course. Do not attempt.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I dont think an idea can be any more simple. By calculating a check digit to add to the end of your existing phone number, and having your phone check for it upon receiving a call, you could reduce the likelihood of ever being bothered by a wrong number!
Old system:
You want 123-4566.You dial 123-4567.
Wrong number. Tedious.
New system:
New phone number, including check digit, is 123-45669.
(1+2+3+4+5+6+6 = 27,
2+7 = 9)
Your phone will still receive the wrong number, as the `phone number` part of the composite `phone number and check digit` number is still uniquely identifying your phone. But it wouldn`t ring unless the check digit is also correct.
On a cynical note: this system could have been implemented in the first place, but would have the effect of 1)limiting the available number of combinations of digits by a factor of 10, which may be an expensive factor in designing exchanges etc, and 2)lost revenue through wrong numbers (phone calls often being rounded up to the nearest minute).
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
This idea is good but probably it would have been too difficult or expensive to implement on the first phones intended for user's to dial themselves. |
|
| |
BTW what would you suggest for international dialling? |
|
| |
Aristotle: It may have been expensive to implement, but if done from the start, the user wouldnt have known that there was a check digit system in place. Ie, whether their number was 123-4567, or 123-456 and a check digit of 7. It would have been transparent! |
|
| |
Re international calls: Your phone would only be checking the last digit. It wouldnt matter how long the number was. You could have dialled, from the states: |
|
| |
00 1 20 8123 4567(8)
or
8123 4567(8) |
|
| |
to get to a number in outer london, for example. Ie. the check digit would be calculated on the phone number+local area code, but not the national/international code. |
|
| |
But this depends on how the phone system works - information to which I am not privy! I know that extra numbers can be dialled after a valid one, and just ignored, or treated as the first digit of a voicemail system, so it could be implemented on just a few phones, not the whole system; anyone forgetting the check-digit just wouldnt get through, or would perhaps be prompted for it (they could calculate it on the spot).
Or perhaps the idea could be extended to a more-than-one digit password, if you were getting bugged by nuisance calls, or wanted to only be woken by a loved one or whatever. |
|
| |
If you have an algorithm for determining the length of the phone number, this idea could be implemented within a phone without the cooperation of the phone system as a whole. That is, it would be possible to make phones that require a check digit before attempting to place a call. |
|
| |
Different check digits on the same number could be useful as well. May be good for routing calls to a certain family member. Could be used to track where marketers get your number. User programmable, variable telephone check digits. |
|
| |
You can't have different check digits on the same number; the check digit is a function of the number. |
|
| |
Actually angel, why not just vary the algorithm used to generate the check digit? Then the possibilities are infinite. |
|
| |
Merely adding digits to produce a check digit does not catch transposition errors.
Try this: if there are 7 digits, ABCDEFG, the check digit is the last digit of 40-A+B-C+D-E+F-G. The "40" is to keep it from going negative. |
|
| |
//Merely adding digits to produce a check digit does not catch transposition errors//
No, that's why check digits don't work like that. |
|
| |
The check digit shouldn't really create problems on the size of the exchages -- the digit would effectively be discarded once it validates the number. Also, if you use a coding scheme ABCDEFG for the number, a check digit of mod9(3*(A+2*C+3*E+4*G)+B+2*D+3*E), will catch transpositons and most skip transpositions. |
|
| |
Or you could just make people enter the phone number twice. Sure it's more work, but no extra digits to remember. Kind of like is often used in web forms (as if we don't all copy and paste when they ask us to enter our e-mail again to verify). |
|
| |
i don't know about everyone else, but most of my wrong numbers aren't simply slips of the finger, but errors of miscommunication. Therefore, if Jane gives me her "digits", being 123-4567, but i accidentally write down 123-4566, and when i get home to call her, i figure the check digit as 9, it still completes my call to phone number 123-4566. Check digits only work in bar codes if the bar code was printed correctly by the manufacturer of the product. |
|
| |
//Also, if you use a coding scheme ABCDEFG for the number, a check digit of mod9(3*(A+2*C+3*E+4*G)+B+2*D+3*E), will catch transpositons and most skip transpositions.// |
|
| |
Assuming you meant 3*F at the end (otherwise F wouldn't be used anywhere), transpositions between F and G would go undetected, and changes to E would go unnoticed). And on any number, substituting a zero for a nine would have no effect. |
|
| |
Doing things mod10 would be a little better, but even there problems exist. The ISBN's mod-11 check digit is pretty good, but being mod-11 poses its own problems. |
|
| |
BTW, I wonder why the particular coding of bars and spaces in UPC was chosen over the much-simpler I2of5? Both code formats use 14 'pixels' to code two digits, but I2of5 only requires distinguishing two widths of bars and spaces (UPC uses four). |
|
| |