Menu
▾
▴
Re: [WWdevel] webwork: problem values getting set to zero
|
From: John J. <jj...@as...> - 2005-07-14 19:11:43
|
Michael Gage wrote: > Ok. so for the "value" (amount the problem is worth) variable. > > Positive numeric states clearly have meaning. > the 0 state should have meaning also -- probably indicating that it= is=20 > an optional problem -- certainly that it gets no credit. > > What is the interpretation of the NULL state or the "" to be? Do we= =20 > have or can we imagine > a use for states of "value" that are not numeric? The "value" of a problem has a value for the whole class (usually 1)= =20 which can be overridden for an individual student. You can make a= =20 problem worth 1 point for almost all of your students but worth 0 poi= nts=20 (or 2 points) for an individual student. Like any field which has a global value which can be overridden for= =20 individuals, NULL or "" means to use the default for the class wherea= s 0=20 means replace the classwide value with 0. By the way, I just discovered that the current CVS version of webwork= is=20 not backward compatible with courses created before the gateway stuff= =20 was merged in. Is there a conversion tool yet, or will there be? John > If we are always going to use it as an integer, there is no reason= =20 > that we can't enforce that it is an integer. > If we are going to use other states we should try to be clear about= =20 > how these states should be interpreted. > > Take care, > > Mike > On Jul 14, 2005, at 2:03 PM, John Jones wrote: > > This discussion of storing the student's score refers to the > student-problem field status. It was not affected by my change= s > to the types of fields in mysql databases - it is still stored = as > type text rather than type int. (Maybe it should be stored as = an > int, but that's a different question.) > > The problem Gavin discovered was with value - the number of poi= nts > the problem is worth. It is one of several fields currently > stored as type int, and they probably all will suffer the same > difficulty if they are override fields for a more global value.= =20 > It is a pretty serious bug, so I will attempt to fix this as so= on > as we know which way we want to go. > > I think our options are: > =95 in all cases, when storing "" in the database, store it as > NULL. It will be promoted back when the information is > retrieved. I think this is safe. > =95 when storing back to the database, only demote "" to NULL i= f the > field is of integer type. > =95 stop using integer types in the database. > > John > > > Michael Gage wrote: > > On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote: > > > Isn't the distinction between "haven't tried" and "scor= e > of zero" also > captured by the attempted field in problem_user? I thi= nk > if the status > codes this also, it's redundant information. > > Am I making sense? > Gavin > > > when extracting scoring data because we were getting a lot > spurious > "undefined variables" warnings. We also get a lot of > "non-numeric in comparison" errors > when sorting, etc. etc. etc. In any case I think this is w= hy > most things are promoted > from null at least to "" or to 0. > > In light of what you have pointed out I suggest that we > "insist" that the student score > be a number. I believe that blanks are automatically > converted to 0, so they would be ok in sorts. > (I haven't checked this.) Otherwise we'll need checks in > every sort routine as well as other places. > Use the "attempts" field to determine if the problem hasn't > been tried yet. > > We may need to fix some assumptions in the grading and scor= ing > packages to conform to this. > The simplification in sorts that we gain by assuming that > score is always a number seems to > me to outweigh desires for more, occasionally non-numeric s= tates. > > Take care, > > Mike > > > On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote: > > Could we get a list of what states are needed for t= he > student score? > > number -- means the student has achieved this > score on this problem > 0 -- means the student has tried th= is > problem but > hasn't gotten in correct > null/ blank -- means that the student hasn't tried > the problem. > > Are there are other states we need? > > Do we need the state that distinguishes between > "hasn't tried the > problem" and the one where the score is zero? > I think perhaps we do, so that we can warn the stud= ent > they haven't yet > completed an assignment while not > bugging them about problems that they haven't > successfully completed. > > any other thoughts on what is needed? > > Take care, > Mike > > > --=20 > P. Gavin LaRose, Ph.D. Program Manager (Instructional = Tech.) > Math Dept., University of Michigan > gl...@um... "There's no us= e > in trying," [Alice] > 734.764.6454 said. "One Can= 't > believe impossible > http://www.math.lsa.umich.edu/~glarose/ things." "I > daresay you haven't had > much practice,= " > said the Queen. > = =20 > - Lewis Carrol > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > from IBM. Find simple to follow Roadmaps, straightforward > articles, > informative Webcasts and more! Get everything you need to g= et > up to > speed, fast. > http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli= ck > _______________________________________________ > OpenWeBWorK-Devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openwebwork-de= vel > > |
