Comment On Just In Case It's Needed

A. Murat Eren was browsing through the (open) source of a program called YUM (which, from what I can tell, has something to do with Linux, hot dogs, and a magical kitchen appliance called a "recipe maker") and sent in a little snippet from it. Now, there's nothing really wrong with the code. It's actually researched, written well, and commented. But none the less, I found it pretty entertaining ... [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Just In Case It's Needed

2005-08-17 21:43 • by richleick
I saw this wtf, had a great stack of CD's and yotta yotta yotta, I landed on the moon.



Re: Just In Case It's Needed

2005-08-17 22:06 • by TheMuuj
41093 in reply to 41088
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

  :



  :

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.

Re: Just In Case It's Needed

2005-08-17 22:15 • by Pax
41094 in reply to 41045
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

Re: Just In Case It's Needed

2005-08-17 22:25 • by Michael
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).



Re: Just In Case It's Needed

2005-08-17 23:32 • by Juenemann
41096 in reply to 41094

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?


 

Re: Just In Case It's Needed

2005-08-17 23:49 • by dance2die
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?

Re: Just In Case It's Needed

2005-08-18 02:49 • by Sten
41102 in reply to 41088
I believe that a bit does have 10 possible values, namely 0 and 1.



Fun,



Sten

Re: Just In Case It's Needed

2005-08-18 03:17 • by Sten
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.21*10^24 bytes.  A CD takes about 700
MB = 7.34*10^8 bytes, so 1 Yottabytes would need 1.65*10^15 CDs. 
At about 1mm per CD, this stack is about 1.65*10^12m high.  The
moon is about 1 light second = 3*10^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*60*3*10^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...

Re: Just In Case It's Needed

2005-08-18 03:31 • by Mic
"""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.



See no evil

2005-08-18 04:01 • by Mikademus
41106 in reply to 41105
/me too will continue to ignore the first-of-its-kind (?) event, that the actual author of the WTF'ed code appeared.

Re: Just In Case It's Needed

2005-08-18 04:17 • by meren
41108 in reply to 41095
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.

Re: Just In Case It's Needed

2005-08-18 04:30 • by Welcome To The Machine
41109 in reply to 41095

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


 

Re: Just In Case It's Needed

2005-08-18 05:13 • by DZ-Jay
41110 in reply to 41078
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.

Re: Just In Case It's Needed

2005-08-18 05:25 • by DZ-Jay
41111 in reply to 41104
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.

Re: Just In Case It's Needed

2005-08-18 05:34 • by Chris Brien
41113 in reply to 41102
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.

Re: Just In Case It's Needed

2005-08-18 05:45 • by DZ-Jay
41114 in reply to 41095
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.



Re: Just In Case It's Needed

2005-08-18 05:46 • by Dave
41115 in reply to 41113
On a serious note



whats the better statement



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



"just in case someone needs more than 1000 yottabytes!" - Unknown Programmer circa 2005


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

Re: Just In Case It's Needed

2005-08-18 05:50 • by Dave
41116 in reply to 41115
Anonymous:
On a serious note



whats the better statement



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



"just in case someone needs more than 1000 yottabytes!" - Unknown Programmer circa 2005


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

Re: Just In Case It's Needed

2005-08-18 05:50 • by DZ-Jay
41117 in reply to 41113
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.



Re: Just In Case It's Needed

2005-08-18 06:03 • by Someone Else's Name
41118 in reply to 41056
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.

Re: Just In Case It's Needed

2005-08-18 06:08 • by Hugo
Hmms, lets see if we can simplify this code a bit:

Alex Papadimoulis:
...
# just in case someone needs more than 1000 yottabytes!

diff = depth - len(symbols) + 1

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

Re: Just In Case It's Needed

2005-08-18 07:18 • by Rob
41120 in reply to 41119
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.

Re: Just In Case It's Needed

2005-08-18 07:23 • by Magic Duck
41122 in reply to 41113

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

Re: Just In Case It's Needed

2005-08-18 08:12 • by dhromed
41125 in reply to 41120
Anonymous:
values larger than a terrabyte,
and so on.




The terrabyte - the Earth's native byte.

Re: Just In Case It's Needed

2005-08-18 08:15 • by DZ-Jay
41126 in reply to 41125
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.



Re: Just In Case It's Needed

2005-08-18 08:53 • by Nick Coghlan
41129 in reply to 41126
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-|

Re: Just In Case It's Needed

2005-08-18 08:54 • by Alex Papadimoulis
41130 in reply to 41105

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.

Re: Just In Case It's Needed

2005-08-18 08:55 • by RayS
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.

Re: Just In Case It's Needed

2005-08-18 11:48 • by Eric the .5b
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...

Re: Just In Case It's Needed

2005-08-18 12:50 • by emptyset
41144 in reply to 41088

joost:


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


1 slug = 14.59390 kg


that's one big slug.

Re: Just In Case It's Needed

2005-08-18 12:52 • by OmnipotentEntity
41145 in reply to 41063
JThelen:
Oh, and since I can't edit my posts, apt-get > yum




Quoted for truth.

Re: Just In Case It's Needed

2005-08-18 13:26 • by CarolSZ
41146 in reply to 41048
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.

 

Re: Just In Case It's Needed

2005-08-18 13:58 • by NancyBoy
41148 in reply to 41116
"Not accurate" is one way of putting it.  "Apocryphal" or "urban legend" are others.

Re: Just In Case It's Needed

2005-08-18 14:06 • by JThelen
41151 in reply to 41146
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.

Re: Just In Case It's Needed

2005-08-18 14:25 • by Boaz
41155 in reply to 41151
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?

Re: Just In Case It's Needed

2005-08-18 14:35 • by neuro
41158 in reply to 41054
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

Re: Just In Case It's Needed

2005-08-18 14:50 • by name
41164 in reply to 41074
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?


Re: Just In Case It's Needed

2005-08-18 15:16 • by dubwai
41173 in reply to 41164

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.

Re: Just In Case It's Needed

2005-08-18 15:17 • by dubwai
41174 in reply to 41173
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.

Re: Just In Case It's Needed

2005-08-18 15:18 • by dubwai
41175 in reply to 41158

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.

Re: Just In Case It's Needed

2005-08-18 16:55 • by allanc
And anyway, 640Yb should be enough for anybody.

Re: Just In Case It's Needed

2005-08-18 17:11 • by eagle
41189 in reply to 41151
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

Re: Just In Case It's Needed

2005-08-18 17:24 • by JThelen
41192 in reply to 41189
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.





Re: Just In Case It's Needed

2005-08-18 17:24 • by Jim
41193 in reply to 41095
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 10**120 possible
chess games. There are approximately 10**115 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?

Re: Just In Case It's Needed

2005-08-18 17:42 • by eagle
41196 in reply to 41192
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

Re: Just In Case It's Needed

2005-08-18 19:40 • by Michael
41204 in reply to 41196
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 :)

Re: Just In Case It's Needed

2005-08-18 20:48 • by eagle
41209 in reply to 41204
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

Re: Just In Case It's Needed

2005-08-18 22:30 • by Chili Joe
41212 in reply to 41204
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.

Re: Just In Case It's Needed

2005-08-19 00:54 • by TheMuuj
41216 in reply to 41118
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.

Re: Just In Case It's Needed

2005-08-19 05:48 • by Vasil
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" :).

« PrevPage 1 | Page 2 | Page 3Next »

Add Comment