• Jay (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Jay:
    foo:
    The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.
    That seems rather pointless. If all the numbers start with a zero, then the zero is superfluous and could be left off.
    That's the reason why international calls omit that zero between the country code and the remainder of the city code. However, most calls are domestic and the zero is needed to indicate that a full number is being dialled instead of a local (intra-city) number.

    Also, historically, long distance calls even within a single country were considerably more expensive than local (intra-city) calls. Also phones were dialled using dials instead of push buttons. So if a phone were offered for public use by a corner store or other public facing proprietor, they would put a lock in the 9 position in the dial. Digits 1 to 9 could be dialled but 0 couldn't be dialled (except by historical phone phreaks of course). Phone numbers didn't have any 0 digits except the first digit of the city code. So local calls could be dialled but long distance calls could not be dialled.

    Eventually pay phones replaced public use of phones provided by corner stores etc. (and later pay phones became obsolete because everyone except me carries a cell phone but let's not get ahead of ourselves), local numbers started to include embedded 0's the same as other digits, and the costs of calls were computed by some newfangled kind of calculating machine so it was no longer necessary to lock out the riffraff from dialling an initial 0.

    I'm not sure if you're agreeing with the original poster or not.

    I think the real answer here is: No, there is no country where all phone numbers start with "0". There may be countries where all DOMESTIC numbers start with "0", or some other subset, so that the zero indicates which subset. But then of course the whole point of the zero is that it is not superfluous, it is telling you that a certain subset applies, and a number beginning with a non-zero indicates that a different subset applies.

    My post on this was not intended to make fun of the phone system, but of the poster's statement about the phone system.

  • Jay (unregistered) in reply to Gurth
    Gurth:
    Jay:
    Back in the early days of computers (I don't think so much today), many people would type the letter oh instead of zero and the letter el instead of one, which of course would then screw up numeric inputs. Manuals would routinely lecture users not to do this. Just because it looks right on a typewriter, it doesn't work on the computer, etc.
    Many typewriters didn't have a 1 and/or a 0 on the keyboard, because a lowercase l and uppercase O would look much the same, and that way the keys normally used for the 1 and/or 0 could be used for other symbols for which there would otherwise be no room. Anybody used to a typewriter would naturally type the same way on a computer, I'd expect.

    Exactly. When people went from typewriters to computers, many just continued to type the way they were used to, and had trouble making the shift. Even if you told them a dozen times, it's difficult to break long-established habits.

  • Jay (unregistered) in reply to foxyshadis
    foxyshadis:
    Pizza Boy:
    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

    I pity the poor misguided son of a gun trying to micro-optimize a few bytes out by storing house numbers as integers, but has anyone actually done that? Everyone seems to associate the house number with the street name.

    Years ago I worked for a Political Action Committee. We got printouts from the Board of Elections that were called "walking lists", intended to be used by people who were going door-to-door passing out campaign literature. These were lists of registered voters, sorted by street, within street by odd vs even house number, and within odd/even by the house number. This was intended to give a list in the order that the houses would be on the street, first one side and then the other. (Do other countries use the same convention as the US? That on one side of the street the house numbers are all even and on the other side they are all odd?)

    This of course required that house number be stored as a separate field.

    They had an additional field for the extra things that sometimes get appended to a house number, like a letter or a fraction. ("101B", "214 1/2", etc)

    So yes, there are times when you want to store the house number separately and be able to manipulate it.

  • Jay (unregistered) in reply to Ol' Bob
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

  • Maude (unregistered) in reply to Jay
    Jay:
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

    Python you moron. And I'd guess many, many more.

  • (cs)

    Wait, Dallas?

    Like Dallas, TEXAS?

    Ladies and gentlemen, we finally found out the rule has an exception:

    INTs are not bigger in Texas!

  • (cs) in reply to Michael J. Cohen
    Michael J. Cohen:
    Sadly, Veekun's article is pretty wrong in and of itself.

    There are multiple in-depth analyses of what he got wrong floating around, but here's the HN thread that I most readily remember reading...

    http://news.ycombinator.com/item?id=4177516

    Worth to read the replies, too!

    Then you will find out that Veekun is not so far off as you suggested.

    And you will notice that the author "wvenable" claims that Java supports pass-by-reference.

  • Jay (unregistered) in reply to foo
    foo:
    Let's see, TRWTFs are: ... - Testing on a different configuration that production ...

    Well, having development and production machines with identical configurations eliminates some areas of problems -- like the one brought up here -- but is often impractical.

    Like, I probably want to have a debugger running on my development machine to help identify errors, but not on my production machine because it would hurt performance. There may be other applications running on the production server that I don't have on my development server. The production server typically is more powerful than the development server because it has to support more users. Etc.

    "Configuration" is a big thing. It is not at all easy to insure that the configuration on two machines is absolutely identical, i.e. that they have exactly the same hardware; exactly the same version of the OS, including all pactches; all the same software, including utilities, software we have purchased, and what we have developed ourselves, etc.

    And of course there are some ways in which the production server MUST be different from a development server. We probably don't want the development server talking to the production database server. If we have interfaces to external systems, we probably don't want our development server sending messages to external production system. Hopefully such differences are just a matter of changing some URLs or the like in some configuration files, but not always.

    For that matter, if we are supporting multiple production servers, does each developer have to have a separate development computer for each production server that any app he works on is deployed on?

  • (cs) in reply to Maude
    Maude:
    Jay:
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

    Python you moron. And I'd guess many, many more.

    Smalltalk, for example.

  • Jay (unregistered) in reply to Maude
    Maude:
    Jay:
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

    Python you moron. And I'd guess many, many more.

    I said "In what language can all numeric types store the number 5 billion?"

    Quoting from http://www.devshed.com/c/a/Python/Data-Types-in-Python/, "A plain integer takes up just a few bytes of memory and its minimum and maximum values are dictated by machine architecture. sys.maxint is the largest positive plain integer available, while -sys.maxint-1 is the largest negative one. On 32-bit machines, sys.maxint is 2147483647." So my statement is not refuted.

    Even granting that Python lets you work with numbers of arbitrary size easily ... well, maybe the point of the original writer was that Python is a "good" language and languages that do not do this are "bad" languages.

    If so, the bad languages still include the languages used for almost all of the development going on in the world: C, C++, C#, Java, Javascript, VB, not to mention Fortran, COBOL, and assembler.

  • SystemsReady (unregistered)

    I dunno, personally I'd have all numbers as strings. You're not doing math with them, and having them as strings with the appropriate formatting in the database will keep you from having to write PHP code to format them every time you spit them out. :)

  • Agention (unregistered) in reply to flats

    I only know 32767 and 65535 by heart. 31 & 32 bit numbers look so... big.

  • (cs) in reply to Jay
    Jay:
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

    GolfScript. But it's most certainly not suited for business use.

  • Norman Diamond (unregistered) in reply to Jay
    Jay:
    Norman Diamond:
    Jay:
    foo:
    The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.
    That seems rather pointless. If all the numbers start with a zero, then the zero is superfluous and could be left off.
    That's the reason why international calls omit that zero between the country code and the remainder of the city code. However, most calls are domestic and the zero is needed to indicate that a full number is being dialled instead of a local (intra-city) number.

    Also, historically, long distance calls even within a single country were considerably more expensive than local (intra-city) calls. Also phones were dialled using dials instead of push buttons. So if a phone were offered for public use by a corner store or other public facing proprietor, they would put a lock in the 9 position in the dial. Digits 1 to 9 could be dialled but 0 couldn't be dialled (except by historical phone phreaks of course). Phone numbers didn't have any 0 digits except the first digit of the city code. So local calls could be dialled but long distance calls could not be dialled.

    Eventually pay phones replaced public use of phones provided by corner stores etc. (and later pay phones became obsolete because everyone except me carries a cell phone but let's not get ahead of ourselves), local numbers started to include embedded 0's the same as other digits, and the costs of calls were computed by some newfangled kind of calculating machine so it was no longer necessary to lock out the riffraff from dialling an initial 0.

    I'm not sure if you're agreeing with the original poster or not.
    Yes and no. The leading 0 is superfluous when the caller is in another country, so they dial the country code, omit the zero, and continue with the rest of the city code and local number. The leading 0 is not superfluous when the caller is in the same country.

    Jay:
    I think the real answer here is: No, there is no country where all phone numbers start with "0". There may be countries where all DOMESTIC numbers start with "0", or some other subset, so that the zero indicates which subset.
    Well, if you want to play word games by saying that a country's own phone numbers are a subset of this country's phone numbers, and foreign countries' phone numbers are a different subset of this country's phone numbers, so the first subset starts with 0 (domestic numbers including their city codes) while the second subset doesn't start with 0 (foreign countries' country codes) ... ok, you set up your subsets that way, but I'm not going to pretend to understand it.
  • Norman Diamond (unregistered) in reply to Jay
    Jay:
    foxyshadis:
    Pizza Boy:
    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

    I pity the poor misguided son of a gun trying to micro-optimize a few bytes out by storing house numbers as integers, but has anyone actually done that? Everyone seems to associate the house number with the street name.
    [...] (Do other countries use the same convention as the US? That on one side of the street the house numbers are all even and on the other side they are all odd?) [...] They had an additional field for the extra things that sometimes get appended to a house number, like a letter or a fraction. ("101B", "214 1/2", etc)
    Thank you for noticing the fractions. Here are a few more examples of countries which don't use the same convention as the US.

    The world's largest country by population, and many other countries near it, have sequences of numbers as the previous poster pointed out: 1/27 27-365 Subdistrict number within a named district, block number (a 2-dimensional area surrounded by roads), lot number (starting with 1 for some randomly chosen lot in the block, and incrementing as you walk around the block by following the roads either clockwise or counterclockwise). As areas get redeveloped, sometimes a merged block gets two or more block numbers, the lot numbers no longer make sense, etc. Also if a lot contains two or more buildings then you'd better include the building name in the address.

    The world's second-largest country by population: No house numbers. Building name, apartment number, floor number, name of street, and name of city.

    The US and some other countries: Rural route number. No house number, no street name.

    Some of my relatives:

    (The above line is null. No house number, no street name, no rural route number. Just the district name and village name. The postman has to know everybody in the district.)

  • (cs) in reply to KattMan
    KattMan:
    Zemm:
    Maurits:
    At the risk of being tautological, if you don't need to do math on the thing, it's not a number, it's just an identifier.

    I'll add ISBNs and PINs to KattMan's list, and subclass part numbers as UPCs and EANs.

    But EANs (of which ISBNs and UPC are subsets) have check digits that you add and modulo to ensure you have read the number correctly. That sounds like maths to me.

    I wouldn't, because you do not do math with the entire set of digits, rather you pull it apart into its separate digits and then do math on that. It is a series of characters that fall within the range of 0-9 that you will split (string operation) then convert to numbers and perform a checksum calculation on.

    If you saved it as a number field (int, double, float whatever) you would have to convert it to the string to split it then convert the pieces back to ints and do the math. Cut out one of those operations since you are not doing math on the original string of digits.

    Edit: I will further mention those UPC codes or EAN's that begin with 0, save it as a number and you won't have the right number of digits to perform your checksum on, save it as a string and you will preserve your true EAN or UPC value.

    You could still store it as a number after performing your string-based validation. You'd even only need to store maximum 12 digits, needing 40 bits, since the check digit is redundant for storage. If it is >= 100000000000 then it's an EAN barcode, otherwise UPC and for output you'd just pad out with zeros to 11 digits. After that compute the check digit. (All scanners should be compatible with both. A UPC is an EAN beginning with 0).

    All that is only if you care about saving the few bytes of storage. These days I'd call that field VARCHAR and not worry about it. I've seen barcodes much longer than 13 characters that you may or may not need to care about. Some barcodes can even store non-numerals so a string field would be the only solution in this case.

  • (cs) in reply to Daniel
    Daniel:
    a few that expect you to pick a US state when you don't live in one (although admittedly I have not seen that particular manifestation of idiocy for quite a while now).

    You're lucky. I still run into it all the time. That and its cousin, the required state that only accepts two characters.

  • SimonP (unregistered) in reply to A Person

    If you are coerced into doing this you should probably convert the int back into a phone number and check it's the same as the number you intended to store... at least this way when it goes wrong you'll know all about it!

  • Danny (unregistered) in reply to Rick

    How about using a language that has working numbers?

  • (cs) in reply to Ol' Bob
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Programming languages which require that developers know and care about the syntax for creating, handling, and closing filehandles are ill-suited for business use. We should make a programming language that implicitly creates files on disk to store data. Variables are read from, and written to, files with the same name. Scope is handled with directories. Files are automatically closed when variables leave scope. Options set when declaring a variable could force file deletion when it leaves scope, or give it an explicit filename that differs from its variable name. In this way we wouldn't have to use filehandles at all, which helps prevent developer confusion. To write to a disk, simply create a variable with the filename and write to that variable. Reading from a disk is easier, just create a variable and it will be initialized with the current file contents.

    The best part is that we'd avoid using memory entirely. It would be so efficient!

  • caper (unregistered)

    Unless they are doing something very dumb, PHP is not the problem:

    $ cat z.php #!/usr/local/bin/php

    <?php $s = "9895551212"; printout( $s ); $i = 9895551212 ; printout( $i ); function printout( $x ) { echo $x . "\n"; } ?>

    $ ./z.php 9895551212 9895551212

    I'm guessing that they also use MySQL and store the strings as 32 bit signed integers which is where things went wrong. http://dev.mysql.com/doc/refman/5.0/en/out-of-range-and-overflow.html

  • big picture thinker (unregistered) in reply to Geoff
    Geoff:
    Not a PHP guy so I don't know but, if you try to convert a string to an int and its to big you get the largest possible signed integer value? Its not an exception, or overflow error?

    What the hell kind of sense does that make?

    Well, from an assembly point of view, there is no exceptions for overflows. Since arithmetic is modular, the CPU will just set the carry flag if the result exceeds the maximum value that can fit in the register. The result might not be what you expect, but there is no actual "error" or "exception".

    In some languages, when the carry flag is set, the designer of the language decided to have an exception thrown.

    In other languages, when the carry flag is set, the designer of the language decided to return INT_MAX.

    Saying one makes sense but not the other is kind of arbitrary and subjective.

    In one case, you trap the exception... in the other case, you can compare the result to INT_MAX... either way, you can effectively get the job done.

    If anything, many people argue that exception-based programming is something that can lead you down a very dangerous path if you don't fully understand it and you don't know how to do it correctly.

  • (cs) in reply to curtmack
    curtmack:
    Programming languages which require that developers know and care about the syntax for creating, handling, and closing filehandles are ill-suited for business use. We should make a programming language that implicitly creates files on disk to store data. Variables are read from, and written to, files with the same name. Scope is handled with directories. Files are automatically closed when variables leave scope. Options set when declaring a variable could force file deletion when it leaves scope, or give it an explicit filename that differs from its variable name. In this way we wouldn't have to use filehandles at all, which helps prevent developer confusion. To write to a disk, simply create a variable with the filename and write to that variable. Reading from a disk is easier, just create a variable and it will be initialized with the current file contents.
    Google "Smalltalk image-based persistence": it's a language that has solved both problems with a far simpler approach.
    curtmack:
    The best part is that we'd avoid using memory entirely. It would be so efficient!
    But what would you do on an embedded system without a filesystem?
  • (cs) in reply to caper
    caper:
    Unless they are doing something very dumb, PHP is not the problem: ... I'm guessing ...
    Stop guessing, just read the article. Turns out guessing was exactly the problem:
    Justin Reese:
    4.As part of that process, I run XML attributes through a very basic type-guesser I wrote 5.That type-guesser says "if you're numeric and not float-like, you must be an int, so… I HEREBY DUB THEE SIR (int) $value
    PHP is part of the problem, as it supports the culture of dynamic-typing / duck-typing.

    XML can be written including a schema, no need to "guess" types.

  • Shark8 (unregistered) in reply to Mozzis
    Mozzis:
    If I am writing in C, it is at least partly because I don't want all of the hand-holding and its associated overhead that would be implied by a check for overflow everytime I added two numbers together. And don't tell me it can be done in "only a couple of assmembly instructions" - if I am using C, I expect *maximum performance*, and if results need checking, I will do it myself thank you very much.

    Bad idea; oftentimes an optimizing compiler can get things right a good deal better than an experienced low-level language programmer. The reason is that while the programmer may know a few optimizing tricks, he is unlikely to know the same number that are in the optimizing-compiler.

    See: http://www.seas.gwu.edu/~adagroup/sigada-website/lawlis.html

  • Shark8 (unregistered) in reply to Jay
    Jay:
    Ol' Bob:
    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

    Hmm, then to the best of my knowledge, there are no programming languages that are well-suited for business use. In what language can all numeric types store the number 5 billion? Maybe there are some out there, but I don't think I've ever used them.

    COBOL, LISP, and Ada can all handle business programming. The "weakest" in these according to your criterion is Ada because the LRM allows it to reject programs it can't compile; and if the 5-billion is entered into an Ada program where the compiler is so restricted (think embedded 16-bit processors) that compiler is free to reject the program.

  • skipc (unregistered)

    I was on a 5 hour call when i did support at Microsoft. I forget the initial issue but the problem turned out to be that the guy had named his computer "007" and Windows was plugging that in as IP address 0.0.0.7.

  • Azarien (unregistered)

    TRWTF is that the int was silently saturated at INT_MAX. If it became something like -1965481203, the reason would be obvious.

  • (cs)

    There was a situation where a change of infrastructure meant that files were suddenly automatically sorted on a print queue by order of size. As our reports were generated: front page, body, back page (in separate files - we had our reasons, mainly to do with mailing packages), suddenly finding that all the front pages, then all the back pages, then all the report bodies generated afterwards, was a bit of a nasty shock.

    The solution involved adding a datestamp (in mumeric format) to the filename (in itself not a trivial deal because we were limited to 39 characters, IIRC - yes, it was VMS). The bright spark who came up with the answer coded the date into a number (10 digits). (I can't remember the details of this, or why this solved the problem - it's a long time ago.)

    Later that month, on the 22nd to be precise, the report s/w fell over.

  • Martin (unregistered) in reply to Anon
    Anon:
    Geoff:
    Not a PHP guy so I don't know but, if you try to convert a string to an int and its to big you get the largest possible signed integer value? Its not an exception, or overflow error?

    What the hell kind of sense does that make?

    Welcome to the wonderful world of PHP.

    In the world of PHP, if you ask it to do something stupid that it doesn't understand, it decides that it's better to just do something rather than give you one of those troublesome error messages that stops your program from running. Nobody likes those.

    Heh. I recently learned that an (int)floatingPointNumber does the same in C#. At least C# has the Convert class as an alternative, which will throw an exception on overflow.

    But for a supposedly modern language, C# has an amazing number of features with shoot-yourself-in-the-foot potential. Most of them copied from C.

  • padjo (unregistered)

    Hah, I've done that exact thing, including the 64bit/32bit mismatch. 2147483647 is now etched in my memory for ever.

  • (cs) in reply to Marc
    Marc:
    Incremental, numeric keys are a bad idea, anyway - they're a one-way trip to unscalable applications.
    Not to mention porting that data to another database. Eg. if you have a kind of "registry" database. You need to implement the same functionality in another project, so you say: "Yeah, I've got the code. I'll just add it to that other project" and do a basic export - import... only the keys already exist in the other database. Nice going, incremental, numeric keys!
  • ccj (unregistered)

    TRWTF is a 'type guesser' -- why not just alter the XML spec and/or DB schema such that each datum must be strongly typed? (Note: I work in a research-oriented digital signal processing shop and have never had 'business' people as clients... I'm guessing my suggestion might be non-trivial with some blighted non-1337 humans involved) Good catch all the same, kudos!

    captcha: "enim" for when you need an enum type immediately!

Leave a comment on “Confessions: The Phone Number”

Log In or post as a guest

Replying to comment #:

« Return to Article