Exactly correct! An article claiming to explain how to answer questions involving run-time complexity shouldn't have such obvious mistakes in its analysis of run-time complexity.
(Yes, constant-time can be achieved by preallocating a fixed hash table, but that's not the same as using an arbitrary set insert/retrieve and since it permits collisions and is inherently bounded. It solves only a subset of the described problems.)
Mostly the dice article illustrates how the author is a poor person to look to for advice in that type of interview.
I was also going to recommend cubesat.org and smallsat.org. The mailing list at cubesat@cubesat.org is active with numerous ongoing projects, mostly university-based. There are ITAR issues with American citizens participating in open projects, but there is a one-man korean satellite/art project at http://opensat.cc/about.html that has scheduled a launch.
Another collaborative effort is the GENSO organization, attempting to coordinate a federation of volunteer ground stations to expand telemetry coverage.
It's true that small satellites are built from off-the-shelf components and that a 500km orbit is generally self-cleaning due to atmospheric drag, but there are still some significant engineering challenges involved.
I'm a hobbyist-level engineer with an MS CS; my thesis focused on methods of software reliability for satellites in low-Earth orbit. Here are a few of the things that I consider to be "difficult" parts of a cubesat: - RF communication on a very small power budget. Expensive (for a hobbyist) commercial solutions exist. - Power management and design. Expensive (for a hobbyist) commercial solutions exist. - Attitude determination and control. - Passing the specific thermal/vibration testing requirements for a specific launch provider - Surviving radiation-induced errors. A significant fraction of student-built failed satellites are lumped into "Command and Data Handling Failure" that could be attributed to the wrong bit flipped at the wrong time
There are a few happy coincidences that make it easier: - most orbits result in alternating sun/shadow exposure, every 90 minutes. This just happens to make the temperature of the typical picosatellite oscillate between -20-80F-ish (very, very -ish) such that electronic components keep working with a minimum of thermal engineering. - low-earth orbit has enough atmospheric drag that you don't have to build an active deorbit mechanism to avoid becoming hazardous space junk - the radiation energy levels at low-earth orbit are enough to cause single-event-upsets (flipped bits) in RAM, but NOT enough to damage typical FLASH memory, so an appropriate reset mechanism is usually sufficient. (A NASA engineer summarized it as "Restarting from a known good state")
Also, WOW, there's a lot of ignorant posts here on slashdot. I don't remember the signal-to-noise being this bad, but I could be biased by nostalgia.
At least two games using Teddy are available, Magic Pengel (2003) and Graffiti Kingdom (2004), both for the PS2.
How does old news like this keep making it to the Slashdot front page? Only a single Google search, or (preferably) the slightest bit of current knowledge on the part of the Slashdot staff would allow them to at least post relevent contextual information along with the original submission.
It's generally unfair to judge ACM teams by the polish of their answers, since the only criteria is to solve the problem in minimum time. Similarly, problems are chosen with the time-constraint in mind, not out of any attempt to further science. If you want that, try the MCM.
What's impressive about the winning solutions is that they went from having nothing to implementing a working program from scratch, under stress in only a few minutes. While that is arguably not applicable to being a programmer in real-life, just as being an Olympic sprinter doesn't prepare you for any particular job, it is certainly a commendable intellectual achievement.
Proposal: A simple method of focusing the ray
on
Archimedes Death Ray
·
· Score: 2, Interesting
One common criticism of this theory is that coordination and aiming would be too difficult to be practicable.
It might be possible to engineer a simple method to coordinate the aiming of many mirrors. First assume that your soldiers are standing in a fixed formation and distance relative to their target. (i.e. a straight line)
Each soldier is holding a mirror which is joined at the base to a board, at an angle of 90 degrees. Put a tiny hole in the mirror, so that a point of light falls on the board to which the mirror is attached. Each soldier now has an indicator of the orientation of the mirror. On each board, an ancient geometer has inscribed a grid. (intersecting parabolic arcs, in the case of a straight line of soldiers) If each grid is drawn appropriately (different for each board), then a commander may call out a row and column and each soldier orients their mirror so that the pinpoint of light falls on the appropriate point.
Implemented as simply as I describe, I doubt this arrangement would be suitably precise, but with a larger (possibly two-person) apparatus and provisions for increased stability, it might be possible to quickly focus the hundreds mirrors required to achieve combustion. The only skill required of the solders would be the ability to stand in a straight line and know the alphabet.
The Mathematical Contest in Modeling is a highly competitive worldwide contest that relies heavily on programming skill. In the 84 hours after the question is revealed, teams of 3 must formulate a modeling approach to the problem, implement it and write a paper on their method. An average winning paper will be a 60-90 page research paper plus 3-5K lines of source code.
Senior undergraduates are most successful as the problems require some sophistication to approach. In the end, it's probably a way for the sponsor to cheaply generate an enormous amount of quick research on their selected topic.
PS. Thank you, TopCoder, for paying for a semester of my college education! Yay competitive programming!
Well, in the specific case of DM Java, the code does suffer from some severe memory leakage. Probably the biggest complaint about the game in its current state is that it will always crash when it uses up all available memory.
The source code has been available for some time, but maybe some extremely bored Slashdot reader will try to help.
Slashdot Mirror
Exactly correct! An article claiming to explain how to answer questions involving run-time complexity shouldn't have such obvious mistakes in its analysis of run-time complexity.
(Yes, constant-time can be achieved by preallocating a fixed hash table, but that's not the same as using an arbitrary set insert/retrieve and since it permits collisions and is inherently bounded. It solves only a subset of the described problems.)
Mostly the dice article illustrates how the author is a poor person to look to for advice in that type of interview.
I was also going to recommend cubesat.org and smallsat.org. The mailing list at cubesat@cubesat.org is active with numerous ongoing projects, mostly university-based. There are ITAR issues with American citizens participating in open projects, but there is a one-man korean satellite/art project at http://opensat.cc/about.html that has scheduled a launch.
Another collaborative effort is the GENSO organization, attempting to coordinate a federation of volunteer ground stations to expand telemetry coverage.
It's true that small satellites are built from off-the-shelf components and that a 500km orbit is generally self-cleaning due to atmospheric drag, but there are still some significant engineering challenges involved.
I'm a hobbyist-level engineer with an MS CS; my thesis focused on methods of software reliability for satellites in low-Earth orbit. Here are a few of the things that I consider to be "difficult" parts of a cubesat:
- RF communication on a very small power budget. Expensive (for a hobbyist) commercial solutions exist.
- Power management and design. Expensive (for a hobbyist) commercial solutions exist.
- Attitude determination and control.
- Passing the specific thermal/vibration testing requirements for a specific launch provider
- Surviving radiation-induced errors. A significant fraction of student-built failed satellites are lumped into "Command and Data Handling Failure" that could be attributed to the wrong bit flipped at the wrong time
There are a few happy coincidences that make it easier:
- most orbits result in alternating sun/shadow exposure, every 90 minutes. This just happens to make the temperature of the typical picosatellite oscillate between -20-80F-ish (very, very -ish) such that electronic components keep working with a minimum of thermal engineering.
- low-earth orbit has enough atmospheric drag that you don't have to build an active deorbit mechanism to avoid becoming hazardous space junk
- the radiation energy levels at low-earth orbit are enough to cause single-event-upsets (flipped bits) in RAM, but NOT enough to damage typical FLASH memory, so an appropriate reset mechanism is usually sufficient. (A NASA engineer summarized it as "Restarting from a known good state")
Also, WOW, there's a lot of ignorant posts here on slashdot. I don't remember the signal-to-noise being this bad, but I could be biased by nostalgia.
At least two games using Teddy are available, Magic Pengel (2003) and Graffiti Kingdom (2004), both for the PS2.
How does old news like this keep making it to the Slashdot front page? Only a single Google search, or (preferably) the slightest bit of current knowledge on the part of the Slashdot staff would allow them to at least post relevent contextual information along with the original submission.
It's generally unfair to judge ACM teams by the polish of their answers, since the only criteria is to solve the problem in minimum time. Similarly, problems are chosen with the time-constraint in mind, not out of any attempt to further science. If you want that, try the MCM.
What's impressive about the winning solutions is that they went from having nothing to implementing a working program from scratch, under stress in only a few minutes. While that is arguably not applicable to being a programmer in real-life, just as being an Olympic sprinter doesn't prepare you for any particular job, it is certainly a commendable intellectual achievement.
One common criticism of this theory is that coordination and aiming would be too difficult to be practicable.
It might be possible to engineer a simple method to coordinate the aiming of many mirrors. First assume that your soldiers are standing in a fixed formation and distance relative to their target. (i.e. a straight line)
Each soldier is holding a mirror which is joined at the base to a board, at an angle of 90 degrees. Put a tiny hole in the mirror, so that a point of light falls on the board to which the mirror is attached. Each soldier now has an indicator of the orientation of the mirror. On each board, an ancient geometer has inscribed a grid. (intersecting parabolic arcs, in the case of a straight line of soldiers) If each grid is drawn appropriately (different for each board), then a commander may call out a row and column and each soldier orients their mirror so that the pinpoint of light falls on the appropriate point.
Implemented as simply as I describe, I doubt this arrangement would be suitably precise, but with a larger (possibly two-person) apparatus and provisions for increased stability, it might be possible to quickly focus the hundreds mirrors required to achieve combustion. The only skill required of the solders would be the ability to stand in a straight line and know the alphabet.
The Mathematical Contest in Modeling is a highly competitive worldwide contest that relies heavily on programming skill. In the 84 hours after the question is revealed, teams of 3 must formulate a modeling approach to the problem, implement it and write a paper on their method. An average winning paper will be a 60-90 page research paper plus 3-5K lines of source code.
Senior undergraduates are most successful as the problems require some sophistication to approach. In the end, it's probably a way for the sponsor to cheaply generate an enormous amount of quick research on their selected topic.
PS. Thank you, TopCoder, for paying for a semester of my college education! Yay competitive programming!
Well, in the specific case of DM Java, the code does suffer from some severe memory leakage. Probably the biggest complaint about the game in its current state is that it will always crash when it uses up all available memory.
The source code has been available for some time, but maybe some extremely bored Slashdot reader will try to help.