[net.cse] students editing output

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-5323

luner@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-0932

brian@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-0932

david@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!hope

hope@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!hope

rbp@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/message

jma@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!louie

spaf@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!spaf

abc@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-5323

mr@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.arpa

wcs@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-5323

gwyn@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.