Thanks for your comments on the midsemester course evaluation. In general, those of you who filled out the forms seemed satisfied with the course, but had a few questions and/or concerns. (I'll share your comments on the recitation with Nathan.) 1. Some of you would like fewer or easier programming projects. I don't think that 4 projects (and the 4th will be really easy) is unreasonable, but I'll take this into consideration for the future. On the other hand, an equal number of you thought that the projects were interesting. It's quite possible that easier ones wouldn't be as interesting :-) 2. Some of you would prefer a "continuous" rather than "discrete" (or "quantized") grading scheme. However, a continuous scheme (for those of you who are real-analysis buffs, I think you really meant "dense" :-) suggests that it's really possible to make (arbitrarily) fine distinctions. My discrete scheme attempts to reflect the basic idea behind the (equally discrete!) ABCDF letter-grading scheme, where (roughly): A = nearly perfect understanding B = better than average, but not perfect C = average D = failure to understand F = did no work My discrete scheme tried to *avoid* problems such as "you lose 1 point for a missing semicolon" or "Gee, can't I have a few more points for this answer?". For more on my philosophy of grading, see: http://www.cse.buffalo.edu/~rapaport/grading.html For more discussion, please post to the newsgroup or send me email. 3. Some of you would like less emphasis placed on writing (and on the report part of the projects). However, writing reports is the way professionals (whether in academe or in industry) present their work, and this course is, after all, an advanced undergrad/graduate-level course designed for students preparing to advance their careers (whether in industry or academe). Learning to write (well)---which is best done by writing---is one of the most important, practical, and long-lasting things you can learn in college or grad school. In any case, the writing is only 1/4 to 1/3 of the project grade, hence only about 1/16 to 1/12 of your final grade. Coding is also only 1/4 to 1/3 of the project grade (contrary to what some of you claimed). But note that with respect to coding, in programming projects as in real life, it's the *result* that counts, not the *amount of time* that you put into it. Spending 1/3 of your time on coding, 1/3 on testing (= sample runs), and 1/3 on writing up the results seems reasonable. That's 2/3 on work, 1/3 on presentation; this weighting seems reasonable. ========================================================================= Please post or email further comments!