Menu
▾
▴
openwebwork-devel
|
From: P G. L. <gl...@um...> - 2005-07-14 15:38:59
|
Hi all,
In the course of adding the GatewayQuiz module to the HEAD branch in the
CVS, I've found that when I look at StudentProgress all student scores are
being reported as zero (regardless of how many correct problems they have
in the set).
I think what's happening is that when we get NULL values out of the
database they are promoted to empty strings, but when we put an empty
string back into an integer field in the database that gets stored as
zero.
In particular, when a set is assigned to a student the appropriate entries
in the problem_user table are created. For those the value field is set
to NULL. When we get() the problems out of the table (with
$db->{problem_user}->get()), the NULL is promoted to "", so that
$userProblem->value() is then the empty string.
As the user problem is processed by Problem.pm (or GatewayQuiz.pm),
$userProblem->value() isn't changed. Then, when we put the problem back
into the database after grading (with $db->{problem_user}->put()), we're
putting an empty string into the integer value field, which is stored as
zero.
When we then get the merged problem out again, $db->getMergedProblem()
checks for empty fields to decide whether to use the global problem's
value. However the entry in problem_user now has value == 0, so the
global problem's value (== 1) isn't used. This means that when
StudentProgress.pm (et al.) calculate the student's score (by taking
$userProblem->status() * $userProblem->value()), the score is zero.
Does that sound right? If so, the work-around/solution may be to make
$db->{}->put() demote empty strings to NULL. Comments?
Thanks,
Gavin
--
P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um... "There's no use 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.
- Lewis Carrol
|
|
From: John J. <jj...@as...> - 2005-07-14 16:11:33
|
Hi everyone, Are the files ok? I just looked at SetMaker.pm through the web-cvs. The diffs to the previous version have lines added like >>>>>>> 1.20.2.2 This is a sign that a "cvs update" was done, there were conflicts which were not fixed, and then a "cvs commit" which would have put all of the conflict markers in the files in cvs. John |
|
From: P G. L. <gl...@um...> - 2005-07-14 16:21:03
|
Hi John, That's my error. I'll double check the other files that had conflicts. I thought I had caught all of them, but obviously missed that one. Gavin On Thu, 14 Jul 2005 at 09:13 John Jones wrote: > Hi everyone, > > Are the files ok? > > I just looked at SetMaker.pm through the web-cvs. The diffs to the > previous version have lines added like > > >>>>>>> 1.20.2.2 > > This is a sign that a "cvs update" was done, there were conflicts which > were not fixed, and then a "cvs commit" which would have put all of the > conflict markers in the files in cvs. > > John > > -- P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.) Math Dept., University of Michigan gl...@um... "There's no use 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. - Lewis Carrol |
|
From: Michael G. <ga...@ma...> - 2005-07-14 16:22:00
|
Hi John, Gavin is in the process of a massive update to HEAD to add all of the=20 Gateway quiz stuff. Things may be a bit iffy for 24 hours or so. I'm at work for the next 3 hours or so, but=20 once I get home I have a copy of the installation which I can use to get rid of any remaining conflicts. I put a warning=20= out a week ago on the home page to be cautious about updating to HEAD for a little while until we get=20 things under control. Take care, Mike On Jul 14, 2005, at 12:13 PM, John Jones wrote: > Hi everyone, > > Are the files ok?=A0 > > I just looked at SetMaker.pm through the web-cvs.=A0 The diffs to the=20= > previous version have lines added like > > >>>>>>> 1.20.2.2 > > This is a sign that a "cvs update" was done, there were conflicts=20 > which were not fixed, and then a "cvs commit" which would have put all=20= > of the conflict markers in the files in cvs. > > John > |
|
From: John J. <jj...@as...> - 2005-07-14 16:24:47
|
This sounds like it is my fault since I changed field types from all
being strings to being types related to what was being stored. What you
suggest is probably the best course of action. I wonder if all
instances of "" should be demoted to NULL, or if it should only be done
for fields with type integer.
Another possibility would be to revert part of my change so that integer
types would not be used in the future which would avoid the promotion
problem for courses created after that.
John
P Gavin LaRose wrote:
>Hi all,
>
>In the course of adding the GatewayQuiz module to the HEAD branch in the
>CVS, I've found that when I look at StudentProgress all student scores are
>being reported as zero (regardless of how many correct problems they have
>in the set).
>
>I think what's happening is that when we get NULL values out of the
>database they are promoted to empty strings, but when we put an empty
>string back into an integer field in the database that gets stored as
>zero.
>
>In particular, when a set is assigned to a student the appropriate entries
>in the problem_user table are created. For those the value field is set
>to NULL. When we get() the problems out of the table (with
>$db->{problem_user}->get()), the NULL is promoted to "", so that
>$userProblem->value() is then the empty string.
>
>As the user problem is processed by Problem.pm (or GatewayQuiz.pm),
>$userProblem->value() isn't changed. Then, when we put the problem back
>into the database after grading (with $db->{problem_user}->put()), we're
>putting an empty string into the integer value field, which is stored as
>zero.
>
>When we then get the merged problem out again, $db->getMergedProblem()
>checks for empty fields to decide whether to use the global problem's
>value. However the entry in problem_user now has value == 0, so the
>global problem's value (== 1) isn't used. This means that when
>StudentProgress.pm (et al.) calculate the student's score (by taking
>$userProblem->status() * $userProblem->value()), the score is zero.
>
>Does that sound right? If so, the work-around/solution may be to make
>$db->{}->put() demote empty strings to NULL. Comments?
>
>Thanks,
>Gavin
>
>
>
|
|
From: Michael G. <ga...@ma...> - 2005-07-14 16:39:52
|
Could we get a list of what states are needed for the student score? number -- means the student has achieved this score on this problem 0 -- means the student has tried this 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 student 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 On Jul 14, 2005, at 12:26 PM, John Jones wrote: > This sounds like it is my fault since I changed field types from all > being strings to being types related to what was being stored. What > you suggest is probably the best course of action. I wonder if all > instances of "" should be demoted to NULL, or if it should only be > done for fields with type integer. > > Another possibility would be to revert part of my change so that > integer types would not be used in the future which would avoid the > promotion problem for courses created after that. > > John |
|
From: Michael G. <ga...@ma...> - 2005-07-14 16:55:18
|
On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote: > > Isn't the distinction between "haven't tried" and "score of zero" also > captured by the attempted field in problem_user? I think if the status > codes this also, it's redundant information. > > Am I making sense? > Gavin > That makes sense to me. I believe that we tried to eliminate all of the null responses 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 why 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 scoring 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 states. 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 the student score? >> >> number -- means the student has achieved this score on this >> problem >> 0 -- means the student has tried this 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 student 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 > > -- > P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.) > Math Dept., University of Michigan > gl...@um... "There's no use 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. > - Lewis > Carrol > |
|
From: John J. <jj...@as...> - 2005-07-14 18:04:27
|
This discussion of storing the student's score refers to the
student-problem field status. It was not affected by my changes 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 points 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. It is a pretty serious bug, so
I will attempt to fix this as soon as we know which way we want to go.
I think our options are:
* 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.
* when storing back to the database, only demote "" to NULL if the
field is of integer type.
* 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 "score of zero" also
>> captured by the attempted field in problem_user? I think if the status
>> codes this also, it's redundant information.
>>
>> Am I making sense?
>> Gavin
>>
> That makes sense to me. I believe that we tried to eliminate all of
> the null responses
> 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 why 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 scoring
> 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 states.
>
> 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 the student score?
>>>
>>> number -- means the student has achieved this score on this problem
>>> 0 -- means the student has tried this 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 student 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
>>
>>
>> --
>> P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.)
>> Math Dept., University of Michigan
>> gl...@um... "There's no use 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.
>> - 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 get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
|
|
From: P G. L. <gl...@um...> - 2005-07-14 18:12:45
|
Hi John,
I think
* 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.
is the easiest fix. Aesthetically I like the idea of calling something
that has integer values an integer when defining the database, so from a
purely artistic viewpoint I'd vote against
* stop using integer types in the database.
Gavin
On Thu, 14 Jul 2005 at 11:03 John Jones wrote:
> This discussion of storing the student's score refers to the
> student-problem field status. It was not affected by my changes 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 points 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. It is a pretty serious bug, so
> I will attempt to fix this as soon as we know which way we want to go.
>
> I think our options are:
> * 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.
> * when storing back to the database, only demote "" to NULL if the
> field is of integer type.
> * 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 "score of zero" also
> >> captured by the attempted field in problem_user? I think if the status
> >> codes this also, it's redundant information.
> >>
> >> Am I making sense?
> >> Gavin
> >>
> > That makes sense to me. I believe that we tried to eliminate all of
> > the null responses
> > 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 why 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 scoring
> > 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 states.
> >
> > 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 the student score?
> >>>
> >>> number -- means the student has achieved this score on this problem
> >>> 0 -- means the student has tried this 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 student 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
> >>
> >>
> >> --
> >> P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.)
> >> Math Dept., University of Michigan
> >> gl...@um... "There's no use 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.
> >> - 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 get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > OpenWeBWorK-Devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>
>
>
--
P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um... "There's no use 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.
- Lewis Carrol
|
|
From: P G. L. <gl...@um...> - 2005-07-14 16:42:57
|
Hi John, In that get() promotes NULL to "" anyway, it's not clear to me that we can tell the difference between fields that are "" in the database and those which are NULL. Does that make sense? The only place that I can think that we grab data out of the database without using get() is with list(), which I think gets indexed/key fields which can't be null. So I think from anywhere at the level of DB.pm or above we can't tell if a field is empty or NULL, in which case it shouldn't matter if all empty fields are stored as NULL. Gavin On Thu, 14 Jul 2005 at 09:26 John Jones wrote: > This sounds like it is my fault since I changed field types from all > being strings to being types related to what was being stored. What you > suggest is probably the best course of action. I wonder if all > instances of "" should be demoted to NULL, or if it should only be done > for fields with type integer. > > Another possibility would be to revert part of my change so that integer > types would not be used in the future which would avoid the promotion > problem for courses created after that. > > John -- P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.) Math Dept., University of Michigan gl...@um... "There's no use 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. - Lewis Carrol |
|
From: Michael G. <ga...@ma...> - 2005-07-14 18:50:10
|
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? If we are always going to use it as an integer, there is no reason that=20= we can't enforce that it is an integer. If we are going to use other states we should try to be clear about how=20= 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=20 > student-problem field status.=A0 It was not affected by my changes to=20= > the types of fields in mysql databases - it is still stored as type=20 > text rather than type int.=A0 (Maybe it should be stored as an int, = but=20 > that's a different question.) > > The problem Gavin discovered was with value - the number of points=20 > the problem is worth.=A0 It is one of several fields currently stored = as=20 > type int, and they probably all will suffer the same difficulty if=20 > they are override fields for a more global value.=A0 It is a pretty=20 > serious bug, so I will attempt to fix this as soon as we know which=20 > way we want to go. > > I think our options are: > =95 in all cases, when storing "" in the database, store it = as NULL.=A0=20 > It will be promoted back when the information is retrieved.=A0 I think=20= > this is safe. > =95 when storing back to the database, only demote "" to = NULL if the=20 > 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 "score of zero"=20= >>> also >>> captured by the attempted field in problem_user?=A0 I think if the=20= >>> 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.=A0 We also get a=A0 lot of = "non-numeric=20 >> in comparison" errors >> when sorting, etc. etc. etc.=A0 In any case I think this is why most=20= >> things are promoted >> from null at least to "" or to 0. >> >> In light of what you have pointed out I suggest that we "insist"=20 >> that the student score >> be a number.=A0 I believe that blanks are automatically converted to=20= >> 0, so they would be ok in sorts. >> (I haven't checked this.)=A0 Otherwise we'll need checks in every = sort=20 >> routine as well as other places. >> Use the "attempts" field to determine if the problem hasn't been=20 >> tried yet. >> >> We may need to fix some assumptions in the grading and scoring=20 >> packages to conform to this. >> The simplification in sorts that we gain by assuming that score is=20= >> always a number seems to >> me to outweigh desires for more, occasionally non-numeric states. >> >> 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 the student = score? >>>> >>>> number=A0=A0=A0=A0 -- means the student has achieved this score on = this=20 >>>> problem >>>> 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --=A0 means the = student has tried this problem but >>>> hasn't gotten in correct >>>> null/ blank=A0 -- 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 student they=20 >>>> haven't yet >>>> completed an assignment while not >>>> bugging them about problems that they haven't successfully=20 >>>> completed. >>>> >>>> any other thoughts on what is needed? >>>> >>>> Take care, >>>> Mike >>> >>> --=A0 >>> P. Gavin LaRose, Ph.D.=A0 Program Manager (Instructional Tech.) >>> Math Dept., University of Michigan >>> gl...@um...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 "There's no use in trying,"=20 >>> [Alice] >>> 734.764.6454=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 said. "One Can't believe=20 >>> impossible >>> http://www.math.lsa.umich.edu/~glarose/=A0 things." "I daresay you=20= >>> haven't had >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 much practice," said = the=20 >>> Queen. >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -=20 >>> Lewis Carrol >>> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration=20 >> Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dc= lick >> _______________________________________________ >> OpenWeBWorK-Devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel > |
|
From: P G. L. <gl...@um...> - 2005-07-14 19:11:07
|
Hi Mike, I think the only interpretation of NULL is in the problem_user table, where it indicates that the global (problem table) value should be used. If this is the case, NULL can't be meaningful in the problem table, because it would be impossible to override a value in the problem table with 'NULL' from the problem_user table. Is there ever a case where 0 credit on a problem would mean anything other than that it was optional? Gavin I think that this means On Thu, 14 Jul 2005 at 14:49 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 > an optional problem -- certainly that it gets no credit. > > What is the interpretation of the NULL state or the "" to be? Do we > have or can we imagine > a use for states of "value" that are not numeric? > > If we are always going to use it as an integer, there is no reason 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 how > these states should be interpreted. > > Take care, > > Mike -- P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.) Math Dept., University of Michigan gl...@um... "There's no use 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. - Lewis Carrol |
|
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 > > |
|
From: P G. L. <gl...@um...> - 2005-07-14 19:26:33
|
On Thu, 14 Jul 2005 at 12:11 John Jones wrote: > > By the way, I just discovered that the current CVS version of webwork is > not backward compatible with courses created before the gateway stuff > was merged in. Is there a conversion tool yet, or will there be? Oops. I'm thinking this is because of the added set and set_user tables in the database. No conversion tool yet, but I think all that needs to be done is to add the additional columns to the tables: alter table [classname]_set add column assignment_type text; alter table [classname]_set add column attempts_per_version integer; alter table [classname]_set add column time_interval integer; alter table [classname]_set add column versions_per_interval integer; alter table [classname]_set add column version_time_limit integer; alter table [classname]_set add column version_creation_time bigint; alter table [classname]_set add column problem_randorder integer; alter table [classname]_set add column version_last_attempt_time bigint; and similarly for set_user. Gavin -- P. Gavin LaRose, Ph.D. Program Manager (Instructional Tech.) Math Dept., University of Michigan gl...@um... "There's no use 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. - Lewis Carrol |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X