• (cs)

    "9 mod 10 leaves you with 1"

    Have I seriously been doing mods wrong my entire life?

  • Troy Mclure (unregistered)

    Dammit this is why my Better Homes and Gardens always arrives late!

  • (cs)

    And here I thought 9 MOD 10 was 9, and ABS(9 - 10) was 1.

  • (cs)

    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.

  • foo (unregistered) in reply to vertagano
    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.

  • Will (unregistered)

    If you assume that the number 10 (and none of the others) is an octal representation, then sure, 9 mod 10 == 1.

  • (cs) in reply to Will
    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.
  • Something Like A Name (unregistered) in reply to zip

    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).

  • dkfal (unregistered)

    9 mod 10 = 1??

    i think i need some antioxidants with vitamins to recover from that...

    weeeee

  • anon (unregistered) in reply to Will 
     if(zipcode>=00000)
     ...
        if(zipcode>=00)

    Umm, is this another WTF - treating numbers as strings?

  • MX5Ringer (unregistered)

    Good Brief!!!!

    Thats even worse than anything I'd do!

    (On the plus side, it looks like boobs if you squint!)

    Captcha:- poindexter (Not bad for a lab assistant!) (Ok I don't know who he is, I looked him up on Wiki)

  • Troy Mclure (unregistered) in reply to anon
    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

  • MX5Ringer (unregistered) in reply to Troy Mclure

    So in their almost 'C' language they didn't need to distinguish between text strings and numeric values??

    Forgive my ignorance, I don't do 'C' so this might be a stupid question.

    Captcha:- gotcha (perhaps you have!)

  • kanna (unregistered) in reply to Troy Mclure
    :
    The check digit is calculated by adding up all the digits of the barcode, throwing away the tens place, and modding the rest by 10. So, if all the digits of the barcode add up to 39, you ignore the 3, and 9 mod 10 leaves you with 1. Couldn't be simpler, right?

    Assuming it really is 9 Mod 10 we want (the one that *doesn't equal one) than you could really just only pay attention to what's left after "throwing away the tens place" (assuming it's <= 99). Of course, you could just Mod the whole thing by 10 and get the same result... without "Throwing away the tens place".. meh, whatever.

  • (cs)

    Is there any case where this "throw away the 10s place" operation is different than % 10?

    I guess they meant c = 10 - (n % 10).

  • (cs) in reply to Troy Mclure
    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?

  • Doh! (unregistered)

    You know, if they had brute-forced every possible zip code and hard coded the result for each, it still wouldn't have been much more code than what was written. nausea sets in

  • (cs) in reply to Troy Mclure
    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

    True, ZIP Codes are not numbers, but 000 in every language I know is a number. The missed the quotation marks to make it a string, "000"...

  • Troy Mclure (unregistered) in reply to zip
    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

  • (cs) in reply to Troy Mclure
    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

    I hate to get all Sesame-Streety about this, but:

    Numbers are numbers. Strings are string. Zip codes are zip codes.

    The statement that "Zip codes ... are strings" is an example of the sort of category error that brings us the diseased syntax of XML (where metadata is forced in-band and considered as a string), or SQL injection errors, or indeed the WTF in the OP.

  • John (unregistered) in reply to vt_mruhlin

    According to Wikipedia, there's a special case when the number % 10 == 0: the answer == 0. Some nice code that works in python, however (and possibly in c, I forget how the handle negative mods): c = -n % 10;

  • chesta (unregistered) in reply to zip
    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?

  • Troy Mclure (unregistered) in reply to real_aardvark
    I hate to get all Sesame-Streety about this, but:

    Numbers are numbers. Strings are string. Zip codes are zip codes.

    The statement that "Zip codes ... are strings" is an example of the sort of category error that brings us the diseased syntax of XML (where metadata is forced in-band and considered as a string), or SQL injection errors, or indeed the WTF in the OP.

    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

  • MX5Ringer (unregistered) in reply to real_aardvark

    But we arn't talking about zip codes here, we are talking about check digits and the method used to create them, which in this case is very much arithmatic based, unlike Postcodes in the UK for example which have no check digit and so are considered Postcodes not Strings or Numbers.

  • (cs)

    a language "like C, but not quite"? Sounds like NQC to me!

    http://bricxcc.sourceforge.net/nqc/

  • MX5Ringer (unregistered) in reply to MX5Ringer

    I'm even confusing myself now,

    Where does it say that the barcode is actually the zip code anyway?

    (for clarity:- UK postcodes contain numbers and letters)

  • iToad (unregistered)

    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.

  • (cs)

    The goggles! They do nothing!

  • me, me (unregistered)

    International Standard Book Number system has 11 digits, so the check "digit" can be 0-9 or X.

  • iToad (unregistered) in reply to MX5Ringer

    The check digit is part of the bar code that is printed on mail within the US:

    From the font of all knowledge:

    http://en.wikipedia.org/wiki/POSTNET

    To calculate the check digit, you add up all the digits, take the result modulo 10, and then subtracting this value from 10.

    The poster's minor error in specifying how the check digit is calculated does not change the fact that the code is an absolute horror. This is the type of code you get when the programmer is ignorant, incompetent, or paid by lines of code produced.

  • (cs) in reply to zip
    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. ;)

  • (cs) in reply to Troy Mclure
    Troy Mclure:
    I hate to get all Sesame-Streety about this, but:

    Numbers are numbers. Strings are string. Zip codes are zip codes.

    The statement that "Zip codes ... are strings" is an example of the sort of category error that brings us the diseased syntax of XML (where metadata is forced in-band and considered as a string), or SQL injection errors, or indeed the WTF in the OP.

    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

    Caught any good bass recently with your baited breath?

    Well, it's been over ten minutes, so there's a good chance that cyanosis has taken you out of the gene pool by now. I'm guessing that you're a VB programmer. VB, the language for programmers who find Sesame Street too intellectually taxing ...

    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.

    They are, in fact, zip codes.

    In passing, I suppose you could consider them as a sub-class of co-ordinates, but I'd rather you write the transformation functions than I.

    Still sitting comfortably? Good. I'll bring the Honey Monster over to sit on your head. It's for the best, really.

  • nickf (unregistered) 
            if(zipcode>=10)
        if(zipcode<20){
          if(zipcode>=0){
            if(zipcode>=1){
              if(zipcode>=2){
                if(zipcode>=3){
                  if(zipcode>=4){
                    if(zipcode>=5){
                      if(zipcode>=6){
                        if(zipcode>=7){
                          if(zipcode>=8){
                            if(zipcode>=9){
                              counter+=0;

    Has anyone noticed that in this block of code, if the first conditional passes, the entire block must be true? Maybe they're coding in redundancy in case one day they switch to a different number system where zipcode >= 10 is true, but zipcode >= 1,2,3...9 might not be.

    does anyone get the feeling that anonymisation process on this code has changed it? Like, I mean really, not even business students would be stupid enough to check that a number is bigger then 1, then 2, then 3 all the way up to 9 AFTER they checked it was bigger than 10 to start with.

  • me, me (unregistered) in reply to me, me

    Well, actually 10 including the check digit, until this year. They've added two more digits since January 1, 2007.

    Each of the first 9 digits of the 10-digit ISBN is multiplied by a number in a sequence from 10 to 2, the sum of which then gets the MOD 11 treatment, and the remainder is the check digit - except if it is 10, in which case the check digit is X (or FileNotFound).

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

    feed it an international postal code, and watch it choke!

    I work in the book industry... you'd be suprised how many publishers/distributors there are out there that have labeling systems that will allow a barcode to be printed with an invalid check digit... For some reason, the very simple process of caclulating a check digit seems to make most people forget how to program, or for that matter think.

  • Troy Mclure (unregistered) in reply to real_aardvark
    real_aardvark:
    Troy Mclure:
    I hate to get all Sesame-Streety about this, but:

    Numbers are numbers. Strings are string. Zip codes are zip codes.

    The statement that "Zip codes ... are strings" is an example of the sort of category error that brings us the diseased syntax of XML (where metadata is forced in-band and considered as a string), or SQL injection errors, or indeed the WTF in the OP.

    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

    Caught any good bass recently with your baited breath?

    Well, it's been over ten minutes, so there's a good chance that cyanosis has taken you out of the gene pool by now. I'm guessing that you're a VB programmer. VB, the language for programmers who find Sesame Street too intellectually taxing ...

    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.

    They are, in fact, zip codes.

    In passing, I suppose you could consider them as a sub-class of co-ordinates, but I'd rather you write the transformation functions than I.

    Still sitting comfortably? Good. I'll bring the Honey Monster over to sit on your head. It's for the best, really.

    No I am not a VB programmer. I actually sell paintings under the 101. Maybe you've seen me - Painting by Troy. And you can throw all the fucking semantics you want at me. I'm not very impressed.

  • Andy (unregistered)
    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 of the internal algorithms

  • AndyG (unregistered)
    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.

  • (cs) in reply to WeatherGod
    WeatherGod:
    a language "like C, but not quite"? Sounds like NQC to me!

    http://bricxcc.sourceforge.net/nqc/

    Woo! We wrote a lot of stuff in NQC a few years back for my robotics class in college when we were learning to do simple search routines and whatnot. Good times :)

  • Michael (unregistered) in reply to nickf
    nickf:
            if(zipcode>=10)
        if(zipcode<20){
          if(zipcode>=0){
            if(zipcode>=1){
              if(zipcode>=2){
                if(zipcode>=3){
                  if(zipcode>=4){
                    if(zipcode>=5){
                      if(zipcode>=6){
                        if(zipcode>=7){
                          if(zipcode>=8){
                            if(zipcode>=9){
                              counter+=0;
    Has anyone noticed that in this block of code, if the first conditional passes, the entire block must be true? Maybe they're coding in redundancy in case one day they switch to a different number system where zipcode >= 10 is true, but zipcode >= 1,2,3...9 might not be.

    does anyone get the feeling that anonymisation process on this code has changed it? Like, I mean really, not even business students would be stupid enough to check that a number is bigger then 1, then 2, then 3 all the way up to 9 AFTER they checked it was bigger than 10 to start with.

    Think of zipcode as a string, and the numbers being compared as getting cast as strings. Thus "23456" is >= "10", but not >= "3", when doing string comparisons.

    CAPTCHA: Sanitarium - Where management should go for letting business students to programming.

  • Jules (unregistered) in reply to Troy Mclure
    Troy Mclure:
    I hate to get all Sesame-Streety about this, but:

    Numbers are numbers. Strings are string. Zip codes are zip codes.

    The statement that "Zip codes ... are strings" is an example of the sort of category error that brings us the diseased syntax of XML (where metadata is forced in-band and considered as a string), or SQL injection errors, or indeed the WTF in the OP.

    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

    If you practice that long enough, you'll become a master. Then you'll be sitting there with master baited breath.

  • (cs) in reply to iToad
    iToad:
    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.
    Additionally, integral literals prefixed with 0 in C-style languages are octal, not decimal. That's almost certainly not what they meant to do. If this was an error in transcribing the code, and they were actually represented as strings, then that's not an issue.
  • Rolf (unregistered)

    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?

  • (cs) in reply to chesta
    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.

  • Bishoy (unregistered)

    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.

  • (cs) in reply to Rolf
    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?

    Well I won't write the code for you (not that much time here at work) but I will give you the pseudo-code I would use and you can have fun pulling it apart and seeing just how to write it yourself. I'm not sure what the actual calculation is for checksums, sometimes it is alternating 1 and 10 multipliers sometimes it is decrementing position values. You will have to find that yourself, but it is an easily reproducible pattern.

    Assuming just 5 digit zip codes.

    Loop through Char 0 to 4 Convert char to a number Apply the checksum addition to the number and save to result End loop Mod 10 the result to get the checksum

  • (cs) in reply to Thuktun
    Thuktun:
    Additionally, integral literals prefixed with 0 in C-style languages are octal, not decimal. That's almost certainly not what they meant to do. If this was an error in transcribing the code, and they were actually represented as strings, then that's not an issue.

    It's not an error in the transcription, it's what you get when you embed a "C-like" language in your product and the language subtly unlike C.

  • JRoyale (unregistered)

    The real nightmare is here

    They got a list of postal codes that were not in use and deleted the lines for those ZIP ranges from their pyramids of power.

    The UPS does adds zipcodes from time to time, which would require this ... um ... code to be kept in sync.

  • JRoyale (unregistered) in reply to JRoyale
    JRoyale:
    UPS

    I mean the USPS.

  • Paul (unregistered)

    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. ;]

Leave a comment on “Checking Your Digits”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article