What's special about 106? How did they come up with that number? I could see making the upper bound a power of two, a perfect square perhaps, but 106? Perhaps they were shooting for 128, but couldn't get those last 22 to play nicely with the others?
Even though the license was violated by other free software developers, I'm glad to see him pursuing this. If we ever want to see the various free software licenses accepted by the general community, we need to show them that we take them seriously, even if that means going after some of our own.
But what's to keep a company's owner from seeing all this missing stuff, breaking a window, and then calling the insurance company? That's just as easy as "stealing" the stuff yourself, it's just that the insurance company has to pay for the window too.
I've got about 2500 cans of Mountain Dew stacked in my cubicle. I use my whiteboard to compute how much caffeine I've consumed, and how many times over it would have killed me.
I've been told that if I were in any other department, I would have been fired. Software development is great.
I think XML is definitely the way to encode the data. However, you may run into problems when you need something that is '(human) language independent'. How is software categorized now? Often by keyword - what (human) language shall these keywords be stored in when it's put into the XML document? Can we simply send it to the fish if someone queries on keywords in a different language?
Describing databases and word processor formats is pretty easy - the 'language' for these is finite (and pretty small at that). We can't assume that we can simply iterate over all algorithms in all languages using all data types to devise the schema. (Human) language is the only method for supporting such a large problem space. So the question now becomes 'How do we take human language and make it human language independent?'
PMDF, a mail service for VMS (and Solaris I think), can be set up to use PH queries to resolve email addresses. That way, you have an easy way to do aliases - just change or add new queries for the server to perform in an attempt to resolve the address. It makes things a lot easier on the sysadmin (especially if that person isn't in charge of maintaining the PH database). These queries create one level of indirection from the actual delivery - the server routes messages between various channels that have been set up to deliver different message types (local, incoming, outgoing, etc), and this query will usually only occur at the final stage of delivery. That means that VRFY will always succeed in this setup, and any message sent to a fake address will only bounce at this final stage. So, don't always trust VRFY. False positives and negatives can result.
I don't know how prevalent such a setup is, but I know of at least one system like this.
You don't need separate/boot partitions, just use the same one for all of the distros that you install. I had a 10GB disk with RedHat installed on it (with/boot accessible in the first 1024 sectors), and when I installed Debian on a 20GB disk (outside of the 1024-sector boundary), I booted it out of my RedHat's/boot with a different image and symlinked Debian's/boot to RedHat's/boot. It seemed to work ok. It only took about 3 installs of Debian (which was rather painful) to come up with this 'strategy'.:)
It said that fog causes some interference, since it blocks light waves, so I would imagine that rain, hail, and snow should not, unless it is so heavy that a normal light beam could not penetrate it.
Chip makers seem to only be concerned about whether or not the gates will live for 10 years? While most 10-year-old chips are so old that they're not even keychains anymore, it seems odd that there's an almost guaranteed failure several years down the road. Most people (at least in the US) get a new computer at least once every ten years, but in less affluent countries, this may not be the case. However, it seems that the chip makers (read evil corporations) are forcing this upon them.
I think one of the main reasons that efficiency isn't much considered in doing server-side programming is that most of the time, these scripts that run only actually execute for a few seconds. It doesn't seem to be worth the time spent making the code memory/CPU/time efficient if it only runs for 15 seconds. Sure, you might be able to shave off some of that time, so now it runs at 10 seconds instead of 15, but was it really worth the 10 hours you spent doing it?
Some of us are born with the ability to, 9 times out of 10, distinguish a telemarketer from someone you actually want to talk to. With a last name like "Van Vertloo", it was always pretty easy to figure it out. The telemarketers would always butcher the name, or, if by some chance they got it correct, it would only be after a short out-of-place pause, which would also give them away. Then it's simply a matter of "he/she isn't home right now." And since telemarketers (at least the ones I've talked to) always ask for someone by using first and last name, it's a pretty good strategy. Although if I'm going to make millions and retire by the time I'm 30, people may start figuring out how to pronounce my name...:)
I was at the contest. It was the first year for anyone from my school to make it, so there was quite a bit of pressure to do well. Especially since we were one of those schools that everyone kept asking us where it was. I worked on Problem F, and I quickly realized it was very similar to a problem that we had practiced. So I had the solution coded up and submitted in about 30 minutes. After getting a wrong submission, I kept revising it and submitting it. Never got a correct solution. I kept telling myself that there must be some weird case that I'm missing, and if I could find it and show that my program broke on that case, then I could figure out why and fix it. Unfortunately, I never found that case. I am positive the algorithm was correct - I copied it almost exactly from the Cormen book (which I saw many copies of there).
In the last 5 minutes of the contest, we printed out all of our code to all of the problems that we worked on, so we could have something to go from. We gave the code to our coach, who coded it up and likewise never found a test case that broke it. So he wrote an email message to Bill Poucher. A few days later, we got a response. Here's a copy-paste of what we received:
> > I will issue a general statement about this. There has been a lot of
> > speculation based on some incorrect assumptions about the data set and > > how F > > was judged. As an exception, I am going to share some information about > > the > > problems, but I still am working on getting confirmation from all > > parties. > > > > Basically, all of the test cases were strongly connected. This has been > > > > verified by at least three very reliable sources. The case that caused > > the > > vast majority of rejection was a directed circuit. To build your own > > test > > data, make four or five test cases followed by: > > > > 1 2 > > 2 3 > > 3 4 > >... > > 99 100 > > 100 1 > > 0 0 > > > > Be sure to terminate your list of test cases with another 0 0. It is > > easy > > to mishandle a sentinel-terminated loop of sentinel-terminated loops. > > Problems that would cause rejection: not explicitly using long > > integers, > > improper type casting, coercion problems, loop bound mistakes, incorrect > > > > initialization of the shortest path matrix, improper traversal of the > > shortest path matrix, improper memory allocation, exceeding stack > > limits, > > failing to reinitialize between test cases, faulty parameter > > passage, getting the algorithm wrong, and so forth. > > > > Be sure that you test it with the command-line compiled version of your > > submissions using the exact command-line compiler flags used in the > > World > > Finals. Make sure to precede this test case by five or six others to > > test > > re-initialization and proper memory management. > > > > I don't know whether Delphi suffers from the same malady that Borland > > C++ > > suffers from, but Borland C++ defaults to 16-bit integers at the > > command-line, but 32-bits at the IDE level.
The reason that 16-bit integers would break any potential solution is that for the case given where we have a 100-node loop is that the sum of distances could easily go beyond the 32767 mark. I guess the teams that did get it either found another algorithm to use or they explicitly used long integers. Pardon me, but ever since 32-bit operating systems came around, I have pretty much assumed that int == 32-bits.
Since then, I have yet to hear of a "general statement", except for this Slashdot story.
In my opinion, many of the results of the competition are invalid because of this problem. Had a correct response come back to us in the first few submissions, we would have gotten at least one, if not two more, correct. We wouldn't have changed the top-most standings, but it's possible that there are other teams that would have.
Slashdot Mirror
Rodent droppings and leech-type creatures - nice to see a regression to the 18th century medical practices.
What's special about 106? How did they come up with that number? I could see making the upper bound a power of two, a perfect square perhaps, but 106? Perhaps they were shooting for 128, but couldn't get those last 22 to play nicely with the others?
Even though the license was violated by other free software developers, I'm glad to see him pursuing this. If we ever want to see the various free software licenses accepted by the general community, we need to show them that we take them seriously, even if that means going after some of our own.
But what's to keep a company's owner from seeing all this missing stuff, breaking a window, and then calling the insurance company? That's just as easy as "stealing" the stuff yourself, it's just that the insurance company has to pay for the window too.
It sounds like the insurance companies are as bad as the people stealing the stuff to begin with. It's not theft if your employees steal from you?
;)
If anyone knows where I can get an Aeron cheap though, let me know...
I've got about 2500 cans of Mountain Dew stacked in my cubicle. I use my whiteboard to compute how much caffeine I've consumed, and how many times over it would have killed me.
I've been told that if I were in any other department, I would have been fired. Software development is great.
How hard is it to double-click the recycle bin? Look at where all those files are. I pressed delete!
I think XML is definitely the way to encode the data. However, you may run into problems when you need something that is '(human) language independent'. How is software categorized now? Often by keyword - what (human) language shall these keywords be stored in when it's put into the XML document? Can we simply send it to the fish if someone queries on keywords in a different language?
Describing databases and word processor formats is pretty easy - the 'language' for these is finite (and pretty small at that). We can't assume that we can simply iterate over all algorithms in all languages using all data types to devise the schema. (Human) language is the only method for supporting such a large problem space. So the question now becomes 'How do we take human language and make it human language independent?'
PMDF, a mail service for VMS (and Solaris I think), can be set up to use PH queries to resolve email addresses. That way, you have an easy way to do aliases - just change or add new queries for the server to perform in an attempt to resolve the address. It makes things a lot easier on the sysadmin (especially if that person isn't in charge of maintaining the PH database). These queries create one level of indirection from the actual delivery - the server routes messages between various channels that have been set up to deliver different message types (local, incoming, outgoing, etc), and this query will usually only occur at the final stage of delivery. That means that VRFY will always succeed in this setup, and any message sent to a fake address will only bounce at this final stage. So, don't always trust VRFY. False positives and negatives can result.
I don't know how prevalent such a setup is, but I know of at least one system like this.
You don't need separate /boot partitions, just use the same one for all of the distros that you install. I had a 10GB disk with RedHat installed on it (with /boot accessible in the first 1024 sectors), and when I installed Debian on a 20GB disk (outside of the 1024-sector boundary), I booted it out of my RedHat's /boot with a different image and symlinked Debian's /boot to RedHat's /boot. It seemed to work ok. It only took about 3 installs of Debian (which was rather painful) to come up with this 'strategy'. :)
The real question is - how many times will the network go down because people have to see for themselves whether the laser is indeed eye-safe?
It said that fog causes some interference, since it blocks light waves, so I would imagine that rain, hail, and snow should not, unless it is so heavy that a normal light beam could not penetrate it.
Chip makers seem to only be concerned about whether or not the gates will live for 10 years? While most 10-year-old chips are so old that they're not even keychains anymore, it seems odd that there's an almost guaranteed failure several years down the road. Most people (at least in the US) get a new computer at least once every ten years, but in less affluent countries, this may not be the case. However, it seems that the chip makers (read evil corporations) are forcing this upon them.
I think one of the main reasons that efficiency isn't much considered in doing server-side programming is that most of the time, these scripts that run only actually execute for a few seconds. It doesn't seem to be worth the time spent making the code memory/CPU/time efficient if it only runs for 15 seconds. Sure, you might be able to shave off some of that time, so now it runs at 10 seconds instead of 15, but was it really worth the 10 hours you spent doing it?
Some of us are born with the ability to, 9 times out of 10, distinguish a telemarketer from someone you actually want to talk to. With a last name like "Van Vertloo", it was always pretty easy to figure it out. The telemarketers would always butcher the name, or, if by some chance they got it correct, it would only be after a short out-of-place pause, which would also give them away. Then it's simply a matter of "he/she isn't home right now." And since telemarketers (at least the ones I've talked to) always ask for someone by using first and last name, it's a pretty good strategy. Although if I'm going to make millions and retire by the time I'm 30, people may start figuring out how to pronounce my name... :)
In the last 5 minutes of the contest, we printed out all of our code to all of the problems that we worked on, so we could have something to go from. We gave the code to our coach, who coded it up and likewise never found a test case that broke it. So he wrote an email message to Bill Poucher.
A few days later, we got a response. Here's a copy-paste of what we received
The reason that 16-bit integers would break any potential solution is that for the case given where we have a 100-node loop is that the sum of distances could easily go beyond the 32767 mark. I guess the teams that did get it either found another algorithm to use or they explicitly used long integers. Pardon me, but ever since 32-bit operating systems came around, I have pretty much assumed that int == 32-bits.
Since then, I have yet to hear of a "general statement", except for this Slashdot story.
In my opinion, many of the results of the competition are invalid because of this problem. Had a correct response come back to us in the first few submissions, we would have gotten at least one, if not two more, correct. We wouldn't have changed the top-most standings, but it's possible that there are other teams that would have.