• (cs) in reply to AndyG
    AndyG:
    It doesn't really matter whether "zip code" exists as a primitive type in a language or DDL. To say that "I can treat a zip-code as a number" is not the same as to say that "a zip code is a number." This is no more, and no less, accurate than saying "a zip code is a string."

    The choice, for persistence, is largely arbitrary. In a programming environment, however, I would respectfully recommend that you treat a zip code as a zip code.

    Tell me, what sort of a number is "96033-1234"? Do you apply the operator? Do you take the standard Web-based approach for data entry and use Javascript to insist that zip-codes only have digits in them?

    Or do you treat it like a zip code?

    As has been pointed out above, it makes no sense to apply arithmetic operations on zip codes. Ergo, they are not numbers. It makes no sense to concatenate them, or to compare them lexically, or to do any one of a number of stringesque things with them. Ergo, they are not strings.

    Someone needs to get off their high horse here.

    1. It can make perfect sense to compare two zip-codes lexically - indexing is one immediate application that springs to mind.

    2. You've got two sides to this argument. Of course it is desirable for your APPLICATION to treat zip-codes as zip-codes. No-one is suggesting that you shouldn't write a zip-code class to manage the particular behaviours of zip-codes. However, within that class you are going to have to choose an INTERNAL REPRESENTATION for your zip-code data. Here the question of whether it is a string or number is not actually arbitrary, as it will affect the performance and complexity of the class implementation.

    Oh, and don't be such a condescending prick.

    Well, you've neatly chopped the original posting -- "Zip codes are NOT numbers. They are strings. Numbers trim leading zeros" -- which would tend to contradict your suggestion that "No-one is suggesting that you shouldn't write a zip-code class..." (it seems to me). However, I accept that you're not manipulating prior statements, but just cleaning up.

    I'm more concerned by having words put into my mouth whenn the original quote is still standing, though. In what way is it not possible to be "largely arbitrary" and "not actually arbitrary" at the same time? Many thanks for implying that I am brain-dead enough to ignore the consequences of expressing a zip code internally as, say, a 3-D model of a hydrocarbon molecule. Yes, it could be encapsulated as a string. It could be encapsulated as a number (in some way -- hopefully not floating-point, no matter what the temptation).

    But the fact remains that the chosen representation is "largely arbitrary." You make the choice once and once only, and you probably do it for efficiency and for ease of use, but after that it's essentially opaque. In that sense, the choice is "largely arbitrary," or, in your terms, it is "desirable for your APPLICATION to treat zip-codes as zip-codes." (Actually, I think it is pretty fucking essential that your application treats zip-codes as zip-codes.)

    I'm sorry, but if by "condescending prick" you mean somebody who has seen more than his fair share of busted implementations based upon shoddy semantics, then, yes, I'm happy to be a condescending prick.

    Oh, and the lexical comparison thing? Yah boo sucks, and condescending prick to you too. Clearly you can use lexical comparison to index zip-codes. You can do this with a lot of things that aren't strings. My bad example -- I'm sorry. But it doesn't make the operands "strings," does it?

    I notice that you didn't pick on the "96033-1234" or on the zip code concatenation or on the point (made by others) that you cannot usefully apply arithmetic operators to zip-codes.

    Zip codes are not numbers and they are not strings. That is all ye know and all ye need to know.

  • Whitey (unregistered) in reply to Bishoy
    Bishoy:
    Does anybody understand Obfuscation? cauz this code to me looks like Obfuscated so other developers dont understand it.

    real WTF is the poor guy took his time to format the code and ident it.

    Obviously you don't. Was this on the quiz this week? There's only two variables "counter" and "zipcode" and a bunch of if's and counter increments. It takes two seconds to figure out what it does and you realize that the guy who wrote this has no idea how to use the tools.

  • Whitey (unregistered)

    @ardvark "I'm sorry, but if by "condescending prick" you mean somebody who has seen more than his fair share of busted implementations based upon shoddy semantics, then, yes, I'm happy to be a condescending prick. "

    I'm pretty what he means when he's calling you a condescending prick is that you are a FUCKING TOOL. Get over yourself, you're being a dick and you don't know what you are talking about.

    So in your infinite wisdom, you're saying that every data that passes through your code, is represented as an object? You write a custom class for every zipcode, address, phone number, DOB, bra size, measurement, etc? Let me guess, not only did you graduate in CS, you got your masters? ... and now you teach? In theory, everything in theory works as it works in practice. In practice, it does not.

  • (cs) in reply to webhamster
    webhamster:
    chesta:
    zip:
    Troy Mclure:
    anon:
     if(zipcode>=00000)
         ...
            if(zipcode>=00)
    
    Umm, is this another WTF - treating numbers as strings?

    Zip codes are NOT numbers. They are strings. Numbers trim leading zeros

    So what's wrong with representing the zip code 00012 as 12 internally?

    Internationalization, for one thing. Not everyone uses numbers.

    Extended (9-digit) zip codes, for another. If you have 1234 in a 9-digit zipcode field, is that supposed to be 01234-0000 or is the first part missing, as in 00000-1234?

    Exactly. Try feeding this thing R2J 8K7 and see what happens.

    Are you being intentionally dense, or does it just come naturally? A ZIP code is defined for use in the US (with some caveats), and is defined as a series of 5 digits. To put in what looks to be a Canadian postal code is nonsensical. Remember, we're talking ZIP codes, here, not postal codes used elsewhere. And on the subject of whether 1234 is 00000-1234 or 01234-0000, that sure seems like an implementation detail to me. For example, I might make a base ZIPCode class that stores the 5 digit ZIP as an integer. Then I can subclass it with ZIPCodePlusFour, which contains a second variable to store the other 4 digits. Or maybe I just shove it all into an unsigned long and store 01234-0000 as 12340000, and 00000-1234 as 1234. It's really not complex, so stop trying to make it seem as if it is.

  • Demaestro (unregistered)

    That is the pretty code I have ever seen.

    I don't mean pretty like nice code.. I mean it makes a nice shape on the page.

    Captcha: tastey

  • Harrow (unregistered) in reply to Troy Mclure
    Troy Mclure:
    Ok well when databases/programming languages establish the zip code or telephone number datatype please let me know. I'm sitting here with baited breath
    The common expression is "waiting with bated breath". "Bated" means stopped or suspended. "Baited" means adorned with an attractive lure.

    You should more properly have said, "I'm sitting here with bated breath".

    Unless, of course, you are lurking in ambush outside a rabbit burrow after rinsing your mouth with carrot juice.

    -Harrow.

  • Harrow (unregistered) in reply to Troy Mclure
    Troy Mclure:
    Ok well when databases/programming languages establish the zip code or telephone number datatype please let me know. I'm sitting here with baited breath
    The common expression is "waiting with bated breath". "Bated" means stopped or suspended. "Baited" means adorned with an attractive lure.

    You should more properly have said, "I'm sitting here with bated breath".

    Unless, of course, you are lurking in ambush outside a rabbit burrow after rinsing your mouth with carrot juice.

    -Harrow.

  • Andrew (unregistered) in reply to Troy Mclure
    Troy Mclure:
    zip:
    Troy Mclure:
    anon:
     if(zipcode>=00000)
         ...
            if(zipcode>=00)
    
    Umm, is this another WTF - treating numbers as strings?

    Zip codes are NOT numbers. They are strings. Numbers trim leading zeros

    So what's wrong with representing the zip code 00012 as 12 internally?

    Nothing really. But hopefully they never go to a 6 digit zip or 12 could be 00012 or 000012. Since its a fixed-length, its really just a preference. Personally since it doesnt make sense to use math operations on it (add, subtract..etc) and leading zeros need to be present I think of it as a string

    These checksums are very old rules, and work on simple computers. I personally know the LUHN10 credit-card checksum better. It doubles every other digit, and makes sure the sum of the digits is divisible by 10 (MOD10).

    In C, this is easy and takes very little memory. Treat the digits as byte array of intgers, each in the range 0-9. For an ASCII digit-string, subtract 48 (ASCII "0") to get numbers. Then, calculate in a loop. An assembly language version isn't much harder.

    /* LUHN10 checksum (almost) */ unsigned char zip[6], sum = 0; for (k = 0; k < 6; k++) { zip[k] -= 48; if (1 == k % 2) zip[k] = 2; sum += zip[k]; } if (sum % 10) return (-1); / Error: not divisible by 10 / else return(0); / ok! */

  • Carrot Breath (unregistered) in reply to Harrow
    Harrow:
    Troy Mclure:
    Ok well when databases/programming languages establish the zip code or telephone number datatype please let me know. I'm sitting here with baited breath
    The common expression is "waiting with bated breath". "Bated" means stopped or suspended. "Baited" means adorned with an attractive lure.

    You should more properly have said, "I'm sitting here with bated breath".

    Unless, of course, you are lurking in ambush outside a rabbit burrow after rinsing your mouth with carrot juice.

    -Harrow.

    Yeah, that's definitely not a mute point.

  • anon (unregistered) in reply to chesta
    chesta:
    If you have 1234 in a 9-digit zipcode field, is that supposed to be 01234-0000 or is the first part missing, as in 00000-1234?
    That depends on whatever convention you set. If I have 0xDEADBEEF, what does that mean? Maybe it means -559038737 (signed int) Maybe it means 3735928559 (unsigned int) Maybe it means -6.2598534e18 (single-precision floating point). Maybe it means something else entirely.
  • Andrew (unregistered) in reply to bstorer
    bstorer:
    webhamster:
    chesta:
    zip:
    Troy Mclure:
    anon:
     if(zipcode>=00000)
         ...
            if(zipcode>=00)
    
    Umm, is this another WTF - treating numbers as strings?

    Zip codes are NOT numbers. They are strings. Numbers trim leading zeros

    So what's wrong with representing the zip code 00012 as 12 internally?

    Internationalization, for one thing. Not everyone uses numbers.

    Extended (9-digit) zip codes, for another. If you have 1234 in a 9-digit zipcode field, is that supposed to be 01234-0000 or is the first part missing, as in 00000-1234?

    Exactly. Try feeding this thing R2J 8K7 and see what happens.

    Are you being intentionally dense, or does it just come naturally? A ZIP code is defined for use in the US (with some caveats), and is defined as a series of 5 digits. To put in what looks to be a Canadian postal code is nonsensical. Remember, we're talking ZIP codes, here, not postal codes used elsewhere. And on the subject of whether 1234 is 00000-1234 or 01234-0000, that sure seems like an implementation detail to me. For example, I might make a base ZIPCode class that stores the 5 digit ZIP as an integer. Then I can subclass it with ZIPCodePlusFour, which contains a second variable to store the other 4 digits. Or maybe I just shove it all into an unsigned long and store 01234-0000 as 12340000, and 00000-1234 as 1234. It's really not complex, so stop trying to make it seem as if it is.

    Read the question! The actual ZIP code values are irrelavent to this exercise. The person is trying to calculate a check-digit for the ZIP's barcode, which is much less work.

    There is an algorithm to test the barcode's checksum. Change it algebraically to find the check-digit instead.

    Would you program all the powers of two in an array, or just calculate 222... in FOR loop? That is the WTF here.

  • Pedantic (unregistered) in reply to Something Like A Name
    Something Like A Name:
    http://www.leadtec.com/d_barcd.htm#checksum

    Poster was correct, but missed a step in the checksum calculation, that being multiplying each digit of the barcode by 9-0 (right to left), and summing all products. In this case, 9*9=81 (congruent to) 1 (mod 10).

    This URL does NOT provide the algorithm for the check sum digit of the Postnet barcode. It is for barcodes found on coupons. The Postnet checksum is much simpler and does not involve mutlipying digits by digit position.

    Using the wrong algorithm is also a WTF.

  • Troy Mclure (unregistered) in reply to Harrow
    Harrow:
    Troy Mclure:
    Ok well when databases/programming languages establish the zip code or telephone number datatype please let me know. I'm sitting here with baited breath
    The common expression is "waiting with bated breath". "Bated" means stopped or suspended. "Baited" means adorned with an attractive lure.

    You should more properly have said, "I'm sitting here with bated breath".

    Unless, of course, you are lurking in ambush outside a rabbit burrow after rinsing your mouth with carrot juice.

    -Harrow.

    Well I've seen it spelled both ways actually. I'm way past the 4th grade so I have no shot at winning the spelling bee anyway.

    But thanks for the correction

  • Jason Doege (unregistered) in reply to chesta

    I doubt it has to do with internationalization. Zip codes are a part of an American address. Canada, for instance, uses something called a Postal Code with the format ANA NAN. It is, most assuredly, not a Zip code, though it performs a similar function.

  • Crash Magnet (unregistered) in reply to Rolf

    I gonna ask this...

    I can see that that code is a huge WTF ( I coded something >like that twice in past :P )

    But I recently started learning C and I wonder how the zip >code checking would have looked like if you kept it as >strings and avoided thousands of line code like this one?

    If your zip code is stored as a number:

    UINT8 CalcCheckSum(UINT32 Zipcode) { return ZipCode % 10; }

    If your zip code is stored as a character string:

    UINT8 CalcCheckSum(char *ZipCode) { int len; int i; UINT16 sum;

    sum = 0;
    len = strlen(ZipCode);
    for (i = 0; i < len; i++) sum += ZipCode[i] - '0';
    
    return (UINT8) (sum % 10);
    

    }

    UINT8, UINT16, and UINT32 are unsigned numbers of the indicated width. They are usually defined thus:

    typedef unsigned char UINT8; typedef unsigned short UINT16; typedef unsigned long UINT32;

    HTH Crash Magnet

  • hmphargh (unregistered) in reply to Troy Mclure

    its what happens when you go fishing and cant catch anything :-\

  • Jason Doege (unregistered) in reply to Troy Mclure

    Yes, I've seen it spelled both ways also. For instance, in this post. However, "bated" is the correct word to use with that phrase.

  • (cs) in reply to Crash Magnet
    Crash Magnet:
    >I gonna ask this... > >I can see that that code is a huge WTF ( I coded something >like that twice in past :P ) > >But I recently started learning C and I wonder how the zip >code checking would have looked like if you kept it as >strings and avoided thousands of line code like this one?

    If your zip code is stored as a number:

    UINT8 CalcCheckSum(UINT32 Zipcode) { return ZipCode % 10; }

    If your zip code is stored as a character string:

    UINT8 CalcCheckSum(char *ZipCode) { int len; int i; UINT16 sum;

    sum = 0;
    len = strlen(ZipCode);
    for (i = 0; i < len; i++) sum += ZipCode[i] - '0';
    
    return (UINT8) (sum % 10);
    

    }

    UINT8, UINT16, and UINT32 are unsigned numbers of the indicated width. They are usually defined thus:

    typedef unsigned char UINT8; typedef unsigned short UINT16; typedef unsigned long UINT32;

    HTH Crash Magnet

    You realize that your algorithms do different things...right? Try the false zip of 11111
  • GoldenRatio (unregistered) in reply to Jason Doege

    Not to get too off topic, but if you have seen it spelled both ways, then you've seen it spelled a WRONG way and a RIGHT way. This reminds me of a classmate when i was in school, who insisted "queue" was pronounced "kway." His reasoning was that a bunch of his friends pronounced it that way or something, and after an hour or so of debate came to the conclusion that it could be pronounced either way.

    It's pronounced "kew" (or, like the letter "Q"), and the expression is "bated."

  • Troy Mclure (unregistered) in reply to GoldenRatio
    GoldenRatio:
    Not to get too off topic, but if you have seen it spelled both ways, then you've seen it spelled a WRONG way and a RIGHT way. This reminds me of a classmate when i was in school, who insisted "queue" was pronounced "kway." His reasoning was that a bunch of his friends pronounced it that way or something, and after an hour or so of debate came to the conclusion that it could be pronounced either way.

    It's pronounced "kew" (or, like the letter "Q"), and the expression is "bated."

    Who gives a fuck? How often do you actually spell it out? You must be a hit with the ladies

  • Akshay (unregistered)

    What address is that? (house on the street in the empire on which the sun never sets) 10 Downing St?

  • jack (unregistered) in reply to Carrot Breath

    possibly not moot rather than mute. i think it goes without saying that written points cannot be noisy :P captcha: stinky, and i showered this morning :(

  • Henry (unregistered) in reply to Troy Mclure

    [quote user="Troy Mclure"][quote] I'm sitting here with baited breath[/quote]

    What did you bait your breath with? Or perhaps you meant "bated" breath?

  • GoldenRatio (unregistered) in reply to Troy Mclure
    Troy Mclure:
    Who gives a fuck? How often do you actually spell it out? You must be a hit with the ladies
    Because it makes me uneasy knowing there are people walking around that don't know this kind of stuff.

    If you pronounce "queue" as "kway", people need to know so they can stay the fuck away from you.

  • jack (unregistered) in reply to jack
    jack:
    possibly not moot rather than mute. i think it goes without saying that written points cannot be noisy :P captcha: stinky, and i showered this morning :(
    no that was bad. i meant 'possiblt moot' rather than 'possibly not moot.' sorry all
  • Troy Mclure (unregistered) in reply to Henry

    [quote user="Henry"][quote user="Troy Mclure"][quote] I'm sitting here with baited breath[/quote]

    What did you bait your breath with? Or perhaps you meant "bated" breath? [/quote]

    Good job. You have now officially killed the joke. Thanks Henry. Just like buffer overflows cease to be amusing, the 7th person to point out that I spelled that word wrong also ceases to be amusing too

  • Troy Mclure (unregistered) in reply to GoldenRatio
    GoldenRatio:
    Troy Mclure:
    Who gives a fuck? How often do you actually spell it out? You must be a hit with the ladies
    Because it makes me uneasy knowing there are people walking around that don't know this kind of stuff.

    If you pronounce "queue" as "kway", people need to know so they can stay the fuck away from you.

    Yes but spelling and pronouncing are not the same thing. Baited and Bated are pronounced the exact same way - hence the reason I didn't spell it right. Queue and Kway are not pronounced the same.

  • InvertedMind (unregistered)

    Wa off the general path, but would that be 23 Wall Street, or "The House of Morgan" referred to in paragraph 1?

  • GoldenRatio (unregistered) in reply to Troy Mclure
    Troy Mclure:
    Yes but spelling and pronouncing are not the same thing. Baited and Bated are pronounced the exact same way - hence the reason I didn't spell it right. Queue and Kway are not pronounced the same.
    I understand completely. In fact I had never heard the word "bated" before I heard that expression, so before then I probably would have spelled it that way as well. It makes no sense that way, but being what it is you don't necessarily expect it to make sense.

    I was more commenting on the fact that people seem to be using "yes i've seen it spelled both ways" as a viable justification.

  • (cs) in reply to bstorer

    Well, I make a perfectly innocent Sesame Street joke and get blasted by mindless idiots. On the other hand, it's possible to be personally insulting, first time on the thread:

    bstorer:
    Are you being intentionally dense, or does it just come naturally? A ZIP code is defined for use in the US (with some caveats), and is defined as a series of 5 digits. To put in what looks to be a Canadian postal code is nonsensical. Remember, we're talking ZIP codes, here, not postal codes used elsewhere. And on the subject of whether 1234 is 00000-1234 or 01234-0000, that sure seems like an implementation detail to me. For example, I might make a base ZIPCode class that stores the 5 digit ZIP as an integer. Then I can subclass it with ZIPCodePlusFour, which contains a second variable to store the other 4 digits. Or maybe I just shove it all into an unsigned long and store 01234-0000 as 12340000, and 00000-1234 as 1234. It's really not complex, so stop trying to make it seem as if it is.
    At the risk of having illiterate gibberish yelled at me once more from Whitey ...
    Whitey:
    @ardvark I'm pretty what he means when he's calling you a condescending prick is that you are a FUCKING TOOL. Get over yourself, you're being a dick and you don't know what you are talking about.

    So in your infinite wisdom, you're saying that every data that passes through your code, is represented as an object? You write a custom class for every zipcode, address, phone number, DOB, bra size, measurement, etc? Let me guess, not only did you graduate in CS, you got your masters? ... and now you teach? In theory, everything in theory works as it works in practice. In practice, it does not.

    ... I will try to defend webhamster, chesta and zip.

    It isn't unreasonable, and it certainly isn't dense, to think of a ZIP code in object terms. Store it in a number, or in a string, and sooner or later some moron is going to pass it to a routine as a number, or as a string, and it will be entirely inappropriate as such. (To be honest, you need a statically-typed language for this to be helpful, but let's just assume that this is what the posters mean.)

    Thinking of it as an object leads to good design practice. bstorer's design isn't quite right in C++: sub-classing from a concrete base is a no-no. (I'm happy to be told that it is a Good Thing in other languages.)

    Thinking of it as an object also allows you to plan for the future. Sure, it's just a ZIP code now. But who said we won't need Canadian postcodes, or British postcodes, or (God help me) Swedish postcodes any time soon? <sarcasm>Oh, I know, we'll make it a string. That way you can put absolutely anything you like into it.</sarcasm>

    If I thought that any of these whiners would benefit, I'd post a stub class implementation. But I don't. Whitey is absolutely free to guess, and utterly wrong. I don't have a degree in CS (it's in History: yes, yes, I know, BS). I don't teach. Frankly, the standard of students these days would be too disturbing.

    Oh, and Whitey? I had to think quite hard about what you were trying to say, but I believe you meant:

    In theory, everything in practice works as it works in theory. In practice, it does not.

    But then again, and I admit that it's an unlikely eventuality, you might be more worried about theory than practice.

    Derrick? You give good WTF. This is actually the first time I've seen a Design Pattern that is actually a pattern...

  • Jelmer (unregistered)

    I think a great idea is placing code in the else branches, giving very beautiful symmetric pyramids. And the first one looks somewhat like a pagoda, too. It's a pity therefore that they had to take out lines for unused ZIP codes, I think some parts of the code now look as ugly as it deserves.

  • ManicMailman (unregistered)

    All I know about Zip codes is that we need to bring back Mr. Zip!

    http://www.zip-codes.com/images/mrzippy.gif

  • AndyG (unregistered) in reply to real_aardvark
    Well, I make a perfectly innocent Sesame Street joke and get blasted by mindless idiots.

    No, you act like a condescending prick, and then you get called on it. Ad hominem begets ad hominem, I'm afradid.

    Thing is, I don't disagree with you about the benefits of encapsulation and abstraction. To be honest, I don't even have a strong opinion on how ZIP codes should be represented. My point is that, in general, encapsulation is only part of a good design. A poorly chosen internal representation can really screw you up in terms of application performance and complexity, and a good representation for one application may be a bad representation for another.

    But you know all this. And I'm sure you can explain it to people without all the Sesame Street bullshit.

  • kat (unregistered) in reply to iToad

    THANK you, that's the real actual point here. The horror!

    It's a real language, a lot like C, but not exactly. Of course that doesn't change the way modulus is found, so... oopsie.

    I have to blame any errors in the post on the HORROR that remains and completely overtakes me, every time I think about the ungodly, insane amount of work the programmer did, which was completely unnecessary. For the love of mike, there was a function in the library to get the check digit! {sob}

    Sorry about the mistake... (it HAS been quite some while since I ran across this code)

    Kat

  • Whitey (unregistered) in reply to real_aardvark
    It isn't unreasonable, and it certainly isn't dense, to think of a ZIP code in object terms. Store it in a number, or in a string, and sooner or later some moron is going to pass it to a routine as a number, or as a string, and it will be entirely inappropriate as such. (To be honest, you need a statically-typed language for this to be helpful, but let's just assume that this is what the posters mean.)

    No, but it also isn't unreasonable to implement it using a string either. I think that's where I have a problem with what you are saying. You seem to think that anything less than implementing it as an object is foolish. It's a god-damn zipcode dude.

    In theory, everything in practice works as it works in theory. In practice, it does not.
    That's what I meant to say.

    The point being that sure, custom object for a "zipcode" is probably the right way to do things. But if you've got a deadline and the "zipcode" you're dealing with is only referenced a few places and you can control the inputs, you may decide that it will work just as well and be done quicker if you just use a string.

  • Rich (unregistered) in reply to Paul
    Paul:
    It looks beautiful, though. ;]

    Just let the page scroll down and follow the code with your eyes. You'll get a "wheeee" feeling with each bump. Awesome. ;]

    Maybe they had just played Line Rider?

  • kat (unregistered) in reply to nickf

    Yes - they really DID do ALL these checks. Some of the code has been left out, because this was the basic structure, but there were HUNDREDS of lines of it. Within each zipcode range, they would increment a counter. I just showed the basic outline here, because.

  • kat (unregistered) in reply to kat

    Also, for those interested, a US postal barcode is built in this way: (Until the new 4-state barcode reaches wide acceptance)

    5 5-digit ZIP 4 Plus-4 of ZIP 2 DP (delivery point, usually the last 2 digits of the addy) 1 check digit (add all the previous numbers, discard tens place, and subtract from 10, unless it's zero.)

    12 characters total

  • (cs) in reply to Whitey
    Whitey:
    It also isn't unreasonable to implement a ZIP code using a string either. I think that's where I have a problem with what you are saying. You seem to think that anything less than implementing it as an object is foolish. It's a god-damn zipcode dude.
    In theory, everything in practice works as it works in theory. In practice, it does not.
    That's what I meant to say.

    The point being that sure, custom object for a "zipcode" is probably the right way to do things. But if you've got a deadline and the "zipcode" you're dealing with is only referenced a few places and you can control the inputs, you may decide that it will work just as well and be done quicker if you just use a string.

    Good, now we're both back on Planet Earth. No name-calling, no baseless insults. I feel happier this way; thank you.

    Yes, I agree with you. Simple is good, "if you can control the inputs." And for 99.X% of zip-coding, as it were, you are absolutely correct.

    On the other hand I am currently dealing with a system that has times, dates, timestamps, printable times ("270307" expressed and stored as an int, for God's sake), and so on. It also has the concept of a "null" timestamp, which for some unknown reason was #defined as 0x7FFFFFFF... Yup, subtract any (real) timestamp from this (timestamps are unsigned), and you get a positive number. Thus (in the naive case) making the null timestamp lexically greater than the real one.

    I worry about the simple stuff, sometimes.

    My original post (oh, so long ago) was purely intended to point out that it is not sensible to say that "a ZIP code is a number," or "a ZIP code is a string." Sure, you can conveniently represent it as such. But it's important to realise that it is, in fact ...

    A ZIP code.

    Basically I think we're in 100% agreement on this one. Implement it how you will, so long as the damn system works.

    Addendum (2007-03-27 15:19): For anyone else out there, when I say "we're both back on Planet Earth", I specifically include myself. I'd just as soon not indulge in mindless name-calling, but, as is the way, I'm usually more to blame for it.

  • Jim (unregistered) in reply to foo
    foo:
    vertagano:
    In fact, I though that 39 MOD 10 = 9 MOD 10 22229 MOD 10 = 22209 MOD 10 So, I'm not sure what the "ignore the 10s digit" stuff is about, either.

    I suppose the non-WTF explination of Modulo arithmetic is the real WTF... even their "good" programmers are bad.

    I know Kat. She just mangled the explanation a little. She's an excellent programmer.

  • (cs) in reply to Akshay
    Akshay:
    What address is that? (house on the street in the empire on which the sun never sets)

    Hint: It's in Essex.

  • TheReligion2000 (unregistered)

    Wow!!! This guy was NOT bad at all. He was an (ASCII-) artist. Great code. I'd like to be able to have such bright ideas.

  • roe (unregistered) in reply to iToad
    iToad:
    According to the font of all knowledge:

    http://en.wikipedia.org/wiki/Zip_code#Postal_bar_code

    You get the check digit by summing all the Zip Code digits, calculating the sum modulo 10, and then subtracting this value from 10.

    However, the poster's minor error in calculating the check digit doesn't change the fact that the code is an absolute horror. This is what happens when the programmer is either ignorant, incompetent, or paid by the number of lines of code produced.

    The Real WTF (tm) is the subtracting part, does that add any 'checksumming'-safety to the actual check digit? Im not overly familiar with bar codes, perhaps I'm missing something there (statistically fewer collisions with erroneous bar codes perhaps?), but to me, it's mapping 0-9 on 9-0 which is the same thing with slightly different (although, quite ridiculous) character set.

    You're absolutely right about the code though...

    And to cite Tom Lehrer, "... you take away seven, and that leaves five... well... six, actually... but the idea is the important thing".

  • (cs) in reply to real_aardvark
    real_aardvark:
    Well, I make a perfectly innocent Sesame Street joke and get blasted by mindless idiots. On the other hand, it's possible to be personally insulting, first time on the thread:
    bstorer:
    Are you being intentionally dense, or does it just come naturally? A ZIP code is defined for use in the US (with some caveats), and is defined as a series of 5 digits. To put in what looks to be a Canadian postal code is nonsensical. Remember, we're talking ZIP codes, here, not postal codes used elsewhere. And on the subject of whether 1234 is 00000-1234 or 01234-0000, that sure seems like an implementation detail to me. For example, I might make a base ZIPCode class that stores the 5 digit ZIP as an integer. Then I can subclass it with ZIPCodePlusFour, which contains a second variable to store the other 4 digits. Or maybe I just shove it all into an unsigned long and store 01234-0000 as 12340000, and 00000-1234 as 1234. It's really not complex, so stop trying to make it seem as if it is.
    I will try to defend webhamster, chesta and zip.

    It isn't unreasonable, and it certainly isn't dense, to think of a ZIP code in object terms. Store it in a number, or in a string, and sooner or later some moron is going to pass it to a routine as a number, or as a string, and it will be entirely inappropriate as such.

    zip's question was about representing a ZIP code internally as an integer. Yes, yes, ZIP is a class, and I address that point by suggesting a possible solution using classes. But like it or not, eventually we have to talk implementation. zip's suggestion is ridiculed because it doesn't take into account things it doesn't need to take into account. It's simply mind-numbing to complain because an implementation of a ZIP code can't handle things that aren't ZIP codes. I wouldn't beat down somebody's implementation of BigInteger because it doesn't handle complex numbers.
    Thinking of it as an object leads to good design practice. bstorer's design isn't quite right in C++: sub-classing from a concrete base is a no-no. (I'm happy to be told that it is a Good Thing in other languages.)
    It's a Good Thing in many modern OOP languages. C++'s behavior when methods aren't virtual is just silly. I didn't feel the need to suggest something involving composition or interfaces because that wasn't really the point.
    Thinking of it as an object also allows you to plan for the future. Sure, it's just a ZIP code now. But who said we won't need Canadian postcodes, or British postcodes, or (God help me) Swedish postcodes any time soon?
    And that's fine and dandy. But we're discussing the internal representation of a ZIP code. I don't care how you'd implement the Swedish, Welsh, Mexican, or any other postal code, because they don't solve the problem of implementing a ZIP. Wanna subclass everything from an abstract postal code class? Hey, that's super. But save it for when you start writing a second potential subclass. Either way, I'm probably implementing ZIP with an int (actually, I'd probably go with char[5]).
    If I thought that any of these whiners would benefit, I'd post a stub class implementation. But I don't. Whitey is absolutely free to guess, and utterly wrong. I don't have a degree in CS (it's in History: yes, yes, I know, BS). I don't teach. Frankly, the standard of students these days would be too disturbing.
    Frankly, I totally disagree with Whitey. Everything that is more than just a number ought to be a class. Address, phone number, and date are three of the classes I use most often. Bra size is a good example of when an object is needed (or at least a struct), because you're tying together a measurement (36) and a cup size (C). Measurements may or may not be classes, depending on the context.
  • (cs)

    The bar code on a piece of a US mail is the zip plus four, the last two digits of the house number, and the check digit. The zip code identifies a unique office, the plus four identifies a unique block, and the two digits of house number identify a unique house. Apartments are often sorted by building, not delivery point, by automated equipment. When they are sorted by delivery point, a unique plus four has been assigned to each floor.

    A single plus four can generally hold 99 houses, numbered 1 to 99. Technically the number 0 is available, but that house number is never used. This is, however, very rare, as every street, and every block on larger streets that use 3 or more digit numbers, must have a unique plus 4. A house that has a loft apartment or some such designated as '###-B' won't be sorted properly. The mail for ### and ###-B will be intermingled.

    If a plus-four becomes full, the zip code will be split. This happens a lot. In New York City, there are buildings that have their own unique zip code! The zip code contains regional information, with each postal district having a specific range of codes to allocate from. Larger offices also have separate zip codes for their PO boxes.

    Also, you are all idiots. Use whatever the hell you want to store a zip code, as long as it gets to the right place. And remember that, if the city name and the zip code don't match, it's going to that zip code first. If you're lucky, they might send it to the right city. It'll probably just come back.

  • dave (unregistered)

    besides the issue of the post making me question my knowledge of modulus, I think this is a prime example of the folly of metrics. As horrible as this code is I bet the coder was very efficient in terms of daily LOC (lines of code) produced.

  • Jason (unregistered)

    The hypnotic dance of the if statements

  • (cs) in reply to bstorer
    bstorer:
    real_aardvark:
    On the other hand, it's possible to be personally insulting, first time on the thread:
    bstorer:
    Are you being intentionally dense, or does it just come naturally? A ZIP code is defined for use in the US (with some caveats), and is defined as a series of 5 digits. To put in what looks to be a Canadian postal code is nonsensical. Remember, we're talking ZIP codes, here, not postal codes used elsewhere.
    I will try to defend webhamster, chesta and zip.
    zip's question was about representing a ZIP code internally as an integer.
    Yup, de ma faute. I meant to defend "anon," not "zip." Got a little bit of indentationitis there.
    bstorer:
    Yes, yes, ZIP is a class, and I address that point by suggesting a possible solution using classes. But like it or not, eventually we have to talk implementation. zip's suggestion is ridiculed because it doesn't take into account things it doesn't need to take into account.
    Frankly, your implementation still looks like bollocks to me. But you're right, it does look "possible."
    bstorer:
    It's simply mind-numbing to complain because an implementation of a ZIP code can't handle things that aren't ZIP codes. I wouldn't beat down somebody's implementation of BigInteger because it doesn't handle complex numbers.
    I, of course, would insist, in true straw-man style -- nobody even mentioned BigInteger, but what the heck, you're welcome to make this stuff up as you go along -- on beating down such an implementation. Complex numbers are obviously a superclass of BigInteger. Whereas "Postal Code" is clearly not a superclass of "ZIP code." Oh, those naughty implementers of "BigInteger."
    bstorer:
    real_aardvark:
    Thinking of it as an object leads to good design practice. bstorer's design isn't quite right in C++: sub-classing from a concrete base is a no-no. (I'm happy to be told that it is a Good Thing in other languages.)
    It's a Good Thing in many modern OOP languages. C++'s behavior when methods aren't virtual is just silly.
    ... and I said I was happy to be told that. Jeez, how emollient do you want me to be? I may very well be dense, but C++'s behaviour when methods aren't virtual makes perfect sense to me. They ain't virtual, dude. What you see is what you get.

    However, if someone with less of a hair up their ass can offer a concrete example -- I suspect from Python, or from CLisp, or maybe from Smalltalk, then I would still be interested. This isn't sarcastic. I really would be interested. I just need a concrete example. The C++ idiom is just an example to help me formulate the question.

    bstorer:
    And that's fine and dandy. But we're discussing the internal representation of a ZIP code. I don't care how you'd implement the Swedish, Welsh, Mexican, or any other postal code, because they don't solve the problem of implementing a ZIP. Wanna subclass everything from an abstract postal code class? Hey, that's super. But save it for when you start writing a second potential subclass. Either way, I'm probably implementing ZIP with an int (actually, I'd probably go with char[5]).
    No, you're discussing the internal representation of a ZIP code. And a damn good job you're making of it too (even if I would argue that char[6] with a terminating '\0' would make it easier to implement ToString(), for example. But that's just a quibble. Or in fact two nibbles).

    And yes, an abstract postal code class would indeed be super. You have correctly hit the nail on the head.

  • Joseph Newton (unregistered) in reply to ssprencel
    ssprencel:
    zip:
    "9 mod 10 leaves you with 1"

    Have I seriously been doing mods wrong my entire life?

    Have you seriously been doing mods your entire life? I didn't get started until I got into programming. ;)

    Really? I started in elementary school. I didn't start calling them modulus until I got into programming, though--in grade school we called them "remainder"

  • Franz Kafka (unregistered) in reply to Welbog
    Welbog:
    Will:
    If you assume that the number 10 (and none of the others) is an octal representation, then sure, 9 mod 10 == 1.
    It could also be base 4, while we're making silly assumptions.

    Nah, 9 isn't a number in base 4. Not in base 8 either.

Leave a comment on “Checking Your Digits”

Log In or post as a guest

Replying to comment #:

« Return to Article