• (cs)

    I saw this wtf, had a great stack of CD's and yotta yotta yotta, I landed on the moon.

  • (cs) in reply to joost
    joost:
    Am I the only one that thinks 'kibibytes', 'mibibytes', 'gibibytes' and what, 'tebibytes'(?) sound absurdly childish? It makes me think of the Teletubbies (HORROR!). I strongly object to this 10**x scheme of 'a kilobyte is 1000 bytes', no matter how many IEEE, ISO and marketing committees they throw at it. And the SI not an argument either. A bit has two possible values, not ten.

    1 km = 10**3 meter
    1 kg = 10**3 gram
    1 megaton = 10**6 ton
    1 ml = 1/10**3 liter
      :
    <insert your="" favorite="" unit="" here="">
      :
    1 KB = 2**10 bytes

    Notice a pattern? I think it's obvious, when we say byte, we mean base 2, when we say any other unit (except for time), we're dealing in base 10. It wasn't confusing until those KiBiBytes came along. Now you have to wonder whether a person would say KiBiByte to find out if they mean 1024 or 1000 by kilobyte.


    That would be fine and dandy if bytes were always measured in powers of 1024, but network transmission rates, for instance (like "gigabit"), are not.  I believe harddrive manufacturers also got in trouble for misrepresenting their harddrive sizes because they used kilobytes (in the SI sense) and not kibibytes (traditional kilobytes).

    Now, in the few programs where I see "2.4 KiB", I actually know that it means 2.4*1024 and not 2.4*1000.  All it takes is a little "i" in the symbol, and even if you choose to continue pronouncing it "kilobytes," it still helps to know which is meant.

    And isn't it illegal in some jurisdictions for "kilo" to mean anything but 1000?

    And what about bits instead of bytes?  A kilobit is generally 1000 bits (because they are more often used in network transmission rates), while a kilobyte is 1024 bytes.  That makes no sense.

    I thought it was silly at first, but I have to constantly remind myself whether Windows Explorer means 1000 bytes or 1024 bytes when it says 1KB, and I know for a fact that all programs are not consistant in this regard.
    </insert>
  • Pax (unregistered) in reply to Ben Cooke

    I've calculatyed this before.  It's early January or February, 2038 (hence the y2k38 bug) - unless you're posting from 2011, that's not 27 years.  If you are, can you please send through a few PDFs of sporting or lotto results for me?

    Pax

  • Michael (unregistered)

    Ok... I'm actually the programmer of this snippet.  I first heard of the daily WFT about two weeks ago, so when I got an email just now telling me my code was here, I kinda freaked out :)  I'm pleased to see that it's not so bad.

    As for why...
      a) why not?  You'll note that the length of the "symbols" list doesn't affect how you get to a given formatting.  It could have 1000 prefixes long and you still get to "k" in one step.  The only cost is storing that list.
      b) who says this is purely for addressing real data?  How much data do you need to describe the location of every atom in the solar system to within 1mm?  There are plenty of cryptographic examples as well.
      c) yes, it amused me.  I actually trolled around for a while to find the prefixes out that far.  I sure didn't know them off the top of my head :)

    Also, new versions allow for SI-based scaling (1000 rather than 1024).

  • Juenemann (unregistered) in reply to Pax

    Anonymous:
    I've calculatyed this before.  It's early January or February, 2038 (hence the y2k38 bug) - unless you're posting from 2011, that's not 27 years.  If you are, can you please send through a few PDFs of sporting or lotto results for me?

    Pax

    Venkatesh, is that you?

     

  • (cs)

    I think there was this d00d, who was able to look 100 years into future.

    He was able to create highway system that's available right now in the U.S.

    Now, what about the guy who has created that piece of code that seems to be the subject of ridiculousness?

  • Sten (unregistered) in reply to joost

    I believe that a bit does have 10 possible values, namely 0 and 1.

    Fun,

    Sten

  • Sten (unregistered)

    A stack of CDs worth 1 Yottabyte is way larger than just four times the distance to the moon!

    1 Yottabytes are 1024^8 = 1.2110^24 bytes.  A CD takes about 700 MB = 7.3410^8 bytes, so 1 Yottabytes would need 1.6510^15 CDs.  At about 1mm per CD, this stack is about 1.6510^12m high.  The moon is about 1 light second = 310^8m away, so the stack of CDs is way higher than just four times the distance to the moon, namely about 5500 times that distance.

    The distance to the sun is about 8.3 light minutes = 8.3    60310^8m = 1.5*10^11m, which is about a tenth of the height of the CD stack, so a stack of CDs worth 1 Yottabyte would go to the sun, and back, and there again, and back again, and there again, and back again, and there again, and back again, and there again, and back again.

    Fun,

    Sten

    PS: I need to restore a file from CD #19327343264632.  Could you please go get it for me? I'll wait...

  • Mic (unregistered)

    """In terms of Compact Discs, we'd need to build a stack high enough to reach the moon ... and back ... and there again ... and back again ... just to have a yottabyte worth of data."""

    WTF?

    Let's do the math:
    Average distance between moon and earth is 385000km, let's assume a double layer DVD, capable of holding 2* 4.7 GB (24.38GiB). A DVD is 1.2mm thick. A yottabyte is 1024^8, so we end up with a stack of DVDs:

    ceil((B    1024^8) / (8.76B*1024^3)) * 0.0012m / 385000km

    = 400.60 times the average distance between earth and moon surfaces.

  • Mikademus (unregistered) in reply to Mic

    /me too will continue to ignore the first-of-its-kind (?) event, that the actual author of the WTF'ed code appeared.

  • meren (unregistered) in reply to Michael

    Hi Micheal,


    Micheal:
    Ok... I'm actually the programmer of this snippet.  I first heard of the daily WFT about two weeks ago, so when I got an email just now telling me my code was here, I kinda freaked out :)  I'm pleased to see that it's not so bad.


    Actually i'm the one who responsible of this entry and it's nice to hear that you pleased to see your code here ;)


    OTOH, i think your code in YUM is pretty delicious.. Keep up the good work..



    Ciao,

    meren.

  • Welcome To The Machine (unregistered) in reply to Michael

    Anonymous:
    Ok... I'm actually the programmer of this snippet.  I first heard of the daily WFT about two weeks ago, so when I got an email just now telling me my code was here, I kinda freaked out :)  I'm pleased to see that it's not so bad.

    As for why...
      a) why not?  You'll note that the length of the "symbols" list doesn't affect how you get to a given formatting.  It could have 1000 prefixes long and you still get to "k" in one step.  The only cost is storing that list.
      b) who says this is purely for addressing real data?  How much data do you need to describe the location of every atom in the solar system to within 1mm?  There are plenty of cryptographic examples as well.
      c) yes, it amused me.  I actually trolled around for a while to find the prefixes out that far.  I sure didn't know them off the top of my head :)

    Also, new versions allow for SI-based scaling (1000 rather than 1024).

    Hey there, good job writing this code, I don't have a problem with it and I fully support the use of these top-end multipliers, I would have struggled but could probably have named all of them - I've got a physics degree and although we just use 1 x 10^24 or whatever, we sometimes like to put a name on our numbers... it can be a yotta fun. :-P

     

  • (cs) in reply to cowbert
    Anonymous:
    Every time I see "yotta" I think of those Japanese singers with the figleaf underwear that sing that song.


    OMG! The weird thing is that i know *exactly* what you are talking about.  Its so funny... but man, its weird.

        dZ.
  • (cs) in reply to Sten
    Anonymous:

    PS: I need to restore a file from CD #19327343264632.  Could you please go get it for me? I'll wait...


    Sorry man, it melted... along with the floppy stack.

        dZ.
  • Chris Brien (unregistered) in reply to Sten
    Anonymous:
    I believe that a bit does have 10 possible values, namely 0 and 1.

    Fun,

    Sten
    Of course, by that logic, one kilobyte, should be 10^3 bytes - ie 8 bytes. kilobyte: 10^3 = 8 bytes megabyte: 10^6 = 64 bytes gigabyte: 10^9 = 512 bytes terabyte: 10^12 = 4096 bytes petabyte: 10^15 = 32,768 bytes exabyte: 10^18 = 262,144 bytes zettabyte: 10^21 = 2,097,152 bytes yottabyte: 10^24 = 16,777,216 bytes xennabyte: 10^27 = 134,217,728 deabyte: 10^30 = 1,073,741,824 vendekabyte: 10^33 = 8,589,934,592

    As you can see, current (32-bit) computer systems can address 0.5 vendekabytes. In only a few Moore-times, when we have 128-bit systems, we will be able to address substantially more than a googolbyte.

  • (cs) in reply to Michael
    Anonymous:
    Ok... I'm actually the programmer of this snippet.  I first heard of the daily WFT about two weeks ago, so when I got an email just now telling me my code was here, I kinda freaked out :)  I'm pleased to see that it's not so bad.

    As for why...
      a) why not?  You'll note that the length of the "symbols" list doesn't affect how you get to a given formatting.  It could have 1000 prefixes long and you still get to "k" in one step.  The only cost is storing that list.
      b) who says this is purely for addressing real data?  How much data do you need to describe the location of every atom in the solar system to within 1mm?  There are plenty of cryptographic examples as well.
      c) yes, it amused me.  I actually trolled around for a while to find the prefixes out that far.  I sure didn't know them off the top of my head :)

    Also, new versions allow for SI-based scaling (1000 rather than 1024).



    Welcome, Michael!

    Do not be intimidated by the purile spirt of this thread.  Most of us appreciate the elegance of your code and approach.  Indeed, of those mocking it, most of them do it in order to be funny, and not to belittle its design.

    As Alex said in his introduction, your code is not really a WTF (as a matter of fact, it is the most un-WTF-ish entry we've had in a while), but it's amusing comments are entertaining to other developers as well.  Maybe Alex's well of WTF submissions is running dry...?

    I hope you stick around this forum for a while.  We could always use more smart people with a witty sense of humour, and I'm sure you can use the cynical amusement brought by laughing at bad code and stupid designs.

        Cheers!
        dZ.

  • Dave (unregistered) in reply to Chris Brien

    On a serious note

    whats the better statement

    "640k (1/2 of a megabyte) ought to be enough for anybody." Bill Gates 1981

    <font color="#006400">"just in case someone needs more than 1000 yottabytes!" - Unknown Programmer circa 2005

    </font>

    Which one do we have to pay for every day of our programming lives :)

  • Dave (unregistered) in reply to Dave
    Anonymous:
    On a serious note

    whats the better statement

    "640k (1/2 of a megabyte) ought to be enough for anybody." Bill Gates 1981

    <font color="#006400">"just in case someone needs more than 1000 yottabytes!" - Unknown Programmer circa 2005

    </font>
    Which one do we have to pay for every day of our programming lives :)


    Before you shoot me down in flames , the quote is not accurate i just googled for it and pasted it in
  • (cs) in reply to Chris Brien
    Anonymous:
    [As you can see, current (32-bit) computer systems can address 0.5 vendekabytes. In only a few Moore-times, when we have 128-bit systems, we will be able to address substantially more than a googolbyte.


    Ah, Vendeka Bytes... the little known cousin of Veruca Salt, and Charlie's dearest love (after chocolate, of course).  Last I heard she was arrested by W.W. security when trying to break into The Factory.

        dZ.

  • Someone Else's Name (unregistered) in reply to TheMuuj
    TheMuuj:
    Or how about the code that bugs you until you reboot, interrupting your workflow until you're forced to reboot and take an early break?


    You know why it does that, right?  If you install a security update to some piece of code that you're currently using (esp. part of the OS), it's not secure until you reboot.  (or at least close and restart that code, but that's not always enough)  Some people would install the update and just ignore the request to reboot indefinitely.

    Personally, I just shove the window off-screen until the end of the day, but it's not just doing that to be annoying.
  • Hugo (unregistered)

    Hmms, lets see if we can simplify this code a bit:

    Alex Papadimoulis:
    <font color="#006400">...
    # just in case someone needs more than 1000 yottabytes!</font>
diff = depth - len(symbols) + 1

    <font color="#0000ff">if</font> diff > 0:
        depth = depth - diff



    So the last assignment reads: depth = depth - (depth - len(symbols) + 1)
    Which can be simplified to: depth = len(symbols) - 1
    And as symbol appears to be a constant array (from this code snippet), this would be a constant...
  • Rob (unregistered) in reply to Hugo

    This may be a reaction to the versions of the UNIX 'df' command where the output formatting was messed up for values larger than a terrabyte, and so on.

  • (cs) in reply to Chris Brien

    Anonymous:
    Anonymous:
    I believe that a bit does have 10 possible values, namely 0 and 1.

    Fun,

    Sten
    Of course, by that logic, one kilobyte, should be 10^3 bytes - ie 8 bytes.

    kilobyte: 10^3 = 8 bytes
    megabyte: 10^6 = 64 bytes
    .
    .
    .
    vendekabyte: 10^33 = 8,589,934,592 As you can see, current (32-bit) computer systems can address 0.5 vendekabytes. In only a few Moore-times, when we have 128-bit systems, we will be able to address substantially more than a googolbyte.

    Either one of 10 cases just happened:

    [*] Someone missed a binary joke or
    [*] I missed missed a joke about a binary joke

  • (cs) in reply to Rob
    Anonymous:
    values larger than a terrabyte, and so on.


    The terrabyte - the Earth's native byte.
  • (cs) in reply to dhromed
    dhromed:
    Anonymous:
    values larger than a terrabyte, and so on.


    The terrabyte - the Earth's native byte.


    Yes, the terrabyte is the word-size of the successor of Deep Thought.

        dZ.

  • Nick Coghlan (unregistered) in reply to DZ-Jay

    I was concerned at one point about the lack of overflow handling on a particular counter in the program I was working on (given that the software assumed that the counter values were unique within any given invocation of the program).

    Then I actually spent five minutes doing the math: overflowing that counter would require running the software continuously for a few hundred thousand years (and thrashing it pretty hard for that entire time). So instead of adding overflow handling, I just put in a comment warning that the software shouldn't be run for half a million years at a time 8-|

  • (cs) in reply to Mic

    Anonymous:
    """In terms of Compact Discs, we'd need to build a stack high enough to reach the moon ... and back ... and there again ... and back again ... just to have a yottabyte worth of data."""

    WTF?

    Let's do the math:
    Average distance between moon and earth is 385000km, let's assume a double layer DVD, capable of holding 2* 4.7 GB (2*4.38GiB). A DVD is 1.2mm thick. A yottabyte is 1024^8, so we end up with a stack of DVDs:

    ceil((B*1024^8) / (8.76B*1024^3)) * 0.0012m / 385000km

    = 400.60 times the average distance between earth and moon surfaces.

    But I was close! Just off by a couple magnitudes ... and the type of disc ;-). I corrected the post, thx for pointing that out.

  • (cs)

    I think actually that this WTF brings a serious issue up. Nobody knows what all those mega this and giga thats mean. It's all greek.

    I hereby suggest that we move to a new standard in describing data storage, with the basic unit of measurement being "metres of floppy disks". Everyone knows how much you can get on a floppy, and how long a metre is.

    "Dude, I just got a new computer, and it has 300MFDs (metres of floppies) of storage!"

    "That's nothing. We've just set up our SAN at work, and we have a London-to-Paris worth of storage".


    Ridding ourselves of the megagigayotta technobabble and embracing units of measurement that the layperson can understand is the best thing we can do for the industry.

    Next up - "Calculations of the nation debt per minute" to make CPU speeds make more sense, and "how well you can make out a cow from the space station" specifications for digital cameras.

  • Eric the .5b (unregistered)

    This is definitely a WTF. It's just a sort of happy, amused "WTF?" as opposed to the shocked, hair-pulling "WTF!" we're used to...

  • (cs) in reply to joost

    joost:

    1 km = 10**3 meter
    1 kg = 10**3 gram
    1 megaton = 10**6 ton
    1 ml = 1/10**3 liter

    <FONT face="Courier New" size=2>1 slug = 14.59390 kg</FONT>

    <FONT face="Courier New" size=2>that's one big slug.</FONT>

  • (cs) in reply to JThelen
    JThelen:
    Oh, and since I can't edit my posts, apt-get > yum


    Quoted for truth.
  • CarolSZ (unregistered) in reply to Anonymous Coward
    This snippet looks buggy to me. It is true that it is hard to hit the bugs during our lifetime even taking into account Moores law. I do not know the language it was written in but:
    WTF: depth=depth-diff ->why obfuscate the code in such a manner instead of simply saying: depth=len(symbols)-1
    where, of course, len(symbols)-1 could be a constant
    Bug: number=number*thresh*depth is wrong. Correct would be: number=number*1024**diff,
    this assuming in the language this is written ** means integer exponentiation and is implemented fast and accurately unlike FP exponentiation and has a higher precedence than multiplication.
    It is amazing though that the language this was written in supports integers so big. I think that even 64 bit systems stop at 16exa.
     
  • (cs) in reply to Dave

    "Not accurate" is one way of putting it.  "Apocryphal" or "urban legend" are others.

  • (cs) in reply to CarolSZ
    Anonymous:
    This snippet looks buggy to me. It is true that it is hard to hit the bugs during our lifetime even taking into account Moores law. I do not know the language it was written in but:
    WTF: depth=depth-diff ->why obfuscate the code in such a manner instead of simply saying: depth=len(symbols)-1
    where, of course, len(symbols)-1 could be a constant
    Bug: number=number*thresh*depth is wrong. Correct would be: number=number*1024**diff,
    this assuming in the language this is written ** means integer exponentiation and is implemented fast and accurately unlike FP exponentiation and has a higher precedence than multiplication.
    It is amazing though that the language this was written in supports integers so big. I think that even 64 bit systems stop at 16exa.
     


    I think you, as well as a few others missed the reasoning behind using the 'thresh' variable as opposed to hardcoding 1024.  YUM isn't the only place you'll find that;  I'm sure that if you looked at apt-get, you'd find it there too, as well as the Windows updater.  The reasoning is to force it into the next higher measure earlier, so that you'll get .90GB as opposed to 1000MB, to use the earlier example.  You have noticed that, right?  Well, doing it your way, as well as was mentioned in an earlier reply(which you and about 3 others appear to be overlooking) will keep that from happening, and won't roll the measure over until it's exactly 1.  So, in short, it's not a bug, and is working as intended.

    As an addendum, I've said this before, as have 3-4 other folks.  This code isn't a WTF in the sense that the board has come to be acquainted with.  There's nothing wrong with YUM from a design standpoint, and I'd imagine the rest of YUM is similarly clean and well designed.  The WTF here is that they built it all the way to yottabytes, which at this time don't really exist.  In practice, a terabyte is about as large as you'll see in a single storage device, and even then, as I'm sure you know, you'll have to set up a rather large RAID array to achieve that.  Even so, this isn't really a WTF in the sense of 'WTF was this moron thinking?'.  To me, snippets like this that just make you go 'Huh?  WTF?' and have a good laugh since there's nothing wrong;  it's just something put in there to get a WTF rise and act as a little bit of a joke are good WTFs.  And we could certainly use a few more of those around here.
  • Boaz (unregistered) in reply to JThelen

    I just started reading TheDailyWTF, and have been pretty impressed by the quality (or lack thereof) of the submissions. When I saw the first line of this, though, I went "WTF? yum has a WTF?" The rest was reassuring -- it is nice to know that the open-source software that I run does not come close to the scariness of the databases, web applications, and proprietary in-house apps out there. Maybe it's the OPEN SOURCE part of Open Source?

  • neuro (unregistered) in reply to dubwai
    dubwai:

    procyon112:
    Very nice.  This programmer takes the "no arbitrary limits" philosophy seriously.  I like it.

    As for neccessity:  Moores law, although it doesn't directly apply to storage, has shown to parallell storage capacity pretty well as a general rule of thumb.  Since 2^10=1024, we can expect to hit the next "depth" every 10 Moore's cycles, or 15 years.  I regularly deal with terabytes of data now, in 2005.  Using Moore's law as a rough guide, I can expect to be dealing with 1000 yottabytes (1 nonabyte) in 60 Moore's cycles, or approximately 90 years.  So, in 2085 this software would most likely break occassionally if it had an arbitrary limit.  By 2100 I would expect it to break fairly regularly.  That is not to say that it won't break eventually, as word length seems to grow linearly, but I'd say he bought himself an extra 40 years or so with this adjustment.  I would fully trust this code to operate until 2115.  It's not THAT far away.

    And to put the storage into perspective, 1 yottabyte is about 2 moles of bytes, which given 1 molecule per bit storage would fit rather handily in something weighing 16-32 grams.  And that is just conventional storage.  We haven't even entered the world of overlapping quanta, so in reality, these sizes are not unbelievable... I just wouldn't try fitting them on a CD-R. :)

    Sure, conceptually we could address that much data but having a place to put that much data and actually having the data to fill it are two completely different matters.



    hehe, seems like you've never bought a new HDD. give me 1000 yottabytes and a month's time, and i'll be back wanting more space :p
  • name (unregistered) in reply to -E
    Anonymous:
    Ytram:
    Anonymous:
    Ytram:
    I assume you're talking about the nag dialog that pops up after an update is completed for Windows.  You can increase the nag timer or completely disable it if you so choose.


    Howhowhowhow? I too find that so annoying.

    I generally drag it so that it's sitting with just a few pixels of the window sitting over the corner of the system tray, the rest off screen, but disableing it would be nicer...


    Start -> Run -> gpedit.msc -> Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Re-prompt for restart with scheduled installations.

    Credit for this info goes to one of the commentors in this Coding Horror blog post:
    http://www.codinghorror.com/blog/archives/000294.html




    LOL - Now that's usability/user friendlyness in only 9+ easy steps ;)

    -E



    and not very future-proof either - it'll keep interrupting my workflow every 1440 minutes at best! hell, what kind of number is 1440, anyway?
    [image]

  • (cs) in reply to name

    Anonymous:

    and not very future-proof either - it'll keep interrupting my workflow every 1440 minutes at best! hell, what kind of number is 1440, anyway?

    1440 minutes =  24 * 6 = 1 day.

  • (cs) in reply to dubwai
    dubwai:

    Anonymous:

    and not very future-proof either - it'll keep interrupting my workflow every 1440 minutes at best! hell, what kind of number is 1440, anyway?

    1440 minutes =  24 * 6 = 1 day.

    a 0 rolled off the screen and under my desk.

    1440 minutes =  24 * 60 = 1 day.

  • (cs) in reply to neuro

    Anonymous:

    hehe, seems like you've never bought a new HDD. give me 1000 yottabytes and a month's time, and i'll be back wanting more space :p

    That must be quite a porn collection.

  • (cs)

    And anyway, 640Yb should be enough for anybody.

  • (cs) in reply to JThelen
    JThelen:


    I think you, as well as a few others missed the reasoning ....



    Dear JThelen, look again.

    Let's assume number is initially a Value of 1048576 yottabytes. Now after the loop the variables have these values:

    depth = 10
    number = 1

    so diff will become 2, which is greater than zero, hence

    depth = 8
    number = 1 * ( 999 ** 8 ) = 992027944069944027992001

    So the final output will be:

    992027944069944027992001 YB

    while it should be

    1048576 YB


    Now, is there

    [  ] no bug  (neither thresh/1024 nor depth/diff)
    [  ] one bug (either thresh/1024 or depth/diff)
    [  ] two bugs (both, thresh/1024 and depth/diff)

    cu
  • (cs) in reply to eagle
    eagle:
    JThelen:


    I think you, as well as a few others missed the reasoning ....



    Dear JThelen, look again.

    Let's assume number is initially a Value of 1048576 yottabytes. Now after the loop the variables have these values:

    depth = 10
    number = 1

    so diff will become 2, which is greater than zero, hence

    depth = 8
    number = 1 * ( 999 ** 8 ) = 992027944069944027992001

    So the final output will be:

    992027944069944027992001 YB

    while it should be

    1048576 YB


    Now, is there

    [  ] no bug  (neither thresh/1024 nor depth/diff)
    [  ] one bug (either thresh/1024 or depth/diff)
    [  ] two bugs (both, thresh/1024 and depth/diff)

    cu


    And if you'd read the whole post that I was referring to, I wasn't addressing that issue.  Here it is, since you apparently missed it.

    This snippet looks buggy to me. It is true that it is hard to hit the bugs during our lifetime even taking into account Moores law. I do not know the language it was written in but:
    WTF: depth=depth-diff ->why obfuscate the code in such a manner instead of simply saying: depth=len(symbols)-1
    where, of course, len(symbols)-1 could be a constant
    Bug: number=number*thresh*depth is wrong. Correct would be: number=number*1024**diff,
    this assuming in the language this is written ** means integer exponentiation and is implemented fast and accurately unlike FP exponentiation and has a higher precedence than multiplication.
    It is amazing though that the language this was written in supports integers so big. I think that even 64 bit systems stop at 16exa.
     


    Now, in the regards that this individual, among others is presenting the 'apparent WTF', it's not. 

    W/r to what you're talking about, yes, it's likely there's a bug in what's there.  The real question, IMO, is how much does it matter?  The developer obviously put this in as an easter egg of sorts, and one accessible only to someone looking at the source.

    Cheers.


  • Jim (unregistered) in reply to Michael

    This brings up a question that's always bothered me.

    Michael wrote:

    b) who says this is purely for addressing real data?  How much data do you need to describe the location of every atom in the solar system to within 1mm?  There are plenty of cryptographic examples as well.

    So, a real-world conundrum: there are approximately 10120 possible chess games. There are approximately 10115 atoms in the universe (estimate). Even assuming one could store one chess game per atom, we're still short. Who will decide which possible chess games never get stored?

  • (cs) in reply to JThelen
    JThelen:


    And if you'd read the whole post that I was referring to, I wasn't addressing that issue.



    I did, and here is what you wrote



    I think you, as well as a few others missed the reasoning behind using the 'thresh' variable as opposed to hardcoding 1024.  YUM isn't the only place you'll find that;  I'm sure that if you looked at apt-get, you'd find it there too, as well as the Windows updater.  The reasoning is to force it into the next higher measure earlier, so that you'll get .90GB as opposed to 1000MB, to use the earlier example.  You have noticed that, right?  Well, doing it your way, as well as was mentioned in an earlier reply(which you and about 3 others appear to be overlooking) will keep that from happening, and won't roll the measure over until it's exactly 1.  So, in short, it's not a bug, and is working as intended



    So you talk about rolling over at .9# and that's the cause for using thresh=999. And yes you are right.

    Yes, it is ok to compare with thresh in the loop's condition. But in


    This snippet looks buggy to me. It is true that it is hard to hit the bugs during our lifetime even taking into account Moores law. I do not know the language it was written in but:
    WTF: depth=depth-diff ->why obfuscate the code in such a manner instead of simply saying: depth=len(symbols)-1
    where, of course, len(symbols)-1 could be a constant
    Bug: number=number*thresh*depth is wrong. Correct would be: number=number*1024**diff,
    this assuming in the language this is written ** means integer exponentiation and is implemented fast and accurately unlike FP exponentiation and has a higher precedence than multiplication.
    It is amazing though that the language this was written in supports integers so big. I think that even 64 bit systems stop at 16exa.
     


    there is no reference to the loop condition, but to the expression used to convert from wtfbytes back to yottabytes.

    And in this expression it is

    a) wrong to use thresh=999 instead of 1024

    and

    b) wrong to use depth instead of diff.

    That's the bug pointed out by the other poster, but in your mission to educate everybody about why thresh=999 is correct (which nobody doubted) you missed that point.



    Now, in the regards that this individual, among others is presenting the 'apparent WTF', it's not. 

    W/r to what you're talking about, yes, it's likely there's a bug in what's there.  The real question, IMO, is how much does it matter?  The developer obviously put this in as an easter egg of sorts, and one accessible only to someone looking at the source.

    Cheers.



    I agree.

    However, the original code produces always the same output for

    1024 yottabytes
    1048576 yottabytes
    1073741824 yottabytes
    ...
    1024**n yottabytes

    And that's a WTF, even if it actually is an easter egg.

    cu
  • Michael (unregistered) in reply to eagle

    Yep.  You guys caught me.  There was indeed a bug in the code.  It's now fixed in CVS.  Thanks.  This is most certainly the strangest bug report I've ever had!  Fortunately, it was actually in the code that deals with the >1000 yottabyte case, so I rather doubt it ever caused any serious trouble for anyone.

    Oh, and I've thoroughly enjoyed this.  I have indeed taken any criticism as playful.  I figure if you emerge from here anything less than bruised, bloody, and limping, then you should take it as a compliment :)

  • (cs) in reply to Michael
    Michael:
    Yep.  You guys caught me.  There was indeed a bug in the code.  It's now fixed in CVS.  Thanks.


    And don't forget to change it here also:

    http://linux.duke.edu/~mstenner/misc/

    :D
  • Chili Joe (unregistered) in reply to Michael
    Anonymous:
    Yep.  You guys caught me.  There was indeed a bug in the code.  It's now fixed in CVS.  Thanks.  This is most certainly the strangest bug report I've ever had!  Fortunately, it was actually in the code that deals with the >1000 yottabyte case, so I rather doubt it ever caused any serious trouble for anyone.

    Oh, and I've thoroughly enjoyed this.  I have indeed taken any criticism as playful.  I figure if you emerge from here anything less than bruised, bloody, and limping, then you should take it as a compliment :)


    I wonder what fix you did. I like Kannan Goundan's suggestion.
  • (cs) in reply to Someone Else's Name
    Anonymous:
    TheMuuj:
    Or how about the code that bugs you until you reboot, interrupting your workflow until you're forced to reboot and take an early break?


    You know why it does that, right?  If you install a security update to some piece of code that you're currently using (esp. part of the OS), it's not secure until you reboot.  (or at least close and restart that code, but that's not always enough)  Some people would install the update and just ignore the request to reboot indefinitely.

    Personally, I just shove the window off-screen until the end of the day, but it's not just doing that to be annoying.


    I certainly do understand the implications of not rebooting, but "No means no."  I'm not going to be attacked through a security hole during the hour I leave the software unpatched, as I generally do not even use the software being patched (in this case Outlook Express).

    If it were software I am actively using, I might save everything and reboot, but that's a hassle I do not normally want to deal with.
  • Vasil (unregistered)

    This reminds me of a funny situation that I had in my first year at the university.

    I think all of you know the classical Tower of Hanoi puzzle.
    If not then check this link http://www.cut-the-knot.org/recurrence/hanoi.shtml.

    So a friend of mine showed me how to implement a simple program in Paskal that solves the puzzle (at these days I was not very good at programming espetially at some "exotic" concepts like recusion :) )

    Anyway our major mistake was to make it "user friendly". It prompted for a number of disks before starting moving them.

    So we implemented it, saw that it was running and then left. I came back in several hours and wanted to see it once again. But when I started it, it just dumped something like "Haha, what a stupid program it is - it does nothing"

    I knew that the only one who could do this was my room mate (only he had a key). When I aksed him why he did this he answered me "The program was doing nothing but just looping endless. I left it looping for hours and then I stopped it."
    Beeing a little surprised to hear that I had a insight and asked him how many disks he entered. The answer was devastating: "100. I wanted to see how it works with large numbers. You see - you have a bug in there - it is just looping ..."

    So when I stopped laughing I explained him following;
    The numbe of moves to solve the Tower of Hanoi puzzle is (2^n) - 1 Where n is the number of the disks.
    So to move 100 disks we need 1267650600228229401496703205375 moves. If we had a super PC that makes 1 000 000 000 moves a second (and mine was an old 386 and was not doing 2 or 3 per second with the dumps) then we'll need about 1267650600228229401496 seconds. Which makes 21127510003803823358 minutes -> 352125166730063722 hours -> 14671881947085988 days -> 40196936841331 years which is about 8000 times more than the life of the solar system and 4000 times more than the existence of the whole universe.

    Well ... he was right for one thing - the program would be really looping "forever" :).

Leave a comment on “Just In Case It's Needed”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article