L
LurfysMa
I posted a question about this back in September and got some
suggestions. I have made a little more progress and now have a few
more questions. I would appreciate any help anyone can offer.
The application is a utility program for electronic flashcard
applications. At present I am writing both the utility program and the
test applications. The plan is for the utility program to be a black
box utility that can be used with applications I did not write and
that only adhere to the standard calling interface.
The electronic flashcard program has a database of questions and
answers (flashcards) on various subjects. As it runs, it asks the user
the questions and scores the answers. It sends the results
(right/wrong) of each drill to the utility program, which keeps track
of statistics. When the application is ready to ask the next question,
it asks the utility program which one to ask. The utility program
checks its stats and tells the application which question to ask next.
The rough flowchart is:
1. Start application
2. Call GetNext(subjectid)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
The only interface between the application and the utility program are
the two calls at steps 2 & 5. Neither program can access the other's
data.
At step 2, the application calls the utility, which returns the index
of the question most in need of redrilling. It figures this out by
checking its database of previous results. (see below)
At step 5, the application calls the utility to report the results,
which the utility uses to update its statistics.
The utility program has a fairly simple database that looks like this:
tblUtilityStats
subjectid questionid #right #tries #rightconsec
1 5 4 9 2
1 3 6 6 6
1 9 3 4 2
2 7 1 2 0
4 12 0 3 0
1 8 2 2 2
There is an entry for each question that has been asked and some
results on how many times it was gotten right vs wrong.
The application program has a more extensive database containing
questions and answers in various subjects. In the sample below, there
are several subjects related to facts about the US States and a
subject with vocabulary words. In the real database, most of the names
would be replaced by keys.
tblUSStatesCapitals
QuestionID Question Answer
1 Alabama Montgomery
2 Alaska Juneau
3 Arizona Phoenix
tblUSStatesAdmitted
QuestionID Question Answer
1 Alabama 12/14/1819
2 Alaska 01/03/1959
3 Arizona 02/14/1912
tblUSStatesNickname
QuestionID Question Answer
1 Alabama Yellowhammer State
2 Alaska Last Frontier
3 Arizona Grand Canyon State
tblVocabulary
QuestionID Question Answer
1 strident Loud, harsh, grating.
2 supine Lying on the back.
3 prone Lying face down.
4 striated Striped, grooved, or banded.
5 paucity Scarcity, a lacking of.
6 evervate To weaken, deprive of strength
7 attenuate To make slender or thin
There is then a table listing all of the subjects.
tblSubjects
SubjectID Table
1 tblUSStatesCapitals
2 tblUSStatesAdmitted
3 tblUSStatesNickname
4 tblUSStatesMotto
5 tblUSStatesFlower
6 tblUSStatesPopulation
7 tblVocabulary
This all works perfectly. The next enhancement was to allow the user
to select multiple subjects for simultaneous study. This was a simple
change. All that was needed was for the application to pass a list of
SubjectIds at step 2 and have the utility program check all of the
listed subjects.
1. Start application
2. Call GetNext(subjectidlist)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
Where subjectlist = subjectid1[,subjectid2[,subjectid3]] …
The problem arose when I wanted to pass a subset of a subject.
This came up with the vocabulary subject. As the list of words grew
larger, there was a need to subdivide it. Some useful subdivisions are
middle school words, high school words, college entrance exam words,
GRE words, etc. The problem is that these subsets are not orthogonal.
Many of the high school words will also be in the college entrance
exam list. So I cannot break the vocabulary subject up into separate
subjects because then the words that are in multiple subjects will
have multiple subjectids which will screw up the tracking.
The solution I came up with is subsets. That is, separate lists with
indices into the vocabulary subject table.
tblGRE
strident
supine
prone
…
tblACT
strident
striated
paucity
evervate
attenuate
…
But these are NOT subjects, so they do not have a subjectid. The word
"strident" will always have subjectid=7 for the vocabulary subject.
My thinking it so crate a reordset containing the list of questionids
and pass that in the GetNext parameter string at step 2
1. Start application
2. Call GetNext(subjectidlist)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
Where subjectlist = subjectid1,[recordset1][, subjectid2,[recordset2]]
…
Is this a good solution? Is there something better?
Once the vocabulary subject gets up to 20,000 words, some of the
recordsets could contain 4-5K entries.
Thanks for your help and suggestions
suggestions. I have made a little more progress and now have a few
more questions. I would appreciate any help anyone can offer.
The application is a utility program for electronic flashcard
applications. At present I am writing both the utility program and the
test applications. The plan is for the utility program to be a black
box utility that can be used with applications I did not write and
that only adhere to the standard calling interface.
The electronic flashcard program has a database of questions and
answers (flashcards) on various subjects. As it runs, it asks the user
the questions and scores the answers. It sends the results
(right/wrong) of each drill to the utility program, which keeps track
of statistics. When the application is ready to ask the next question,
it asks the utility program which one to ask. The utility program
checks its stats and tells the application which question to ask next.
The rough flowchart is:
1. Start application
2. Call GetNext(subjectid)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
The only interface between the application and the utility program are
the two calls at steps 2 & 5. Neither program can access the other's
data.
At step 2, the application calls the utility, which returns the index
of the question most in need of redrilling. It figures this out by
checking its database of previous results. (see below)
At step 5, the application calls the utility to report the results,
which the utility uses to update its statistics.
The utility program has a fairly simple database that looks like this:
tblUtilityStats
subjectid questionid #right #tries #rightconsec
1 5 4 9 2
1 3 6 6 6
1 9 3 4 2
2 7 1 2 0
4 12 0 3 0
1 8 2 2 2
There is an entry for each question that has been asked and some
results on how many times it was gotten right vs wrong.
The application program has a more extensive database containing
questions and answers in various subjects. In the sample below, there
are several subjects related to facts about the US States and a
subject with vocabulary words. In the real database, most of the names
would be replaced by keys.
tblUSStatesCapitals
QuestionID Question Answer
1 Alabama Montgomery
2 Alaska Juneau
3 Arizona Phoenix
tblUSStatesAdmitted
QuestionID Question Answer
1 Alabama 12/14/1819
2 Alaska 01/03/1959
3 Arizona 02/14/1912
tblUSStatesNickname
QuestionID Question Answer
1 Alabama Yellowhammer State
2 Alaska Last Frontier
3 Arizona Grand Canyon State
tblVocabulary
QuestionID Question Answer
1 strident Loud, harsh, grating.
2 supine Lying on the back.
3 prone Lying face down.
4 striated Striped, grooved, or banded.
5 paucity Scarcity, a lacking of.
6 evervate To weaken, deprive of strength
7 attenuate To make slender or thin
There is then a table listing all of the subjects.
tblSubjects
SubjectID Table
1 tblUSStatesCapitals
2 tblUSStatesAdmitted
3 tblUSStatesNickname
4 tblUSStatesMotto
5 tblUSStatesFlower
6 tblUSStatesPopulation
7 tblVocabulary
This all works perfectly. The next enhancement was to allow the user
to select multiple subjects for simultaneous study. This was a simple
change. All that was needed was for the application to pass a list of
SubjectIds at step 2 and have the utility program check all of the
listed subjects.
1. Start application
2. Call GetNext(subjectidlist)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
Where subjectlist = subjectid1[,subjectid2[,subjectid3]] …
The problem arose when I wanted to pass a subset of a subject.
This came up with the vocabulary subject. As the list of words grew
larger, there was a need to subdivide it. Some useful subdivisions are
middle school words, high school words, college entrance exam words,
GRE words, etc. The problem is that these subsets are not orthogonal.
Many of the high school words will also be in the college entrance
exam list. So I cannot break the vocabulary subject up into separate
subjects because then the words that are in multiple subjects will
have multiple subjectids which will screw up the tracking.
The solution I came up with is subsets. That is, separate lists with
indices into the vocabulary subject table.
tblGRE
strident
supine
prone
…
tblACT
strident
striated
paucity
evervate
attenuate
…
But these are NOT subjects, so they do not have a subjectid. The word
"strident" will always have subjectid=7 for the vocabulary subject.
My thinking it so crate a reordset containing the list of questionids
and pass that in the GetNext parameter string at step 2
1. Start application
2. Call GetNext(subjectidlist)
3. Ask the user the question
4. Check the answer
5. Call ReportResult(subjectid,questionid)
6. Go to 2.
Where subjectlist = subjectid1,[recordset1][, subjectid2,[recordset2]]
…
Is this a good solution? Is there something better?
Once the vocabulary subject gets up to 20,000 words, some of the
recordsets could contain 4-5K entries.
Thanks for your help and suggestions