## Forum archive 2000-2006

### Gavin LaRose - subsequent problems having same seed

by Arnold Pizer -
Number of replies: 0
 subsequent problems having same seed topic started 6/20/2002; 1:54:26 AMlast post 6/25/2002; 4:09:39 AM
 Gavin LaRose - subsequent problems having same seed  6/20/2002; 1:54:26 AM (reads: 1150, responses: 7) What I'd like to do is take a long multi-part problem and split it into several problem files. To make this work, however, each problem file would need to have the same data---that is, the same problem seed. I'm thinking that in practice probably the only way to do this is to set the seed for each of the problem files to the same, arbitrary value (e.g., something to do with the psvn). Is there a better way that I've not thought of? Following up with this thought, is it possible to include information that a student submitted in a previous problem in the current one? For example, in problem 1 the student includes a function "foo" as one answer. For problem 2, we want the student to use this function. Thus we'd like to have the problem show up saying something like:  In problem 1 you entered the function: foo Use this function to... Is this possible? It looks like processProblem8 has access to this data, but it's not clear to me how to or whether it could be included in the problem. Thanks! Gavin <| Post or View Comments |>

 Michael Gage - Re: subsequent problems having same seed  6/20/2002; 2:49:33 AM (reads: 1313, responses: 0) Hi Gavin,CAPA originally used the psvn to generate seeds, but we've found that it can be rather constraining -- too many dependencies that aren't really related. In particular the psvn's, currently generated randomly, are really just unique identifiers for each record in the database. If one switches databases (something we're working hard on) the results may change. The new database model would give you control over setting the seed for each problem and you could write your own routine for deciding the dependencies. Here's my suggestion -- it's a kludge which will work in the meantime -- and changes code in a minimal number of places. The idea is that in the setDefinion file we can add an extra field -- set to 1 it demands that we use the seed from the previous problem. Set to 0 or omitted gives the current behavior. In FILE.pl change the readSetDef subroutine to check for the extra field and return (as a last variable) a reference to the new array of directives as to whether or not to use the previous seed. (Perhaps force the 0th element to always be zero, since you will never? use the seed given to the previous student.) Next, in the proceduresForBuildProbSetDB.pl and the subroutine buildProbSetDB accept the extra array reference -- approximatly line 49-50 Finally at line 281--282 modify the lines so that the seed is chosen appropriately -- if the method is not "readFromLogFile" then check to see if you are supposed to reuse the seed. if so reuse it, otherwise generate a new one. In each case save a copy of the seed in a variable whose scope contains the while statement looping through the problems. This will be needed for the next problem in case it wants to reuse the seed. This change should be backword compatible, so if you get time to hack it we can put it in our CVS for others who would like to do this. It's a nice new feature. We'll make sure it is included, in a cleaner way, in the next version. Take care, Mike <| Post or View Comments |>

 Michael Gage - Re: subsequent problems having same seed  6/20/2002; 2:50:02 AM (reads: 1288, responses: 0) Hi Gavin, CAPA originally used the psvn to generate seeds, but we've found that it can be rather constraining -- too many dependencies that aren't really related. In particular the psvn's, currently generated randomly, are really just unique identifiers for each record in the database. If one switches databases (something we're working hard on) the results may change. The new database model would give you control over setting the seed for each problem and you could write your own routine for deciding the dependencies. Here's my suggestion -- it's a kludge which will work in the meantime -- and changes code in a minimal number of places. The idea is that in the setDefinion file we can add an extra field -- set to 1 it demands that we use the seed from the previous problem. Set to 0 or omitted gives the current behavior. In FILE.pl change the readSetDef subroutine to check for the extra field and return (as a last variable) a reference to the new array of directives as to whether or not to use the previous seed. (Perhaps force the 0th element to always be zero, since you will never? use the seed given to the previous student.) Next, in the proceduresForBuildProbSetDB.pl and the subroutine buildProbSetDB accept the extra array reference -- approximatly line 49-50 Finally at line 281--282 modify the lines so that the seed is chosen appropriately -- if the method is not "readFromLogFile" then check to see if you are supposed to reuse the seed. if so reuse it, otherwise generate a new one. In each case save a copy of the seed in a variable whose scope contains the while statement looping through the problems. This will be needed for the next problem in case it wants to reuse the seed. This change should be backword compatible, so if you get time to hack it we can put it in our CVS for others who would like to do this. It's a nice new feature. We'll make sure it is included, in a cleaner way, in the next version. Take care, Mike <| Post or View Comments |>