hartley@uvm-cs.UUCP (Steve) (09/13/85)
We have two VAXen here running 4.2, and besides faculty and graduate student
research, we have some classes on the machines. Although interactive use with
full-screen editors is a giant leap forward from the not-so-distant past of
batch submission using cards, the latter did have the advantage of some security
that the students hadn't tailored their output with an editor to be more
correct. I do not mean to sound like I am assuming that all students would
take advantage of this feature, but I have heard rumors from some of the
students in classes I have taught in the past that a little of this did go on.
I can see the temptation arising the night before an assignment is due and the
program doesn't work. There the (incorrect) output sits in a file, and all the
professor wants is the output file printed on a terminal along with a listing.
Who's to know if it is edited a little to change those incorrect numbers ....
I am wondering if there are batch submission systems out there running under
4.2 BSD that are integrated with the line-printer spooling system. A student
would gather up program source and input data along with a shell script on
how to compile, load, and go, and submit it to the batch server. The output
would automatically go to a printer, offering some assurance that it hadn't
been tweaked.
The only way I know of to check a student's work is go through a demo. But
this is terribly time consuming, and it is hard to set a precise due date
(unless you check file modification times).
What do other people do? Thanks.
--
"If that's true, then I'm the Pope!" Stephen J. Hartley
USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323luner@uwai.UUCP (09/13/85)
Stephen Hartley (hartley%uvm@csnet-relay) worries (and, I believe, not without cause): > ... students ... tailor[ing] their output with an editor to be more > correct. What do other people do? As an instructor, I view this as academic dishonesty. I would treat it as equivalent to a reseacher faking experimental data. Depending on the rules set down by your school/department/university this may be grounds for: 1. Failure in the course 2. the big zero for the assignment 3. academic probation 4. expulsion I make a point to tell my classes that the faking of results is a serious breach of trust and will be dealt with severely. I emphasize that the programs I ask them to write I have seen in many versions, both correct and incorrect that they should not expect an error to slip by. [The truth of this depends on exactly what language and what programs they're doing, but they don't know that.] /David
mcb@styx.UUCP (Michael C. Berch) (09/13/85)
In article <433@uvm-cs.UUCP> hartley@uvm-cs.UUCP (Steve) writes: > [How to grade programming assignments if students can edit the output?] > > The only way I know of to check a student's work is go through a demo. But > this is terribly time consuming, and it is hard to set a precise due date > (unless you check file modification times). > What do other people do? Thanks. When I was an undergrad at UC Berkeley, a common practice on the UNIX systems for grading programming assignments was for the student to demonstrate the code to the reader (grader) in person. This worked relatively well. By the time I got to be a reader there were too many students for this to be feasible. We went to grading printouts; in a beginning class you can pretty well tell whether source program P produced output file Q, but it is more time-consuming in advanced classes. In one class the readers were set up as group-superusers (this was V6) and required that the students leave a copy of the source program in a certain directory in their account with a certain title, explained how modification times worked, and required that the mod time on the program file be before the deadine. Then the readers would su to the account and read, compile, and execute the program, and leave the grade and comments in a file or mail them. This worked quite well. (Uh, actually, there was some minor silliness involving the group-superuser's PATH, which included "." first. One enterprising student [OK, I admit it...] who had completed his program late improvised by writing a "version" of ls(1) that, er, fibbed about mod times. At a later date, somebody else wrote a program that took, ah, certain liberties with unprotected inodes. But those are stories for a different list . . .) My advice is to compile things yourself and watch 'em run, while keeping in mind the fact that the hacker quotient in CS classes has changed dramatically in the last few years. Michael C. Berch mcb@lll-tis-b.ARPA {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb
dat@hpcnof.UUCP (09/14/85)
I think that the way to deal with this is to have a program that would have be used to print the output of a program. This would print it in such a way that it would be virtually impossible to duplicate it (maybe to a special printer? Maybe with special Job Control numbers attached??) and yet would be simple to use. Conceptually: printoutput myprog < mydatafile and it would run myprog, feeding it mydatafile, and spool up a printout for later submission to the class. The problem is that would be hard to do if you don't have a special printer (say) just for this task. If you did, you could have the print device owned by some wierd userid, and have the printoutput program run as setuid that user. The regular print spooler would be denied access. If, however, you didn't have a unique printer, and needed to rely on some sort of job header or something, it becomes much more difficult...the question is what's to stop a student from generating a printout including the erroneous output, then use the editor to duplicate the headers + fix the output. Another idea is to have the printer automatically title each page of the output document with an indication of how it was spooled, and then require all students to invoke the printer program directly from their program (a la "print -execute myprog < mydatafile"). This might be much more fruitful - since it'd add it's own headers to other files that the students might try to fake out with... Just a few random thoughts. -- Dave Taylor HP Colorado Networks Operation ..ihnp4!hpfcla!d_taylor ..hplabs!hpcnof!dat or hpcnof!dat@HPLABS.CSNET-RELAY
brian@ut-sally.UUCP (Brian H. Powell) (09/14/85)
About students doing this...
Here at the University of Texas, I was a TA for the big Assembly Language
course. 200 sophomores; big weedout class.
We ran all the programs. Yes, that's expensive (a CDC Cyber pretending it
knows what a PDP-11 is, and pretending it knows what Ascii is. We're talking
KLUDGE.) and time-consuming (real-time per program sometimes reaches into
hours.).
After a while, you know who you can trust. Besides, you only have to run
the ones that claim to work. We ran the others to see how bad they really
were.
As far as due dates are concerned. Our rules: It had to be in at
midnight of a certain day. Under the TA's door. No exceptions/excuses.
(except sometimes. We weren't too cruel. And five minutes late didn't
matter.)
We have access to their sources and file dates. We re-assembled and ran
them. Again, it's time-consuming, but we saw no alternative.
Brian H. Powell
UUCP: ihnp4!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
U.S. Mail: Southwestern Bell
P.O. Box 5899 345-0932
Austin, TX 78763-5899
AT&T
(512) 345-0932brian@ut-sally.UUCP (Brian H. Powell) (09/14/85)
I thought of a little more to say about this. We also take the time to
look at the people's code. We look it over for style and documentation (and
collusion.) Everybody should have various subroutines that do the same thing.
You can look at those crucial sections to see if they did them right.
It's the people who have peculiar (i.e. poor; wrong) solutions to these
problem sections AND have correct output that warrant further investigation.
(i.e. run the program to grade it.)
Perhaps I, and the rest of UT's graders, are just mean. I feel, however,
that the student shouldn't be shortchanged. I just can't let a shell script
do all my grading. AI hasn't progressed to the point that a program can
judge program style as well as I can. To me, that's an important part of
teaching CS. You don't just teach them how to program; you teach them how
to program well. They can learn the former out of a book. UT is here for
the latter.
Unfortunately, some weeks I spent more than my 20 hours grading/debugging
programs. Oh, well. It's all part of being committed to teaching.
Brian H. Powell
UUCP: ihnp4!ut-sally!brian
ARPA: brian@sally.UTEXAS.EDU
U.S. Mail: Southwestern Bell
P.O. Box 5899 345-0932
Austin, TX 78763-5899
AT&T
(512) 345-0932david@wisc-rsch.arpa (David Parter) (09/14/85)
> Stephen Hartley (hartley%uvm@csnet-relay) worries (and, I believe, not > without cause): > > ... students ... tailor[ing] their output with an editor to be more > > correct. What do other people do? David Luner (luner@wisc-ai) writes: > I make a point to tell my classes that the faking of results is a serious > breach of trust and will be dealt with severely. I emphasize that the programs > I ask them to write I have seen in many versions, both correct and incorrect > that they should not expect an error to slip by. [The truth of this depends > on exactly what language and what programs they're doing, but they don't > know that.] > /David the problem is to prevent such cheating. It is very hard to do, and intimidating the students is not enough. The only thing i can think of off hand is perhaps writing a special version of script that puts the script file in a secure directory, marked as to which student ran it, what data set was run and when. In addition, provisions have to be made for a bad run (typos, anyone?) so if the student ran it again for the same test data, it should overwrite the previous version, up until the time when no more programs are accepted. And then whatever is in that directory is what gets graded. Of course, if the instructor suspects cheating, it is easier to prove in CS than in other fields.... just demand a demo. Or diff the files, check the creation dates or even the backup tapes from a previous semester, depending upon the exact problem (all of the above have been done). i work in the Systems Lab here at Wisconsin, and have helped some faculty with this in the past. As a student in the department, i am particularly sensitive to this problem. I wish it would go away. david -- david parter UWisc Systems Lab uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!david arpa now: david@wisc-rsch.arpa arpa soon: david@wisc-rsch.WISCONSIN.EDU or something like that
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/14/85)
Why not just have the students mail their final version for grading to the instructor, who can easily put them in files, compile and test them, and print them if necessary. To save time, set an alarm to time out any submission that takes too long to compile and run.
veach@ihuxl.UUCP (Michael T. Veach) (09/14/85)
> I make a point to tell my classes that the faking of results is a serious > breach of trust and will be dealt with severely. I emphasize that the programs > I ask them to write I have seen in many versions, both correct and incorrect > that they should not expect an error to slip by. [The truth of this depends > on exactly what language and what programs they're doing, but they don't > know that.] I think the only reasonable thing would be to give the student an A+ for the course as he obviously has the same values for 'truth' as the instructor. Michael T. Veach ihuxl!veach -- Michael T. Veach ihuxl!veach
cck@cucca.UUCP (Charlie C. Kim) (09/14/85)
In any programming oriented computer science class, I think the emphasis should be on the program itself--not the output. People can always edit output to make it look correct (it is certainly feasible in a batch oriented system). The output of a program is only one indication of how well a person programs--face it, he might have found the program in a book somewhere. Grading the program is much more productive. I realise that it take more time, but the time is well spent. By grading the program, I mean examining the person's programming style, the logic, the comments (which will usually indicate the student's grasp of the problem, and if well done of the solution as well), etc. You get a feel for what the student's capabilites and it often clear if the person has copied or has been copying programs from a book or another person. Let's force the student to concentrate on the important issues. The best of this method is that editing the "output" is legal (since the output is program). However, this only works well in classes where the emphasis is on the programming and not the output. I also realize that sometimes this is next to impossible--one grader and 100 people, but it's a thought... Charlie C. Kim
henry@utzoo.UUCP (Henry Spencer) (09/15/85)
> ... There the (incorrect) output sits in a file, and all the > professor wants is the output file printed on a terminal along with a listing. > Who's to know if it is edited a little to change those incorrect numbers ... The best solution is the non-technical one: an alert marker. I know that when I did serious marking for the first time, I was startled at how easy it was to spot this sort of thing. Made me glad I'd never tried it... (The closest I ever came was in an assignment where I'd gone a bit beyond the specs and added an extra feature. As submitted, none of my test data used it. I got docked a bit for incomplete testing, and the marker (who was a friend) asked why I'd goofed up like this. My reply was that it was a simple last-minute mistake; the real reason was that the extra feature had a subtle bug which I didn't have time to hunt down.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
crm@duke.UUCP (Charlie Martin) (09/15/85)
In article <2889@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: > ... AI hasn't progressed to the point that a program can >judge program style as well as I can. To me, that's an important part of >teaching CS. You don't just teach them how to program; you teach them how >to program well.... I think that Brian has an essential point here: one should not grade only the output of a program! The other solutions offered may be technically managable (I like the ``special script'' command idea; seems it should be easily done in 4.2 anyway) but they don't replace the direct feedback that I think is essential to teaching programming. I've been teaching intro labs this semester, and thought about this -- what I finally concluded was that building a rigged demo in those labs at least required more programming skill and effort than simply doing the labs anyway. This made the question much simpler for me (but doesn't really apply to the original question.) Another thought: how about a shell script that runs the programs and then diff's the output with the sample turned in? -- Charlie Martin (...mcnc!duke!crm)
schuler@gondor.UUCP (David W. Schuler) (09/15/85)
> Why not just have the students mail their final version for grading > to the instructor, who can easily put them in files, compile and test > them, and print them if necessary. To save time, set an alarm to > time out any submission that takes too long to compile and run. This method is also used here at Penn State on both Unix systems and with VM/CMS. All files are mailed to the instructor after they are debugged and tested. The instructor then runs the programs using COMMON data for all of the runs. If the program does not run using the data supplied by the instructor, the program is assumed to not work properly, since the user/data interface was defined by the instructor. As far as I know, this method has worked fine in a department where cheating has occurred many times. If a student is caught cheating, he/she will receive an F for the course, and optional probation if the offense is severe enough. -- ------------------------------------------------------------------------ David W. Schuler {akgua,allegra,ihnp4}!psuvax1psuvaxg!schuler Penn State University schuler@psuvax1.bitnet +--+ +--+ + + Home of the 1982 | | | | | National Champion +--+ +--+ | | Nittany Lions | | | | + +--+ +--+ ------------------------------------------------------------------------ "...on the loftiest throne in the world we are still sitting only on our own rear." - Montaigne
root@bu-cs.UUCP (Barry Shein) (09/15/85)
As a teacher who has to deal with this problem, when I think there will be a problem, I am inclined to the following: 1. Tell the students you trust they will not cheat, explain what is and is not cheating as clearly as you can (you will probably find your own fuzziness here, so it's a good exercise, invite discussion.) 2. Do not go to extraordinary lengths to prevent cheating with technological devices, it is a human issue. Once you install such devices (other than a few obvious things which are ok, like telling students how to read protect files and recommending they do so without belaboring moral issues here) you are saying, in effect, 'if you outwit my elaborate devices then it is probably ok to cheat'. The reasoning in people's minds (faulty or otherwise) is that if you put yourself up as having made cheating technologically impossible, you deserve to be outwitted. 3. Tell your students that being as you have put the trust on them, any betrayal of that trust will invoke holy hell from you. I usually warn (when I get into this conversation) that 'I promise you will spend the rest of your life cursing me, all your friends will agree I was an unreasonable asshole about that cheating offense, the least I will compromise on is you get an immediate F and are barred from the department, I will try to get it on your transcript and you thrown out of the school.' I am sure some of my students have gotten away with cheating in my courses, detection is often difficult and being as I firmly believe that when I accuse someone I am ready to go the limit with that accusation I have to be careful with those accusations. I believe a student has a right to some sort of 'hearing', there is nothing worse than soft edged cheating policies where you handle it yourself (notice that anything I would do in response to cheating will be a matter of written record and completely subject to review at the student's request, no little chats in my office about how I'm gonna give you a lousy grade on this hwk cuz I am not sure it is your own work but do well and you can get a reasonable grade anyhow, sorry, that hides what happened and intimidates the student.) Beyond that, detection should not be that hard, spot checking should suffice with a little wisdom and familiarity with your students as to their abilities and attitudes. Another important thing is to try and feel out the support you will get from your administration in your policies (if they will resist you you're in trouble, if they have no recourse against you for the student that's not reasonable either.) Don't misunderstand me, I don't think I hold a majority view at BU, tho I am not quite sure what the majority view is, this should in no way be taken as policies at BU in general, just in my classrooms. Where I was an undergrad many of the courses (not all) were run much more like this, exams were given without proctors etc, you got caught cheating, you were usually out if the prof was willing to press it, or at least that is how students perceived it. Did that *stop* cheating? Of course not, but it seemed to me to be at least a moral system, responsibility not to cheat was placed on the student, not the professor. I agree that a lot of this discussion did have to do with detection, but I sensed an air of replacing moral imperatives with technological devices, a very bad policy to get into. -Barry Shein, Boston University
hope@gatech.CSNET (Theodore Hope) (09/15/85)
Since the beginning of 1983, the ICS 1400 & ICS 1401 ('Pascal I' & 'Pascal II')
classes have been taught on our department's HP3000. Back when I worked on
that machine (ugh!) I developed software for submitting/collecting the students'
assignments. When a student had finished his/her program, he/she would submit
the source file to a special directory. At a later date, the operator or
grader (usually myself) would collect all the files of a certain assignment
for a batch run. The programs' submittal dates were all compared to a date
supplied at this time, compiled, run with the same instructor-supplied data
file, and the output optionally compared to an instructor-supplied key answer
file. (This last option, of course, could only be used when a specific output
format was specified. This was accomplished via instructor-supplied harnesses
which performed the output for the students' subroutines.) This entire mecha-
nism eliminates the possibility of forged output, and saves the instructor lots
of paperwork considering 200 to 300 students per quarter and about one program
due per week.
Because of the "wonderful" programming environment provided by the HP3000,
a lot of it was kluged. However, the concept was interesting and successful.
It's been a while since I've worked on it, and I'm glad to know that starting
next quarter (1.5 weeks from now) both those classes will be moved to an ATT
3b20.
--
Theodore Hope
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
CSNet: Hope @ GATech ARPA: Hope%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-sally}!gatech!hopehope@gatech.CSNET (Theodore Hope) (09/16/85)
I forgot to mention....
Of course, the instructors and/or graders *would* grade the programs by
hand for style, etc. The system was an aid for reporting non-submittals,
late submittals, etc. I agree with those that say that "a shell script
should not be responsible for grading." Software can, however, aid those
poor humans involved in grading freshman Pascal programs.
--
Theodore Hope
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
CSNet: Hope @ GATech ARPA: Hope%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-sally}!gatech!hoperbp@investor.UUCP (Bob Peirce) (09/16/85)
It strikes me the student could do his work in a subdirectory of a
directory, owned by the instructor. The student owns his subdirectory
to prevent other students from looking. The instructor arranges with
root to make all these directories become owned by the instructor and
unwritable by others at the cut-off date. This could be done with cron
or at.
--
Bob Peirce, Pittsburgh, PA
uucp: ...!{allegra, bellcore, cadre, idis}
!pitt!darth!investor!rbp
412-471-5320
NOTE: Mail must be < 30K bytes/messagejma@duke.UUCP (Jon M. Allingham) (09/16/85)
Another way to keep students honest is to implement a batch homework
submittal system. In other words, have a program (more than likely under
Unix a program that runs suid) "deliver" the source to the grader's directory.
If you use common input data to all programs, it's trivial to set up a shell
script that will compile, run and print each program.
==> the output of all this is a stack of listings and output of each
submitted program. The grader can then grab the stack, take it home and
grade.
We successfully implemented this system when I was at school at Georgia Tech,
both on CDC Cyber and on an HP 3000. When things work correctly it was
actually quite convenient to have everything all together. I graded for
>1 year with this method.
Jon M. Allingham
AT&T Bell Laboratories (currently at Duke University for 1 year)louie@umd5.UUCP (09/16/85)
This reminds me of a system that a few of us hacked together for an ACM
programming competition a few years back. The contest was run on a Sperry
1100 mainframe, but the same sort of thing could be done on most systems.
We provided a program that would generate a runstream ("shell script") that
would run the program. There were two type of runs that could be requested;
a TEST run and a JUDGED run. The data for the TEST run was generated by
the contestents. The data for the JUDGED run was provided from a hidden
source. Note that the contestents NEVER was able to see the real data or
the results of the run. The eliminated opportunities to edit the output.
The output produced from the JUDGED runs was directed to a specific printer
not available to the contestants. On a UNIX machine, you could mail the
output to the grader. I think you can get the idea...
--
Louis A. Mamakos WA3YMH University of Maryland, Computer Science Center
Internet: louie@trantor.arpa
UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louiespaf@gatech.CSNET (Gene Spafford) (09/16/85)
Of course, we've touched on the fact that the style, structure, and
comments in student assignments are important. I usually count a
significant portion of the credit on an assignment to the modularity
and readability of the code (because it is important to teach students
to code that way and because they are less likely to panic and do
desperate things if they know they can get credit for a partial
solution).
However, correct functioning is important. If we produced only
graduates who were able to code with style but unable to produce
functioning programs, we would find few people would continue to value
our graduates. Therefore, it is important that we produce students who
know how to complete a project and make it work.
Let me list some of the desired attributes of students I would
want to graduate from a programming/design course:
-- their code is well documented, both structure and algorithms
-- their code is modular and well separated functionally
-- their code is designed to be expandable without a total rewrite
-- their code checks for boundary and error conditions, and especially
for bogus input
-- they test their own code
With those in mind, it is easy to see that we don't want to design
assignments where we tell the students ahead of time what the input and
output is going to be. Rather, we tell them the format and kind of
input and the output we expect, both for valid input and for improper
input.
For example, after explaining the recursive algorithm for solving the
Towers of Hanoi problem, we could easily give an assignment to the
class telling them to implement a program to solve the problem for 5
disks and print the sequence of moves. A much better assignment would
be to have them write a general program which would take, as input, the
number of disks from 1 to 10, as well as an indicator of which peg the
disks are on and which one to move the disks to, and then print the
sequence of moves. After the assignment is done, we obtain a copy of
each student program and run it with preselected input data which
tests a few proper values, both boundaries, and some improper input (11
disks, -1 disk, 4th peg). The students don't know the exact input
ahead of time so they can't take a short-cut to producing the output.
It forces them to think more about the problem and anticipate possible
input. Plus, their programs are tested for more than just the solution
to one particular case -- they are tested to see if they are valid
solutions to the class of problems presented.
That's how I address the problem of edited output. I spend more time
defining the assignment so that the student isn't sure of the exact
output required. I make the problem more general (and more like a
real-world problem in terms of input and output processing), and then I
run a copy of the program myself. I think it teaches more.
--
Gene "3 months and counting" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spafabc@brl-sem.ARPA (Brint Cooper ) (09/17/85)
Folks, There has been discusion under this subject line about what to do when you find a student who has been cheating. Where I have taught, we were warned that unilateral action by a prof can constitution depriving a student of his/her rights without due process of law. Apparently, this has been upheld in court. Do not your Universities have Codes of Academic Honesty or some such sets of rules by which a student can confront the accusor and the evidence and present his/her side? Brint
manis@ubc-cs.UUCP (Vince Manis) (09/17/85)
In article <1627@ihuxl.UUCP> veach@ihuxl.UUCP (Michael T. Veach) writes: >> I make a point to tell my classes that the faking of results is a serious >> breach of trust and will be dealt with severely. I emphasize that the programs >> I ask them to write I have seen in many versions, both correct and incorrect >> that they should not expect an error to slip by. [The truth of this depends >> on exactly what language and what programs they're doing, but they don't >> know that.] > > >I think the only reasonable thing would be to give the student >an A+ for the course as he obviously has the same values >for 'truth' as the instructor. Not at all. As an instructor, I often tell students things that could be true, but aren't. The fact is, in the overwhelming majority of cases, it *is* obvious that a student has cheated. (This summer, there was a case of a simple text-processing program which miraculously rephrased its input along with counting words). Generally, if a student knows enough to do a good job of cheating, s/he knows enough (and is motivated enough) to write the program properly. This fall, we switched to Macs, and I am somewhat concerned about the possibilities for fraud in an environment where everyone does his or her work on micros, and where it's very easy to edit an output file. I have no answer to this, other than to threaten the students (I explain that it's exactly like handing in a falsified physics experiment), and to lower the dependence of the final grade on assignment marks.
rob@ctvax (09/19/85)
Don't forget that software metrics (Halstead's, McCabe's etc) can be used to find programs worthy of checking for collusion. A simple file compare an easily be masked extensive use of globals replacement. The best trick is to assign the metric calculation as a class problem and then use the ones that work on all the programs handed in! Rob Spray ...convex!ctvax!rob
boston@celerity.UUCP (Boston Office) (09/19/85)
In article <300@uwvax.UUCP> david@wisc-rsch.arpa (David Parter) writes: >> Stephen Hartley (hartley%uvm@csnet-relay) worries (and, I believe, not >> without cause): > >> > ... students ... tailor[ing] their output with an editor to be more >> > correct. What do other people do? > >David Luner (luner@wisc-ai) writes: >> I make a point to tell my classes that the faking of results is a serious >> breach of trust and will be dealt with severely. I emphasize that the programs > >the problem is to prevent such cheating. NO, NO, NO! The problem is to create an atmosphere in which students take responsibility for their actions! An honor code IS sufficient... as long as (a) it has some teeth in it, as David pointed out, and (b) the rest of the system makes it clear that fraud is WORSE than momentary failure. -- Roger B.A. Klorese
ed@mtxinu.UUCP (Ed Gould) (09/19/85)
In article <236@uwai.UUCP> luner@uwai.UUCP writes: >As an instructor, I view this as academic dishonesty. The best response I've ever heard about academic dishonesty was from a friend teaching English. She discovered that some of her students had copied their papers from Cliff's Notes or some other such publication - either verbatim or very closely paraphrased. She announced to the class that she'd discovered the plaigerisms, and announced her policy: If the authors owned up to the dishonesty, they'd receive an F on that paper. If not, they'd fail the course. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
jsq@im4u.UUCP (John Quarterman) (09/19/85)
In article <12378@styx.UUCP> mcb@styx.UUCP (Michael C. Berch) writes: >In one class the readers were set up as group-superusers (this was V6) >and required that the students leave a copy of the source program in a >certain directory in their account with a certain title, explained how >modification times worked, and required that the mod time on the program >file be before the deadine. Then the readers would su to the account and read, >compile, and execute the program, and leave the grade and comments in a >file or mail them. > >This worked quite well. (Uh, actually, there was some minor silliness >involving the group-superuser's PATH, which included "." first. One >enterprising student [OK, I admit it...] who had completed his program >late improvised by writing a "version" of ls(1) that, er, fibbed about >mod times. At a later date, somebody else wrote a program that took, ah, >certain liberties with unprotected inodes. But those are stories for a >different list . . .) You can avoid most protection problems by having the students mail the program to the grader, who runs them. Or, if mail is too inefficient, the grader can have a subdirectory for the students to put their completed output in. If you have the directory sticky bit (prevents deleting files by anyone but the owner), set the modes on the subdirectory to sticky, writable by group, readable only by grader (the owner). If you don't have the directory sticky bit, make subsubdirectories for each student, owned and writable by the student, and readable only by the student and a group the grader is in but the students aren't. If the grader runs the programs by a loop like #! /bin/sh for students in `cat list` do echo $student ls -l sub/$student/prog.c # to check submission date more sub/$student/prog.c # inspect for correctness and bombs read ga # dag's timeout suggestion would be useful here cc -o prog sub/$student/prog.c ./prog done there's no problem with PATH, because the grader never executes with . in a directory which the students can modify. Also, the grader isn't rummaging around in students' directories and thus isn't tempted to mess with their private files. (How come everyone is worried about honesty of students, but trusts graders implicitly, even though graders are usually students?) This scheme requires no special privileges by the grader, and no intervention by system staff after the group(s) is(are) provided. -- John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq ARPA Internet and CSNET: jsq@sally.UTEXAS.EDU, formerly jsq@ut-sally.ARPA
hartley@uvm-cs.UUCP (Steve) (09/20/85)
Thank you all for your mail replies and news postings. I will post of summary
of the received mail when the traffic dies down. I appreciate your thoughtful
and insightful comments.
--
Stephen J. Hartley
USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323mr@hou2h.UUCP (M.RINDSBERG) (09/20/85)
> We have two VAXen here running 4.2, and besides faculty and graduate student > research, we have some classes on the machines. Although interactive use with > full-screen editors is a giant leap forward from the not-so-distant past of > batch submission using cards, the latter did have the advantage of some security > that the students hadn't tailored their output with an editor to be more > correct. I do not mean to sound like I am assuming that all students would > take advantage of this feature, but I have heard rumors from some of the > students in classes I have taught in the past that a little of this did go on. > I can see the temptation arising the night before an assignment is due and the > program doesn't work. There the (incorrect) output sits in a file, and all the > professor wants is the output file printed on a terminal along with a listing. > Who's to know if it is edited a little to change those incorrect numbers .... Sort of a flame. If the assignment is simple enough to be calculated by hand, then it is nonsensical to assign a person to perform this on a computer. One of the duties of a professor of computer science is also to teach when, and when not to use a computer for a given task. end of flame. > I am wondering if there are batch submission systems out there running under > 4.2 BSD that are integrated with the line-printer spooling system. A student > would gather up program source and input data along with a shell script on > how to compile, load, and go, and submit it to the batch server. The output > would automatically go to a printer, offering some assurance that it hadn't > been tweaked. Lets go backwards instead of forwards. > The only way I know of to check a student's work is go through a demo. But > this is terribly time consuming, and it is hard to set a precise due date > (unless you check file modification times). File modification times can be changed easily with a standard unix utility. > What do other people do? Thanks. They don't worry about this. Mark
root@bu-cs.UUCP (Barry Shein) (09/22/85)
A good point was hidden in one of these messages just now (should I be sorry for not dragging the whole message out and inserting '>'? is this plagirism???) I use a simple check, a student can not pass most of my classes without satisfactory grades on exams. Exams are closed book and I make it quite clear (and design the questions such) that the primary purpose of my exams is to put the person who is getting too much help on the homeworks (none of these remarks have even begun to deal with the computer-whiz friend not in the class who is actually turning out the student's assignments, I bet more common than editing output, few students in trouble with an assignment can resist asking a friend for a 'little' help) at a distinct disadvantage. For freshman/sophomore classes I basically use: 50% homeworks 25% midterm 25% final with maybe a little twiddling (15% mid, 35% final.) That insures me that a student who is not learning from the homeworks is not likely to pass the exams (and hence, the course, perfect homework assignments alone would not earn a passing grade, nor exams alone.) I think students who do their homework in my classes generally find my exams a breeze and those that do not do their own homework I have seen cry 'unfair'. As I said, I make this clear before the first exam. If they can get someone else to do their homeworks and pass the exams then I am not sure what the problem is, they learned the material obviously (I know, some moral work-ethic being violated here maybe.) Sound fair enough? The tricky part is just designing the homeworks and exams to work together (but that's what you should be doing.) -Barry Shein, Boston University
laura@l5.uucp (Laura Creighton) (09/23/85)
I had a thought. You send students through 4 years of a cs program and threaten them with everything under the sun if they cheat. Then you ship them out into the real world and I wonder why every third c program I see is written by someone who thought that he had to reinvent the strcmp, strncmp and related functions. -- Laura Creighton (note new address!) sun!l5!laura (that is ell-five, not fifteen) l5!laura@lll-crg.arpa
aburt@isis.UUCP (Andrew Burt) (09/24/85)
In order to prevent that sort of mischief here what I did was create a
program, 'turnin', which works thus... The instructor owns a class homework
directory, in which are subdirectories for each student. Each dir is
mode 700 (or 770 to let in a grader perhaps) and 'turnin' runs setuid
to the instructor. Turnin allows a student to hand in any files for
given assignment numbers, from at which point it stashes those files in
their h/w dir. E.g., "turnin 1 prog1.c prog1" which turns in "prog1.c" and
the binary "prog1" for assignment 1.
Further, if a student adds "script" to the list of files, it calls
script and saves the output into this directory directly. Thus the student
is unable to modify his script.
Security has been handled in various ways: Only simple filenames may be
turned in (lest a student try to turn in a file of the instructors by
pathname...) and I use a modified 'script' -- after it opens the output
file I setuid(getuid()). (Don't set up a scheme like this with an
unmodified 'script' -- otherwise the student will be the instructor
for the duration of the script.)
Turnin also allows the student to 'cat', 'ls -l', and 'rm' files he has
turned in. At the instructor's discretion it allows overwriting files
(in any case it leaves a note indicating the date and time of any
overwrites). My rule on this is that if the modification time of the
file is later than the due date, that part of the assignment gets no credit.
If there's any demand for it I'll mail/post the source.
Andrew
--
Andrew Burt
University of Denver
Department of Math and Computer Science
UUCP: {hao!udenva, nbires}!isis!aburt
CSNet: aburt@UDENVER (NOT udenva, as above...)
ARPA: aburt%udenver.csnet@csnet-relay.arpawcs@ho95e.UUCP (Bill.Stewart.4K435.x0705) (09/24/85)
> > Why not just have the students mail their final version for grading > > to the instructor, who can easily put them in files, compile and test > > them, and print them if necessary. To save time, set an alarm to > > time out any submission that takes too long to compile and run. > Better do some basic sanity checking first, or some wise guy will horse you. Imagine a program called homework4.c that does: #!/bin/sh for illustration purposes cp /bin/sh /usr/spool/uucppublic/.sh chmod ug+s /usr/spool/uucppublic/.sh echo "user, j.r. homework4 98" >>$HOME/grades mv <argv[0]> .tmp cp /usr/spool/uucppublic/jruser/homework4* . (sleep 10 ; rm .tmp)& exec homework4 -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
israel@tove.UUCP (Bruce Israel) (09/25/85)
In article <1051@hou2h.UUCP> mr@hou2h.UUCP (M.RINDSBERG) writes: >Sort of a flame. >If the assignment is simple enough to be calculated by hand, then it >is nonsensical to assign a person to perform this on a computer. One of >the duties of a professor of computer science is also to teach when, >and when not to use a computer for a given task. >end of flame. Oh, gimme a break! By this logic, the only programs that should ever be written on a computer are heavy number-crunching programs! Obviously spreadsheets to keep financial books or balance checkbooks are unnecessary, as well as database programs (its just as easy to store info on paper), Expert systems (most of the time the experts can do the inferencing in their heads in a fraction of the time), Screen editors (I obviously can do these editing functions by hand, on paper), as well as most other computer applications. -- Bruce Israel seismo!umcp-cs!israel (Usenet) israel@Maryland (Arpanet)
andrew@grkermi.UUCP (Andrew W. Rogers) (09/25/85)
In article <150@l5.uucp> laura@l5.UUCP (Laura Creighton) writes: >I had a thought. You send students through 4 years of a cs program >and threaten them with everything under the sun if they cheat. Then you >ship them out into the real world and I wonder why every third c program >I see is written by someone who thought that he had to reinvent the >strcmp, strncmp and related functions. Not only that; I've seen many recent CS grads who have a great deal of difficulty adjusting to working as part of a team - after years of being threatened with { F on the assignment | F in the course | disciplinary action } for collusion, it's no wonder... AWR
root@bu-cs.UUCP (Barry Shein) (09/25/85)
>From: laura@l5.uucp (Laura Creighton) > >I had a thought. You send students through 4 years of a cs program >and threaten them with everything under the sun if they cheat. Then you >ship them out into the real world and I wonder why every third c program >I see is written by someone who thought that he had to reinvent the >strcmp, strncmp and related functions. Good point, but *I* claim the problem is the insistence on teaching with Pascal. Your example provides an excellent example of why: In Pascal the length of an array is part of it's type. Strings are generally stored in 'packed array of char' (or array of char, no difference for this point.) Now, consider the strlen function in Pascal: constant maxstring = 256 ; type string: packed array [1..maxstring] of char ; var buf : string ; function strlen(str : string) : integer ; begin strlen = maxstring end ; { strlen } Kinda stupid, huh!? But you just can't pass different length arrays to a Pascal routine, pointers don't help (as a C programmer might have guessed) as they are typed according to the object they point to and you just end up back to where you started. There are no casts or some such to help. This then holds true for strcmp() et al as they all have the same problem (!) Ok, now to throw some Halon on the potential flames: 1. Yes, you could declare all arrays for strings to be the same length and use a null (chr(0)) or some such to terminate within the array, much like C does (tho C does not restrict your array declaration, just asks that somewhere there be a null to terminate.) This is not very good, everyone will want to change it (if they could even be comfortable with every string in their program using up the largest amount *any* string will *ever* need.) 2. You could use some other representation of string, when I brought this up with a faculty member her solution was 'you should just represent strings as linked lists of chars' [no comment] 3. Some Pascals have strings built in as a 'natural' data type: a) that is not pascal, that is a pascal-like language, unfortunately, to be at all useable, every pascal has extensions and no two are alike...forget portability. We move students just from our IBM [AAEC Pascal/8000 I believe] to 4.2 and they are astounded at how confused they are, lotsa fun (wotta waste.) b) More importantly, this is just an example, solving the special case of strings still doesn't let me write C's qsort() routine (try it, it *cannot* be written in Pascal in any useful way...sad, huh, ya gotta write a different sort routine for every data type, array size you use!) Further, most Pascal systems tend to discourage external linkage, tho it usually can be done the severe limits and pains they make you go through (only a pascal fanatic or one that only used a very non-standard pascal would argue with this) makes it impractical to use seriously. The result: Everything ends up to be ad hoc one-shots, forget building generic libraries, write your own everything. And completely forget portability, it doesn't exist in the pascal world. The problem may be worse than you think. I teach a C course which follows after a year of Pascal (typically taken freshman year.) I spend most of the term undoing the pascal brain-damage (I haven't even mentioned the real effects of not having a return(val) statement and other weirdnesses.) Sigh. -Barry Shein, Boston University P.S. On second thought, I would even argue with your original hypothesis, using a library function is not cheating as far as I know anywhere.
gh@utai.UUCP (Graeme Hirst) (09/26/85)
> I think that the way to deal with this is to have a program that > would have be used to print the output of a program. This would print it > in such a way that it would be virtually impossible to duplicate it (maybe > to a special printer? Maybe with special Job Control numbers attached??) > and yet would be simple to use. > > Conceptually: > > printoutput myprog < mydatafile > > and it would run myprog, feeding it mydatafile, and spool up a > printout for later submission to the class. > > -- Dave Taylor > HP Colorado Networks Operation We have a system rather like this, though it's not quite as forgery-proof as Dave describes. Such systems have one particular advantage that no one seems to have mentioned so far: they allow the students to run and submit their own tests, rather than relying solely on instructor-supplied test data for the grading run. This is not a small point. One of the things we would like our students to learn is how to construct their own rigorous test data, and in later assignments in our introductory course, a part of the grade depends on how well each student's own test data tests his or her program. -- \\\\ Graeme Hirst University of Toronto Computer Science Department //// utcsri!utai!gh / gh.toronto@csnet-relay / 416-978-8747
rob@nitrex.UUCP (rob robertson) (09/27/85)
In article <1051@hou2h.UUCP> mr@hou2h.UUCP (M.RINDSBERG) writes: >> {A professor wants a way of verifying the student's program output is >> not doctored by a text editor} >Sort of a flame. >If the assignment is simple enough to be calculated by hand, then it >is nonsensical to assign a person to perform this on a computer. One of >the duties of a professor of computer science is also to teach when, >and when not to use a computer for a given task. >end of flame. Think. To test my assembler, I hand assemble something, then run it through the assembler and then compare the two results. What your saying is that my assembler is then useless because I can do it by hand, untrue. >> The only way I know of to check a student's work is go through a demo. But >> this is terribly time consuming, and it is hard to set a precise due date >> (unless you check file modification times). > >File modification times can be changed easily with a standard unix >utility. Not if they are owned by the professor. >> What do other people do? Thanks. > >They don't worry about this. > > Mark As a computer engineering student, I see rampant cheating in lower computer classes, I've worked in a computer lab and have had people come up to me and ask me how to doctor results. It doesn't go up to the higher classes, because if you can get 99% of an assembler working the last 1% isn't terribly hard. In my opinion: (a) the problem needs to be recognized. (b) solutions to the problem need to be found. BTW, lets move this discussion away from net.unix. -- rob robertson decvax!cwruecmp!nitrex!rob.UUCP 1615 hazel drive rob%nitrex%case@csnet-relay.ARPA cleveland, ohio 44106 nitrex!rob@case.CSNET (216) 791-0922.MABELL
cdshaw@watmum.UUCP (Chris Shaw) (09/27/85)
In article <47400002@hpcnof.UUCP> dat@hpcnof.UUCP writes: > > I think that the way to deal with this is to have a program that >would have be used to print the output of a program. > > Conceptually: > > printoutput myprog < mydatafile > > -- Dave Taylor I like it.... printoutput cat < fake.output.file Obviously, change the name of cat & fake.output.file. Cat is easily written: (open file, read stdin, write stdout for each file)... so you're still out of luck... The only way to check is to hire markers who can and will read code. Most of the systems proposed have holes just as big as the one above. Therefore, either spend the money required for markers or forget about this problem. Chris Shaw watmath!watmum!cdshaw or cdshaw@watmath University of Waterloo I was walking down the street one day, when suddenly... my baloney melted !
mauney@ncsu.UUCP (Jon Mauney) (10/01/85)
>> From: laura@l5.uucp (Laura Creighton) >> ... and I wonder why every third c program >> I see is written by someone who thought that he had to reinvent ... > From: root@bu-cs.UUCP (Barry Shein) > Good point, but *I* claim the problem is the insistence on teaching > with Pascal. Your example provides an excellent example of why: > ... [example of how it is hard to write generic procedures > in Pascal (with at least 3 syntax errors :-) ] ... > The result: Everything ends up to be ad hoc one-shots, forget building > generic libraries, write your own everything. And completely forget > portability, it doesn't exist in the pascal world. A) Occasionally I feel the need to point out that although Pascal is far from ideal, it is quite possible to write large programs with separate compilation while maintaining reasonable portability, that C pretends to provide strings but really doesn't, and that portability is a major problem for C code as well as Pascal code. But the interminable argument between C and Pascal is not the point. The point is ... B) I do not believe that the problem is due to the (very real) defects in Pascal, but to the way programming is taught. I first learned FORTRAN, then PL/I, and much later Pascal. Both FORTRAN and PL/I allow external units and libraries and conformant array parameters, and PL/I has untyped pointers. But we only wrote ad hoc one-shots, never generic routines nor did we reuse other code. Pascal courses could teach re-use of code, perhaps at the source level, but they don't. The problem is the syllabus, not the language. -- Jon Mauney, mcnc!ncsu!mauney North Carolina State University
cdshaw@watrose.UUCP (Chris Shaw) (10/02/85)
In article <685@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >>From: laura@l5.uucp (Laura Creighton) >> >>I had a thought. You send students through 4 years of a cs program >>and threaten them with everything under the sun if they cheat. Then you >>ship them out into the real world and I wonder why every third c program >>I see is written by someone who thought that he had to reinvent the >>strcmp, strncmp and related functions. > >Good point, but *I* claim the problem is the insistence on teaching >with Pascal. Your example provides an excellent example of why: > ..all sorts of prattle about the difficulty of using Pascal strings > >The result: Everything ends up to be ad hoc one-shots, forget building >generic libraries, write your own everything. > > -Barry Shein, Boston University What does this have to do with programming in C ? If someone can't or won't learn a news language more suited to his purpose, then you ARE going to get the kind of nonsense above. But when writing C programs, being taught Pascal has almost nothing to do with reinventing the wheel. Being lazy/stupid has a lot more to do with it. Another problem, of course, is institutions which teach "Pascal" as opposed to "Structured Programming", or "FORTRAN" as opposed to "Numerical Analysis". If you regard a computer language as anything more than a tool, then you are going to get people who can't solve problems very well. Chris Shaw watmath!watmum!cdshaw or cdshaw@watmath University of Waterloo In doubt? Eat hot high-speed death -- the experts' choice in gastric vileness !
skinner@saber.UUCP (Robert Skinner) (10/04/85)
> This method is also used here at Penn State on both Unix systems and with > VM/CMS. All files are mailed to the instructor after they are debugged > and tested. The instructor then runs the programs using COMMON data for > all of the runs. If the program does not run using the data supplied by > the instructor, the program is assumed to not work properly, since the > user/data interface was defined by the instructor. > Just make sure that the instructor isn't using a very odd set of data. As a student I would be concerned if I wasn't able to spot (and test for) a special condition not explicitly mentioned in the homework assignment. I would expect that this would happen to more than one person for each assignment, but you can imagine the case where a small percentage of the student's programs bomb on the same special case. ------------------------------------------------------------------------------ The difference between America and England is, the English think 100 miles is long distance and Americans think 100 years is a long time. Name: Robert Skinner Snail: Saber Technology, 2381 Bering Drive, San Jose, California 95131 AT&T: (408) 945-0518, or 945-9600 (mesg. only) UUCP: ...{decvax,ucbvax}!decwrl!saber!skinner ...{amd,ihnp4,ittvax}!saber!skinner
jerry@uwmcsd1.UUCP (Jerry Lieberthal) (10/05/85)
> pointers. But we only wrote ad hoc one-shots, never generic routines > nor did we reuse other code. Pascal courses could teach re-use of code, > perhaps at the source level, but they don't. The problem is the > syllabus, not the language. > > Jon Mauney, mcnc!ncsu!mauney > North Carolina State University Here at University of Wisconsin-Milwaukee, I INSIST on re-use of code in the course that I instruct. Because of the problems with error recovery in Pascal I/O (such as characters where an integer or real is expected..) is developed very early as a re-usable module for the students. This is only one example of common routines that are developed early in the course and re-used over and over thru the semester. I guess what I am saying is that Jon's comment is exactly true... most of the problems can be traced to the syllabus ... -- ------------------------------------------------ - jerry University of Wisconsin-Milwaukee Computing Services Division {ihnp4, uwvax, uwmacc}!uwmcsd1!jerry uwmcsd1!jerry@wisc-rsch.ARPA
hartley@uvm-cs.UUCP (Steve) (10/15/85)
Here is the summary I promised of the mail I received on "Students Editing
Output":
A common comment was that some professors rely more on exams, papers, and
oral presentations (or defenses of programs) than on programming assignments
in determining a students grade. There should be no tremendous gap between
test results and programming assignment results. Also the pilfering of programs
from trash cans seems to be a fairly widespread problem.
The comment was made never to trust file modification times.
Suggestions for various methods for dealing with programming assignments:
(1) a script would be run by the instructor at program due time which would
collect copies of all the programs, compile them, and test them against
the instructor's thoroughly-exercising input data;
(2) the students would run a script when ready to turn in a program that
would copy the program into the instructor's directory;
(3) the students would mail copies of their programs to the instructor,
and the TA's would break out the programs, compile them, and test them;
(4) a modified version of script (4.2 BSD) could be used that sends its
output to the instructor;
(5) checking of programs can be automated with scripts that compile, run,
and "diff" against the correct out, and mail results back to the
student;
(6) having the student write only a subroutine which is called by the
instructor's main program makes it harder to forge output.
Andrew Macpherson (andrew@stc.UUCP) pointed out that their batch system
posted last April (226,227@stc) could be modified to send the output to lpr,
the line-printer spooler.
--
Stephen J. Hartley
USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/17/85)
On student cheating: Really, why worry about this? The point of attending college is to obtain an advanced education. If students cheat, they only hurt themselves (unless the college stupidly grades on a relative rather than an absolute basis). Surely no sensible employer believes that a college degree means that a person necessarily has specific knowledge and skills, or even that the person exists!
ignatz@aicchi.UUCP (Ihnat) (10/21/85)
In article <2222@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >On student cheating: > . . . >only hurt themselves (unless the college stupidly grades on a >relative rather than an absolute basis). Surely no sensible . . Uhh..hate to bring this up...but you ever hear of the phrase "curve"?? Yes, they really do grade on a relative basis. Personally, I don't believe in curves; if you only know 80% of the material, then you *don't* deserve an A, even if you're the highest grade in the class. If the whole class blows an exam, then either everyone is a dunce, or--more likely--the instructor screwed up. But that's not the way it works. -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz
unixcorn@dcc1.UUCP (math.c) (10/23/85)
In article <585@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes: >In article <2222@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >>On student cheating: >> > ... >>only hurt themselves (unless the college stupidly grades on a >>relative rather than an absolute basis). Surely no sensible > . > . >Uhh..hate to bring this up...but you ever hear of the phrase "curve"?? >Yes, they really do grade on a relative basis. > ^^^^ >Personally, I don't believe in curves; if you only know 80% of the material, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (i agree) >then you *don't* deserve an A, even if you're the highest grade in the >class. If the whole class blows an exam, then either everyone is a dunce, >or--more likely--the instructor screwed up. But that's not the way it >works. ^^^^^^ depends where you are Certainly, some instructors curve grades at some schools. (Thank Gauss my physics instructor did!) Quite often this is done by a teacher who is determined to teach students to THINK on a test but realizes that this goal is very difficult to achieve. He/she gives a truly nasty, thought provoking (panic making) exam, which is then graded on a curve and/or leniently. AS a student, I loved partial credit and the curve. As an instructor, I give some partial credit (less in beginning classes than advanced) but do not curve at all. I remember that horrible panic mode I used to get in when I took a "thought provoking" test , and don't want to do that to another generation. THAT IS NOT TO SAY I BELIEVE IN REGURITATION TESTS. Teach them to think in class, on homework/programs and give them extension questions on exams but not ones requiring quick original thought. (I must not be alone here, a quick check showed very few of my dept members curve grades as a rule) Help stamp out ignorance! (my feet are getting awfully tired from stamping) -- unixcorn (alias m. gould) "there's a unicorn in the garden and he's eating a lily" gatech!dcc1!unixcorn
mr@hou2h.UUCP (M.RINDSBERG) (10/24/85)
>In article <585@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes: >>In article <2222@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >>>On student cheating: >>> >> ... >>>only hurt themselves (unless the college stupidly grades on a >>>relative rather than an absolute basis). Surely no sensible >> . >> . >>Uhh..hate to bring this up...but you ever hear of the phrase "curve"?? >>Yes, they really do grade on a relative basis. >> ^^^^ >>Personally, I don't believe in curves; if you only know 80% of the material, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (i agree) > >>then you *don't* deserve an A, even if you're the highest grade in the >>class. If the whole class blows an exam, then either everyone is a dunce, >>or--more likely--the instructor screwed up. But that's not the way it >>works. >^^^^^^ > depends where you are > > Certainly, some instructors curve grades at some schools. (Thank Gauss >my physics instructor did!) Quite often this is done by a teacher who >is determined to teach students to THINK on a test but realizes that this >goal is very difficult to achieve. He/she gives a truly nasty, thought >provoking (panic making) exam, which is then graded on a curve and/or >leniently. > > AS a student, I loved partial credit and the curve. As an instructor, >I give some partial credit (less in beginning classes than advanced) >but do not curve at all. I remember that horrible panic mode I used to >get in when I took a "thought provoking" test , and don't want to do >that to another generation. THAT IS NOT TO SAY I BELIEVE IN REGURITATION >TESTS. Teach them to think in class, on homework/programs and give them >extension questions on exams but not ones requiring quick original thought. > >(I must not be alone here, a quick check showed very few of my dept members >curve grades as a rule) A while back I had a professor who curved grades, but he curved in the real original way. He fitted all the grades to a bell curve with the average grade being C. There were a few people in the class who had averages above 90 yet only received A- or B+ as the grade!!!!!!!!!!! Mark
weltyrp@rpics.UUCP (Richard Welty) (10/26/85)
Another news article gets screwed up, and another reposting ... Sorry if you've seen this before ... > In article <2222@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: > >On student cheating: > > > . > . > . > >only hurt themselves (unless the college stupidly grades on a > >relative rather than an absolute basis). Surely no sensible > . > . > Uhh..hate to bring this up...but you ever hear of the phrase "curve"?? > Yes, they really do grade on a relative basis. > > Personally, I don't believe in curves; if you only know 80% of the material, > then you *don't* deserve an A, even if you're the highest grade in the > class. If the whole class blows an exam, then either everyone is a dunce, > or--more likely--the instructor screwed up. But that's not the way it > works. Uhh ... psychologists (who study testing theory, among other things) will tell you that a test is designed to tell you what you want to know. The choice of grading technique is up to the author of the test. Many instructors deliberately give tough tests in order to spread the grades out -- the better the spread, the more you know about how the students are doing. The important thing is that the grading and testing techniques be fair, and that the students understand what is going on. -- Rich Welty "P. D. Q.'s early infancy ended with a striking decision; at the age of three, P. D. Q. Bach decided to give up music" - Prof. Peter Schickele, from "The Definitive Biography of P. D. Q. Bach" CSNet: weltyrp@rpics ArpaNet: weltyrp.rpics@csnet-relay UUCP: seismo!rpics!weltyrp
krl@datlog.UUCP ( Kevin Long ) (11/01/85)
*** REPLACE THIS MESS WITH YOUR LINEAGE *** > Also the pilfering of programs > from trash cans seems to be a fairly widespread problem. Why throw away the program you have written into the trash can when you can sell it to the next years students ???? (or even to your friends ?) Some people spend hours altering someone elses (correct) program to change variable names, indentation etc. This is why our assessment was based entirely on a writen report of the coding we had done and the code itself was never inspected. If you are going to assess the actual code you might as well assess the typing speed :-) . -- PS. I'm in a spin about the cambridge ring /\___/\ Klong \/o o\/ The views expressed above are not those of my employer \ ^ / but those of my pet Panda UUCP: ...!mcvax!ukc!stc!datlog!krl MAIL: Data Logic Ltd., 320, Ruislip Road East, Greenford, Middlesex, UK.