David Lightstone
06-24-2003, 04:45 AM
"Thaddeus L Olczyk" <olczyk@interaccess.com> wrote in message
news:1jvefv8sf1p7ol6gubs0utd6rcob134fts@4ax.com... On Mon, 23 Jun 2003 20:05:55 GMT, "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote:"Dave Harris" <brangdon@cix.co.uk> wrote in messagenews:memo.20030623183133.12175A@brangdon.madasafish.com... john.wilkinson@spirentcom_removethis.com (John W. Wilkinson) wrote (abridged): > Is TDD an appropriate technique for a project such as this contest > where: > > 1. the requirements are fully known and fixed They aren't, really, in this contest. Usually they are a bit woolly,
like, "The program should be faster than competing programs" or "its robots should beat the other robots". They are open-ended.Don't be silly. Those are not requirements. You mean "those are not the requirements"? ^^^
No I mean exactly what I stated, they are not requirements. They are an
evaluation metric for a competition. They do not in any way what-so-ever
serve to describe attributes of the system in need of development. They do
however describe the relationship that the developed system would have to
alternatively developed systems.
As a rhetorical question consider - Please describe one attibute derivable
from the statement, and indicate how it was derived.
Because they are not. There is no place in the rules where it says that "The program should be faster than competing programs". The only place in the rules it says anything about time is the requirement that each move not take more than 1 second of CPU time. People asked and it was clarified that this meant averaged over the period of delivering packages ( the robots burned fuel, when the fuel ran out the move was over ), rather than each move using less then one second ( so one move might take 2.98 seconds, but if the next took 0.01 each you were OK ). The second place entry actually used the whole second. After it finished calculating it's move it used the rest of the time to project it's options. So "how fast" had little to do with it. Just a time limit. Typical of many real programs. Nor does it say "it's robots should beat the other robots". It says the winning robot will be the one that scores the most over a series of different scenarios. ( Where the circumstances vary greatly. One scenario might be where the map is a maze like structure. In another the terrain is wide open. The robot might have lots of fuel but only carry one package at a time. In another the robot carries many packages but has little fuel. The point is to write code that optimizes the score. In fact it's a traveling salesman problem with some unique weighting problems. ). It just another apriori excuse by an incompetent programmer for failing at something.
I kind of think we are not in disagreement, we seem to be focusing on
different aspects
-------------------------------------------------- Thaddeus L. Olczyk, PhD Think twice, code once.
news:1jvefv8sf1p7ol6gubs0utd6rcob134fts@4ax.com... On Mon, 23 Jun 2003 20:05:55 GMT, "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote:"Dave Harris" <brangdon@cix.co.uk> wrote in messagenews:memo.20030623183133.12175A@brangdon.madasafish.com... john.wilkinson@spirentcom_removethis.com (John W. Wilkinson) wrote (abridged): > Is TDD an appropriate technique for a project such as this contest > where: > > 1. the requirements are fully known and fixed They aren't, really, in this contest. Usually they are a bit woolly,
like, "The program should be faster than competing programs" or "its robots should beat the other robots". They are open-ended.Don't be silly. Those are not requirements. You mean "those are not the requirements"? ^^^
No I mean exactly what I stated, they are not requirements. They are an
evaluation metric for a competition. They do not in any way what-so-ever
serve to describe attributes of the system in need of development. They do
however describe the relationship that the developed system would have to
alternatively developed systems.
As a rhetorical question consider - Please describe one attibute derivable
from the statement, and indicate how it was derived.
Because they are not. There is no place in the rules where it says that "The program should be faster than competing programs". The only place in the rules it says anything about time is the requirement that each move not take more than 1 second of CPU time. People asked and it was clarified that this meant averaged over the period of delivering packages ( the robots burned fuel, when the fuel ran out the move was over ), rather than each move using less then one second ( so one move might take 2.98 seconds, but if the next took 0.01 each you were OK ). The second place entry actually used the whole second. After it finished calculating it's move it used the rest of the time to project it's options. So "how fast" had little to do with it. Just a time limit. Typical of many real programs. Nor does it say "it's robots should beat the other robots". It says the winning robot will be the one that scores the most over a series of different scenarios. ( Where the circumstances vary greatly. One scenario might be where the map is a maze like structure. In another the terrain is wide open. The robot might have lots of fuel but only carry one package at a time. In another the robot carries many packages but has little fuel. The point is to write code that optimizes the score. In fact it's a traveling salesman problem with some unique weighting problems. ). It just another apriori excuse by an incompetent programmer for failing at something.
I kind of think we are not in disagreement, we seem to be focusing on
different aspects
-------------------------------------------------- Thaddeus L. Olczyk, PhD Think twice, code once.