Comments on: The Context of Minstrel‘s Creation http://grandtextauto.org/2007/11/07/the-context-of-minstrels-creation/ A group blog about computer narrative, games, poetry, and art. Thu, 30 Sep 2010 22:43:57 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Grand Text Auto » Façade, Petz, and The Expressivator http://grandtextauto.org/2007/11/07/the-context-of-minstrels-creation/comment-page-1/#comment-159139 Grand Text Auto » Façade, Petz, and The Expressivator Mon, 17 Dec 2007 02:35:05 +0000 http://grandtextauto.org/?p=1644#comment-159139 [...] fiction systems, including James Meehan’s Tale-Spin (1 2), Scott Turner’s Minstrel (1 2), and Michael Lebowitz’s Universe (1). Now I’m pleased to continue the series with some [...] [...] fiction systems, including James Meehan’s Tale-Spin (1 2), Scott Turner’s Minstrel (1 2), and Michael Lebowitz’s Universe (1). Now I’m pleased to continue the series with some [...]

]]> By: Matthew Merzbacher http://grandtextauto.org/2007/11/07/the-context-of-minstrels-creation/comment-page-1/#comment-144835 Matthew Merzbacher Tue, 20 Nov 2007 21:35:20 +0000 http://grandtextauto.org/?p=1644#comment-144835 Scott's memory of the programming contest overlaps, but is not quite the same with mine. The thing I most remember was that we placed THIRD in our region before going to the (inter)nationals (at that time, there were only a couple of non-US teams, so I'll call them "finals" from now on instead of the inaccurate "nationals" or misleading "internationals"). Normally, a region sent two teams to the finals. We had hoped to place second behind a very strong CalTech team and were packing up to go home when they told us that we'd be going because we had come third to TWO CalTech teams, and a school could only send one team to the finals. Thus, it took some rules luck to even go to the finals. We fully expected to place only moderately well at the finals (maybe top 10), so we spent the day before the finals in Mammoth Caves (Kentucky) and goofing off, instead of getting nervous. When we got the problems for the finals, we divided them up. Seth Goldman took one problem, "It's just I/O hacking" he said, while Alex, Scott, and I took others (and we left a couple to sit). I finished my problem pretty quickly (after coding in "C" for years, dropping back to Pascal was a bit challenging - do YOU remember how Pascal functions return values?). I saw that another problem had been solved by several teams, so I picked that one up - it turned out to LOOK hard, but easily be solved by a greedy solution. That's a common characteristic of contest problems. Anyhow, Alex got his problem and I picked up another. Meanwhile, Seth had switched problems. He kept saying, "That damned I/O problem *should* be solvable, but it looks like it'll take hours." Little did he know - we never even tried to solve that problem (beyond Seth reading through it). One of the most surprising things about the contest was how poorly the (remaining) CalTech team (and several other 'heavyweights' - e.g., MIT) had fared. After all, CalTech had wiped us out in the regionals. I later asked their coach (a friend of mine) what had happened - they solved only one or two problems. He said, "Well, the good teams know that it's all about who can solve the problems FASTEST and not just who can solve the most, since the top teams always get ALL the problems. They saw the I/O problem and realized that it was going to take a long time, so they spent all but the last hour of the contest working on it. Only then did they realize that they wouldn't finish it, or (as a result), any others." There's a great lesson in project management therein, I think. By identifying a problem as essentially insoluble given our constraints, we did the best alternative and ended up "winning". Scott’s memory of the programming contest overlaps, but is not quite the same with mine. The thing I most remember was that we placed THIRD in our region before going to the (inter)nationals (at that time, there were only a couple of non-US teams, so I’ll call them “finals” from now on instead of the inaccurate “nationals” or misleading “internationals”). Normally, a region sent two teams to the finals. We had hoped to place second behind a very strong CalTech team and were packing up to go home when they told us that we’d be going because we had come third to TWO CalTech teams, and a school could only send one team to the finals. Thus, it took some rules luck to even go to the finals.

We fully expected to place only moderately well at the finals (maybe top 10), so we spent the day before the finals in Mammoth Caves (Kentucky) and goofing off, instead of getting nervous. When we got the problems for the finals, we divided them up. Seth Goldman took one problem, “It’s just I/O hacking” he said, while Alex, Scott, and I took others (and we left a couple to sit). I finished my problem pretty quickly (after coding in “C” for years, dropping back to Pascal was a bit challenging – do YOU remember how Pascal functions return values?). I saw that another problem had been solved by several teams, so I picked that one up – it turned out to LOOK hard, but easily be solved by a greedy solution. That’s a common characteristic of contest problems.

Anyhow, Alex got his problem and I picked up another. Meanwhile, Seth had switched problems. He kept saying, “That damned I/O problem *should* be solvable, but it looks like it’ll take hours.” Little did he know – we never even tried to solve that problem (beyond Seth reading through it).

One of the most surprising things about the contest was how poorly the (remaining) CalTech team (and several other ‘heavyweights’ – e.g., MIT) had fared. After all, CalTech had wiped us out in the regionals. I later asked their coach (a friend of mine) what had happened – they solved only one or two problems.

He said, “Well, the good teams know that it’s all about who can solve the problems FASTEST and not just who can solve the most, since the top teams always get ALL the problems. They saw the I/O problem and realized that it was going to take a long time, so they spent all but the last hour of the contest working on it. Only then did they realize that they wouldn’t finish it, or (as a result), any others.”

There’s a great lesson in project management therein, I think. By identifying a problem as essentially insoluble given our constraints, we did the best alternative and ended up “winning”.

]]> By: andrew http://grandtextauto.org/2007/11/07/the-context-of-minstrels-creation/comment-page-1/#comment-136151 andrew Fri, 09 Nov 2007 10:45:05 +0000 http://grandtextauto.org/?p=1644#comment-136151 Wow, thanks for this Scott, it's a fun and fascinating read. Wow, thanks for this Scott, it’s a fun and fascinating read.

]]>