• (cs) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.

    I'm surprised that more IDEs do not simplify it for you.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

    Dim oct As UShort = &O777
  • (cs) in reply to Jim the Tool
    Jim the Tool:
    I timesed by zero once. Nothing happened.

    I then divided by zero. Black hole.

    Bugger.

    The real WTF is that people put up with a crappy coder who also doesn't have good interpersonal skills, and can't take criticism. If it were only the first, it might be OK (send them to testing). If it were only the last two, it might be OK (don't interact with them?).

    But altogether, I don't know why you'd not fire Mark.

    Nah, just wait for the next round of redundancies. Better still, if he's that loud and forceful, he'll ace his next job interview. Pretend to be a recruiting agency, hunt for a competitor company you don't like, and introduce them to each other.

  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

    What goes: "Pieces of ten, pieces of ten, pieces of ten!" An octal parrot. What goes: "Pieces of eleven, pieces of eleven, pieces of eleven!" A parroty error.

  • fizzbuzz (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Pretend to be a recruiting agency, hunt for a competitor company you don't like, and introduce them to each other.

    I think there's a real business idea here. Start a recruiting company, but your business plan is a little different: for a s̷m̷a̷l̷l̷ moderate fee, we get your annoying co-workers hired away to somewhere else.

    It's beautiful - think of the repeat business! "Hey guys, we've got Ted Jones again - third time this year."

  • n_slash_a (unregistered)

    Mark's Boss: "The timeout is too short." Mark: "FINE! I'LL MAKE IT LONGER!!"

     timeout = timeout + 0
    Mark's Boss: "The timeout is still too short." Mark: "FINE! I'LL MAKE IT EVEN LONGER!!"
     timeout = timeout + 0 + 0
    Mark's Boss: "The timeout is still too short. Don't just extend it, refactor it this time." Mark: "FINE! I'LL MAKE THE TIMEOUT REALLY REALLY LONG!!"
     timeout = timeout + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0
    Head, meet desk.

  • Tux "Tuxedo" Penguin (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

    Then maybe use specific prefix for octal numbers? Like 0x denounces hex numbers, maybe 8x should denounce octals?

  • S (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Then maybe use specific prefix for octal numbers? Like 0x denounces hex numbers, maybe 8x should denounce octals?

    That would be 0o prefix, since the 'x' is 0x is what signifies hex (newer versions of Java also support 0b for binary). And I believe some languages do use a 0o prefix, but unfortunately, most C-family languages have inherited the unfortunate 0 prefix behaviour...

  • YellowOnline (unregistered) in reply to Tux "Tuxedo" Penguin

    To be honest, if someone wants to add leading zeros for intending reasons to enhance readability, I have no issue with that.

    Very simple example:

    $var1 = 001
    $var2 = 023
    $var3 = 104
    

    I can imagine scenarios where this can avoid errors.

  • Spencer (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    ¯\(°_o)/¯ I DUNNO LOL:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

    Then maybe use specific prefix for octal numbers? Like 0x denounces hex numbers, maybe 8x should denounce octals?

    0o or even just o is already used in some languages, likewise 0b is used for binary-coded numbers (in pretty much every language based on or deriving from C). Although, each language seems to think it can be confused with something else

    Wikipedia:
    Newer languages have been abandoning the prefix 0, as decimal numbers are often represented with leading zeroes. The prefix q was introduced to avoid the prefix o being mistaken for a zero, while the prefix 0o was introduced to avoid starting a numerical literal with an alphabetic character (like o or q), since these might cause the literal to be confused with a variable name.

    I can only imagine the progression of dialogue that lead back to using 0o, and probably around and around a few more times.[tation needed]

  • J (unregistered) in reply to YellowOnline

    It's a surprising bug lying plain sight: $var2 is assigned 19 in decimal. 023 is octal notation.

  • Norman Diamond (unregistered) in reply to anonymous
    anonymous:
    anonymous:
    Jonathan was tempted to point out that Mark's attempt to express the number of milliseconds in a second was off by an order of magnitude or two
    Or infinitely many, but who's counting?
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    [image]K, you knew this was coming.
  • Norman Diamond (unregistered) in reply to YellowOnline
    YellowOnline:
    To be honest, if someone wants to add leading zeros for intending reasons to enhance readability, I have no issue with that.

    Very simple example:

    $var1 = 001
    $var2 = 023
    $var3 = 104
    

    I can imagine scenarios where this can avoid errors.

    If the values used to be one, twenty-three, and one hundred four, and after adding leading zeroes the values are one, nineteen, and one hundred four, are you sure this can avoid errors?

    Meanwhile, [image] is a bigger leading zero.

  • (cs) in reply to Developer Dude
    Developer Dude:
    I'm trying to multiply, but nothin' happens!
    • several internets for invoking Curly.
  • Jim (unregistered) in reply to anonymous
    anonymous:
    anonymous:
    Jonathan was tempted to point out that Mark's attempt to express the number of milliseconds in a second was off by an order of magnitude or two
    Or infinitely many, but who's counting?
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    Ferrous metaly
  • Pinkie (unregistered) in reply to cowardly man
    cowardly man:
    What ever happened to providing user feedback via text that says what the installer is doing. if it is on the same step for an hour, something went wrong.
    *opening a can of worms*

    Can something be longer without being larger?

  • hohum (unregistered) in reply to cowardly man
    cowardly man:
    What ever happened to providing user feedback via text that says what the installer is doing. if it is on the same step for an hour, something went wrong.
    That's what I used to think, then I let it go all day, and it actually installed!
  • Johnny Cash (unregistered) in reply to anonymous
    anonymous:
    cellocgw:
    MonkeyCoder:
    TRWTF is Jonathan's timidity (and the entire team's, really) in the face of a blowhard who uses bluster and intimidation instead of logic and skill.

    Problem is: Mark's the President's daughter and can never be fired.

    She prefers to be called Sue now, you insensitive clod.

    captcha: transverbero

    Oh, a boy named Sue...who's infringing my copyright?

  • aeradha (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    like it does on my phine number's area code?

    I can't believe we still need 0s in the 21st century

  • Jim (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    Octal is a thing. C started on DEC CPUs where data was traditionally represented in octal. That being said, about the only mainstream use of octal anymore is Unix file permissions, though I'm sure there are specific cases where it comes in handy.

    Maybe some IDEs display octal numbers in a different color than decimal (I just checked, and the one I normally use doesn't), but perhaps "warn me if octal ever happens" could be a compiler option. The problem is that the people who understand what it is and why to turn on such a warning are the only ones who would know to turn it on. The rest will be completely clueless even when the compiler throws an error on "009".

    Re Unix file permissions, that just happens to be a 3 bit bitfield.....it's not really got anything to do with octal, other than the max of a bitfield of size x will be ( 2^x -1 ).

    I would not be callin' him octal, even though each element can only be 0-7 (and some of them numbers not be much use)

  • Microsoft (unregistered) in reply to cowardly man
    cowardly man:
    What ever happened to providing user feedback via text that says what the installer is doing. if it is on the same step for an hour, something went wrong.
    http://support.microsoft.com/kb/928957 Service pack installation takes longer than the original product installation: Installing Visual Studio 2005 SP1 takes longer than installing the original release version because the SP1 installation is much like a product installation, but with additional installation tasks. Installation time depends on which product is installed and the computer’s configuration.

    http://weblogs.asp.net/scottgu/visual-studio-2005-service-pack-1-sp1-released The service pack itself is a fairly large download (431Mb), and can take 30-90 minutes to update your Visual Studio 2005 installation depending on which versions of VS you have installed, and what features are enabled. So you should plan ahead and not expect it to be a few second operation (note: it is a good task to kick off before lunch or in the evening).

  • QJo (unregistered) in reply to aeradha
    aeradha:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    like it does on my phine number's area code?

    I can't believe we still need 0s in the 21st century

    Oh good grief. TRWTF is implementing telephone numbers as integers. One of the stupidest of the common misdesign decisions ever. Nearly as stupid as implementing zip codes as integers.

  • (cs) in reply to fizzbuzz
    fizzbuzz:
    I think there's a real business idea here. Start a recruiting company, but your business plan is a little different: for a s̷m̷a̷l̷l̷ moderate fee, we get your annoying co-workers hired away to somewhere else.
    Those companies did (do?) actually exist.

    Over here in Dutchland, it's not easy to get rid of employees. But there is usually a sort of trial period of 1 or 2 months when starting in a new job, during which either side can simply terminate the contract. Back in the zeroes, during the first "dotcom crisis", there were some recruiting companies that would recruit (for a fee) employees you'd want to get rid of, to have them fired on or even before their first day in the new (fakeish) job.

    Problem is, when the word gets out, business ends.

  • Ziplodocus (unregistered) in reply to QJo
    QJo:
    aeradha:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    like it does on my phine number's area code?

    I can't believe we still need 0s in the 21st century

    Oh good grief. TRWTF is implementing telephone numbers as integers. One of the stupidest of the common misdesign decisions ever. Nearly as stupid as implementing zip codes as integers.

    It depends entirely on where those numbers come from and where/how they are to be used.

    I'm always suspicious of any statement that has always in it and never trust one with a never.

  • (cs)

    Incompetent and a dick. The full package.

    And he's single, ladies!

  • QJo (unregistered) in reply to Ziplodocus
    Ziplodocus:
    QJo:
    aeradha:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    like it does on my phine number's area code?

    I can't believe we still need 0s in the 21st century

    Oh good grief. TRWTF is implementing telephone numbers as integers. One of the stupidest of the common misdesign decisions ever. Nearly as stupid as implementing zip codes as integers.

    It depends entirely on where those numbers come from and where/how they are to be used.

    I'm always suspicious of any statement that has always in it and never trust one with a never.

    Are you going to use arithmetic on them? No? Then they should not be implemented as numbers. You are going to use arithmetic on phone numbers and zip codes? What on earth for?

  • EvilSnack (unregistered) in reply to anonymous
    anonymous:
    ¯\(°_o)/¯ I DUNNO LOL:
    nerd4sale:
    anonymous:
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    Yes it does. 0000000000 is clearly larger then 00.
    Even Las Vegas knows they're different, they have both 0 and 00 on roulette wheels! Or maybe 00 is just the octal version.
    File that under "reasons why competent mathematicians don't play roulette".
    FTFY.
  • Ziplodocus (unregistered) in reply to QJo
    QJo:
    Are you going to use arithmetic on them? No? Then they should not be implemented as numbers. You *are* going to use arithmetic on phone numbers and zip codes? What on earth *for*?

    Oops, implementing. My brain interpreted that as storing. I never seem to get that right and always make that mistake.

    CAPTCHA: ideo(t)

  • nmclean (unregistered) in reply to anonymous
    anonymous:
    anonymous:
    Jonathan was tempted to point out that Mark's attempt to express the number of milliseconds in a second was off by an order of magnitude or two
    Or infinitely many, but who's counting?
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    But that sentence had nothing to do with the number being multiplied on the left. It said the expression of milliseconds in a second was off, meaning compared to the correct expression of it, i.e. 0 versus 1000.

    The order of magnitude of 0 is undefined, I suppose. But assuming that the value of timeOut is 100, you could accurately say that the total was off by two orders of magnitude from its intended value.

  • anonymous (unregistered) in reply to nmclean
    nmclean:
    anonymous:
    anonymous:
    Jonathan was tempted to point out that Mark's attempt to express the number of milliseconds in a second was off by an order of magnitude or two
    Or infinitely many, but who's counting?
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    But that sentence had nothing to do with the number being multiplied on the left. It said the expression of milliseconds in a second was off, meaning compared to the correct expression of it, i.e. 0 versus 1000.

    The order of magnitude of 0 is undefined, I suppose. But assuming that the value of timeOut is 100, you could accurately say that the total was off by two orders of magnitude from its intended value.

    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    captcha: distineo

  • nmclean (unregistered) in reply to Jim
    Jim:
    Re Unix file permissions, that just happens to be a 3 bit bitfield.....it's not really got anything to do with octal, other than the max of a bitfield of size x will be ( 2^x -1 ).
    Uh... that is literally what octal is. The whole reason octal and hex literals exist is as convenient representations of bit fields. 3-bit = octal, 4-bit = hex.
  • n9ds (unregistered)

    There's an old saying, "Twice nothing is still nothing." Usuaully refers to my paycheck, but can apply elsewhere too.

  • nmclean (unregistered) in reply to anonymous
    anonymous:
    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    You misunderstood my last sentence. I said the total would be two orders of magnitude off the intended value, if timeOut was 100. Given [i]timeOut + 10 * 000[/code], the intended total value would be 100 + 10,000 = 10100. The actual value would be 100 + 0 = 100. The difference in the orders of magnitude between 100 and 10100 is two.

    And again zero's order of magnitude is undefined, not negative infinity -- infinitely small isn't the same as zero.

  • anonymous (unregistered) in reply to anonymous
    anonymous:
    nmclean:
    anonymous:
    anonymous:
    Jonathan was tempted to point out that Mark's attempt to express the number of milliseconds in a second was off by an order of magnitude or two
    Or infinitely many, but who's counting?
    I do find it a little bit ironic that the "order of magnitude or two" has the same error that Mark's fix had. Multiplying 0 by a larger number - whether it's 10 or 60 or 100 - doesn't make it any larger.
    But that sentence had nothing to do with the number being multiplied on the left. It said the expression of milliseconds in a second was off, meaning compared to the correct expression of it, i.e. 0 versus 1000.

    The order of magnitude of 0 is undefined, I suppose. But assuming that the value of timeOut is 100, you could accurately say that the total was off by two orders of magnitude from its intended value.

    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    captcha: distineo

    Or, to put it in more mathematical terms, although the order of magnitude is technically undefined since the logarithm of 0 is undefined, if you take the mathematical limit you can clearly see that as the number that you're comparing to 100 approaches zero, the order of magnitude between them approaches positive infinity:

      lim  (log10 100 - log10 x) = ∞ x → 0+

  • Whatever (unregistered) in reply to n_slash_a

    I mean, if the compiler does not strip the + 0 it does get longer to compute this.

    Given enough useless adding maybe it'll succeed (if this is actually done in another thread as the actual install).

  • anonymous (unregistered) in reply to nmclean
    nmclean:
    anonymous:
    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    You misunderstood my last sentence. I said the total would be two orders of magnitude off the intended value, if timeOut was 100. Given [i]timeOut + 10 * 000[/code], the intended total value would be 100 + 10,000 = 10100. The actual value would be 100 + 0 = 100. The difference in the orders of magnitude between 100 and 10100 is two.

    And again zero's order of magnitude is undefined, not negative infinity -- infinitely small isn't the same as zero.

    Well, that's what I said. The article said "the number of milliseconds in a second was off by an order of magnitude or two". The number of milliseconds in a second is 1000. The number he wrote is 0. There are infinitely many orders of magnitude between 1000 and 0.

    You're also correct, in that the total difference was only a couple of orders of magnitude. But the article specifically said that the number of milliseconds in a second was what was being compared, not the total result of the expression.

  • Paul Neumann (unregistered) in reply to anonymous
    anonymous:
    nmclean:
    anonymous:
    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    You misunderstood my last sentence. I said the total would be two orders of magnitude off the intended value, if timeOut was 100. Given [i]timeOut + 10 * 000[/code], the intended total value would be 100 + 10,000 = 10100. The actual value would be 100 + 0 = 100. The difference in the orders of magnitude between 100 and 10100 is two.

    And again zero's order of magnitude is undefined, not negative infinity -- infinitely small isn't the same as zero.

    Well, that's what I said. The article said "the number of milliseconds in a second was off by an order of magnitude or two". The number of milliseconds in a second is 1000. The number he wrote is 0. There are infinitely many orders of magnitude between 1000 and 0.

    You're also correct, in that the total difference was only a couple of orders of magnitude. But the article specifically said that the number of milliseconds in a second was what was being compared, not the total result of the expression.

    And the magnitude of 5 and 5.0000 should differ? The magnitude is determined by the value of the most significant digit. 0 would be the most significant digit in 0.0000 as 1 would be the most significant digit in 0.0001. The difference in magnitude would be -4.

  • Not Hans (unregistered) in reply to QJo
    QJo:
    Ziplodocus:
    QJo:
    aeradha:
    Tux "Tuxedo" Penguin:
    TRWTF is compilers accepting numbers with leading zeroes. Anything like 01, 006, 000 should throw an error.
    like it does on my phine number's area code?

    I can't believe we still need 0s in the 21st century

    Oh good grief. TRWTF is implementing telephone numbers as integers. One of the stupidest of the common misdesign decisions ever. Nearly as stupid as implementing zip codes as integers.

    It depends entirely on where those numbers come from and where/how they are to be used.

    I'm always suspicious of any statement that has always in it and never trust one with a never.

    Are you going to use arithmetic on them? No? Then they should not be implemented as numbers. You are going to use arithmetic on phone numbers and zip codes? What on earth for?

    Auto-dialer.

  • Reductio Ad Ridiculousum (unregistered) in reply to Pinkie
    Pinkie:
    cowardly man:
    What ever happened to providing user feedback via text that says what the installer is doing. if it is on the same step for an hour, something went wrong.
    *opening a can of worms*

    Can something be longer without being larger?

    It's not how long you make it, it's how you make it long.

  • Norman Diamond (unregistered) in reply to QJo

    [quote user="QJo"][quote user="Ziplodocus"]Oh good grief. TRWTF is implementing telephone numbers as integers. One of the stupidest of the common misdesign decisions ever. Nearly as stupid as implementing zip codes as integers.[/quote]It depends entirely on where those numbers come from and where/how they are to be used.

    I'm always suspicious of any statement that has always in it and never trust one with a never.[/quote]Are you going to use arithmetic on them? No? Then they should not be implemented as numbers. You are going to use arithmetic on phone numbers and zip codes? What on earth for?[/quote]Array indices. Not always, but not never.

    Or they might get hashed and the hash values will be array indices. Not always, but never.

    I always never recommend absolutes.

  • F (unregistered) in reply to gnasher729
    gnasher729:
    Nagesh:
    I am in favor of promoting Mark out of development team so he can no longer do any harm to code-base.

    Well, I'd personally ask him very quietly what is wrong with the code. And if he starts shouting, I'd use every single opportunity to tell everyone very quietly that I'm still waiting for an apology for shouting at me when I pointed out the most stupid bug ever in his code.

    Come off it. A man of his calibre is bound to have done something even stupider. You just haven't looked hard enough.

  • James Bond (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Or they might get hashed and the hash values will be array indices. Not always, but never.
    You can't even quote without fucking up. It's not never, it's not never. Never say never.
  • Jeremy (unregistered) in reply to cyborg

    It's common enough -- if you make a code change and don't test it (because "it's such a simple change that no test is necessary") then you won't notice that the code is not actually working. :^P

  • anonymous (unregistered) in reply to Paul Neumann
    Paul Neumann:
    anonymous:
    nmclean:
    anonymous:
    No! You're forgetting decimals. The order of magnitude of 0 is negative infinity.

    100 is two orders of magnitude off 1, three orders of magnitude off 0.1, four orders of magnitude off 0.01, ... the more zeros you have before you reach a 1 digit, the more orders of magnitude difference there is; 100 is infinitely many orders of magnitude off 0, which is 0.000... (a 1 digit never occurs).

    You misunderstood my last sentence. I said the total would be two orders of magnitude off the intended value, if timeOut was 100. Given [i]timeOut + 10 * 000[/code], the intended total value would be 100 + 10,000 = 10100. The actual value would be 100 + 0 = 100. The difference in the orders of magnitude between 100 and 10100 is two.

    And again zero's order of magnitude is undefined, not negative infinity -- infinitely small isn't the same as zero.

    Well, that's what I said. The article said "the number of milliseconds in a second was off by an order of magnitude or two". The number of milliseconds in a second is 1000. The number he wrote is 0. There are infinitely many orders of magnitude between 1000 and 0.

    You're also correct, in that the total difference was only a couple of orders of magnitude. But the article specifically said that the number of milliseconds in a second was what was being compared, not the total result of the expression.

    And the magnitude of 5 and 5.0000 should differ? The magnitude is determined by the value of the most significant digit. 0 would be the most significant digit in 0.0000 as 1 would be the most significant digit in 0.0001. The difference in magnitude would be -4.
    LOL. Zero is never a significant digit.

    An order of magnitude is a factor of 10 (canonically, although I suppose it could be a factor of any number if you weren't so picky).

    How many times do you multiply zero by ten to make it similar in magnitude (within a factor of ten) of 0.0001?

    Good luck with that. I'll be sitting here counting until you figure out that your zero isn't getting any bigger.

  • (cs) in reply to anonymous
    anonymous:
    LOL. Zero is never a significant digit.

    An order of magnitude is a factor of 10 (canonically, although I suppose it could be a factor of any number if you weren't so picky).

    How many times do you multiply zero by ten to make it similar in magnitude (within a factor of ten) of 0.0001?

    Good luck with that. I'll be sitting here counting until you figure out that your zero isn't getting any bigger.

    You must have failed Chemistry (and/or Math) 101.

    "100."

    Both zeroes are significant.

  • Bill C. (unregistered) in reply to anonymous
    anonymous:
    LOL. Zero is never a significant digit.
    Wrong. My 21st digit is legendary. Sometimes it goes missing, not often, but sometimes. But even when it's a zero, it's still very significant.
  • anonymous (unregistered) in reply to chubertdev
    chubertdev:
    anonymous:
    LOL. Zero is never a significant digit.

    An order of magnitude is a factor of 10 (canonically, although I suppose it could be a factor of any number if you weren't so picky).

    How many times do you multiply zero by ten to make it similar in magnitude (within a factor of ten) of 0.0001?

    Good luck with that. I'll be sitting here counting until you figure out that your zero isn't getting any bigger.

    You must have failed Chemistry (and/or Math) 101.

    "100."

    Both zeroes are significant.

    No they are not. The 1 is significant, and it's in the hundreds place. The zeros are nothing more than placeholders to show you where the 1 is, relative to the decimal point. Same as 0.01 has only one significant digit - also the 1.

    captcha: damnum damnum, I gotta explain all this?

  • anonymous (unregistered) in reply to Bill C.
    Bill C.:
    anonymous:
    LOL. Zero is never a significant digit.
    Wrong. My 21st digit is legendary. Sometimes it goes missing, not often, but sometimes. But even when it's a zero, it's still very significant.
    "Goes missing"? I'm sorry, it must be hard living with that condition.
  • (cs) in reply to anonymous
    anonymous:
    chubertdev:
    anonymous:
    LOL. Zero is never a significant digit.

    An order of magnitude is a factor of 10 (canonically, although I suppose it could be a factor of any number if you weren't so picky).

    How many times do you multiply zero by ten to make it similar in magnitude (within a factor of ten) of 0.0001?

    Good luck with that. I'll be sitting here counting until you figure out that your zero isn't getting any bigger.

    You must have failed Chemistry (and/or Math) 101.

    "100."

    Both zeroes are significant.

    No they are not. The 1 is significant, and it's in the hundreds place. The zeros are nothing more than placeholders to show you where the 1 is, relative to the decimal point. Same as 0.01 has only one significant digit - also the 1.

    captcha: damnum damnum, I gotta explain all this?

    "100" != "100."

    "100" means that only the 1 is significant, so it could be 101. "100." means that all three are significant digits, so it can't be 101.

Leave a comment on “Sound and Fury, Implementing Nothing”

Log In or post as a guest

Replying to comment #:

« Return to Article