Home: Welcome to the MathEngine wiki! - VSAResearchGroup/MathEngine GitHub Wiki
This document captures the outline for the mathematical engine, responsible for translating the pre-requisite networks into degree-plan pools. Each degree plan pool will contain n-number of degree-plans, based upon the constraints implied by the linear-equations used in the mathematical engine. These constraints would be fed by the students based upon their availability, course requirements, degree goals, and so on. The mathematical engine is based upon a bunch of linear inequalities, and trigonometric theorems, which uses the user constraints as the input to solve the intersection points of these linear equations. Various intersection points of these equations enclose the search space (containing all the courses) and filter out courses according to a students requirements. Future versions of the mathematical engine can also be used to do big data analysis on academic data collected from various educational institutions and disclose hidden trends of society.
0.1 Introduction
Despite of technological advances, well-established activities in the field of education and training are primarily untouched by the impact of technology. A number of these well-established tasks are being carried out with human effort, redundantly, because of laxity of well-defined rules and procedures that are put into completing these tasks. The range of such tasks vary from student advising to career counseling. Such complex activities heavily depend upon heterogeneous information and unpredictable human-information interactions. Although, such tasks can be well-accomplished with the help of modern paradigms of computing such as artificial intelligence, but they also require formatted patterns of well-defined data to be fed as input.
In this project, we are trying to automate the student advising for community colleges. Despite of the wide disparity between financial liability for pursuing university-level degree and that for college-level degree, a large number of students move forward towards pursuing a baccalaureate/graduate level degree from a university, after obtaining an associates degree from a community college. In order to do so in a financially viable way, students tend to fulfill a certain number of particular type of curricular credits at the community college and transfer them to their respective universities. This way, students cover all the required courses while also cutting the costs incurred towards their degree. These credits are also required for fulfilling the admission criteria towards the desired degree programs.
In order to facilitate for the same along with catering a greater student turnout, community college professors are usually assigned with the duty to provide for the advisory services to the students, along with practicing regular duties of a teacher. Providing advisory along with regular academic routine not only becomes cumbersome but also brings down the efficiency and finesse of the whole process. The project, Virtual Student Advisor strives to provide technological aid to this system and help students in a more effective and efficient way. With the help of this projects, students would be able to choose amongst the best possible academic routes to transition into the desired degree programs, without human intervention. The holistic view of proposed advisory system not only takes into consideration the academic prerequisites such as the core courses or the number credits required, but also considers the qualitative and socioeconomic factors about the students such as the time of his/her class, whether he/she can pay for their courses chosen or the course load needs to be spread across a longer time duration.
The Virtual Student Advisor (VSA) project meritoriously attempts to address this unique situation with an effort to minimize human intervention at a scalable level.
0.2 Problem Statement
In order to provide for advising services, advisors are required to understand the course stipulations that are required to be fulfilled by the students before obtaining admission in that course at a university level. These course requirements are then translated into target courses and pre-requisite credits by the advisor. Target courses define the various courses which are required to be studied by the student at the community college in order to fulfill the admission requirements. Pre-requisite credits define the minimum total number of credits required by the students to obtain admission at a university level course. The pre-requisite credits are usually tightly coupled with the target courses and they get transferred to the university once the student obtains the admission.
In order to fulfill both of these requirements, academic advisors provide a list of prerequisite courses for each quarter that are required to be completed by the student before he/she can study the target courses. Most of these courses are prerequisites to each other and they also contribute towards credits earned by the students. In order to do so, academic advisors take into consideration various constraints such as availability of student throughout the week, budgetary constraints governed by the students financial conditions, availability of courses at different times of year, schedule of different courses, students employability conditions and pertaining restrictions, along with other real-life limitations and restraints.
As a result of the advisory process, students obtain an academic plan that defines various courses that are suggested to be studied by the student in order to achieve his/her academic targets. These plans are not static and can be subject to a change whenever student experiences a change in any of his/her socio-economic factors.
0.3 Proposed Framework for Virtual Student Advisor
In this project, we propose an independent recommendation engine to provide on-demand advising services to the host institution. The proposed recommendation engine would be integrated into the existing technological infrastructure of the host institution. The primary goal of this project is to establish provide a platform for seamless and intelligent student advising service which can be customized to the needs of different educational institutions of different sizes.
VSA is being developed using two different approaches, concurrently. These two approaches include, the conventional method of using backtracking algorithms for determining different academic possible paths that can be taken by a student, and the other approach where we are developing a mathematical model of the problem statement and deploy a set of linear inequalities to find possible solutions. In this report, we shall focus on the second approach towards realizing Virtual Student Advisor which involves modelling the target courses, students constraints, and academic restraints, as a set of definite linear-inequalities.
These inequalities can be applied over the search-space comprising of different courses available in a college. When these inequalities are solved, their points of intersection bound the plane of search-space. This trimmed down plane of search-space lists all the courses which can be taken by the student while preserving the various academic or socio-economic constraints.
0.3.1 End-User Constraints & Environmental Factors
Creating an academic plan involves analysis complex real-life constraints related to the student. These constraints cannot be decided once for all, but the academic plans are required to be revised repeatedly whenever these constraints change. Sometimes, academic plans may require a revision if these constraints change in the middle of a quarter. For example, if a student was working fulltime when he started the community college program, he or she can attend to college as a part-time student, taking fewer courses, and will have lesser number of credits available for them to take; whereas if the student converts his/her employability status to part-time, he/she may be able to enroll themselves as a full-time student and be able to cover more number of courses in less time. Hence, in the first case, the student might take longer time to finish their degree than that in the first case. Thus, it would not only affect the credits distribution but also the budget and financial aid available at the disposal of the student.
Since such constraints are governed by various real-life socio-economic factors, they may not be levied from the students side only but they can also be imposed by the institution itself, or may just be an effect of current setting of these factors. Therefore, while modeling VSA recommendation engine mathematically, we do not focus on these factors, rather we shortlisted the constraints to focus upon and formulated them into mathematical linear-equations. We considered the following constraints for creating the mathematical recommendation engine for the Virtual Student Advisor:
- Day - Time availability
Most of the community college courses are repeated weekly but they may be offered at different times on different days of the week. A student may also be available through the week at different times. In order to generate a viable academic plan, the proposed system must be able to choose among the courses whose schedule matches with the students availability.
- Financial restrictions
Usually, community colleges charge a per credit fee for every credit a student attempts, irrespective of the courses he/she wants to study. Based upon the estimated amount of money that can be spent by the student, advisor should pick the maximum number of courses or the shortest academic route that student should take, based upon other preferences.
- Minimum credit requirements and maximum credit constraint Certain amount of time and effort is expected to be put by a student for each credit of study that he/she takes up. This time and work is translated into man-hours or the work-hours that the student must put in-total, inside/outside a class. Irrespective of whether a student is a fulltime student of part-time student, he or she cannot exceed the maximum number of work-hours, as according to the labor laws. On the other hand, a student must take a certain number of minimum credits, in order to maintain his/her valid student status. Thus, the advisor is also required to populate the academic plan with the courses such that both, the maximum and the minimum credit requirements are taken care.
- Highest level course available
Depending on the academic year in which the student is studying along with the courses already covered by the student, advisors may choose courses of higher level and expedite a students graduation credit. This approach may also be used towards saving some financial liability for the student. For example, an advisor may allow a student studying in 2nd year to study a course of 300 level, skipping other courses in-between.
- Course prerequisite fulfillment
A student is eligible to take up a higher-level course after he/she has already studied the prerequisite lower-level courses for that course. Hence, the advisor is required to choose courses that are prerequisites to more number of higher-level courses.
- Course Clashes
If two or more courses have a clash of time at which they are scheduled but both courses are available at specific times in a year, then the academic advisor is required to address the concern of spreading the academic plan of the student in such a way that the student is able to study both the courses and without compromising upon other courses which hold either of these courses as pre-requisites.
These constraints have been modelled into a set of linear inequalities which work together to bound the search space of courses offered at a community college, organize these courses into academic plans and make recommendations. In the following section, we will have a look at the design overview, description of various components and salient features of the Virtual Student Advisor.
0.4 Architecture Overview
Automation in the fields of education and training has not been made approachable in common practices yet. A major factor which impedes this goal is towards establishing an artificially intelligent computation capability for such purposes is a challenging task. This research would facilitate a variety of colleges and the students with a tool which would enable them to realize their academic goals, securely.
The mathematical engine is designed as a monolithic procedure executed by a combination of Octave scripts in a sequential manner. These scripts form the mathematical logic to perform linear optimization over a search space of academic courses, related to each other by prerequisite/co-requisite relationship. Each script forms a single component of the mathematical engine and works as a filter which prunes out portions of the input course prerequisite network, if it doesn’t satisfy desired user-constraints. The reduced course network delivered by each mathematical script is fed as input to the next script in sequence.
The filtrate/reduced search space of prerequisite courses, generated from the filter scripts, is merely a list of courses and their details and it does not yield to a sequential academic plan. We use a special mathematical script, the “prerequisites multiPlans.m”, for generating logical sequence of courses to form an academic plan from the reduced search space. The “prerequisites multiPlans.m”script is responsible for traversing the search space and enlists the courses per each quarter for a student, such that, the prerequisites courses for each course are enlisted in suggested in the previous quarters, and the total number of courses suggested in a quarter fulfill the credit requirements for that quarter.
Figure 1: VSA System Overview illustrates the functional overview of the VSA framework, and its interaction with the student, and the advisor, the based on the various constraints. At the conceptual view, VSA works as a black box for both stakeholders, the advisor, and the students. Various constraints are fed by the student to the VSA recommendation engine, where it preprocesses the recommendations and manipulates the courses taken from the college databases to generate the suggestive academic plans. These plans are then reviewed by both, the advisors, and the student before being adopted by the student. If the recommendations are required to be changed, the recommendation engine is fed with the desired feedback.
0.4.1 Components
The proposed mathematical engine is comprised of total 10 distinct components, comprising of 9 functional components, knitted into 1 master process that runs every time the recommendation engine is invoked and runs these 9 components in the appropriate order. These components are principally responsible for handling distinct user and environmental constraints. Out of the 9 functional components, 5 components are the primary components which have been modeled as the mathematical linear-equations. The remaining 4 functional components provide auxiliary services to these 5 primary components. By and large the 9 components can be delineated as a separate module by itself as the following:
Skim module
Usually community colleges offer 1000 - 1500 courses under various degree curriculums and host around 25000 students. Traversing through such a vast search space of around 1500 courses every time while calculating academic plans for around 25000 students would tax heavily on the compute performance of the recommendation engine. Therefore, recommendation engine trims down the vast search space to the courses that are relevant to the target degree type and the target academic courses that are required to be transferred to the university.
These trimmed down versions of courses are of the form of relational networks which are primarily defined by the relation of desired course - to - set of prerequisite courses. The prerequisite networks so formed reduce the search space to around 1/15th times of the master search space. Skim module is responsible for trimming down the master search space and caching it for further use, the courses and their relationships are rarely altered.
Year Filter module
The year filter takes care of the Highest level course available constraint and is responsible for determining what is the highest level of course which can be legibly taken by the student pursuing his/her degree in any year.
The Year Filter module is one of the 5 primary components which is mathematically modelled as:
(1)
If the value of this linear-equation yields true, the high-level course under inspection is not legibly available for the student to study.
Schedule Matching module
The schedule matching module is responsible for determining if the courses intended are available on the days of availability of the student. This module covers days setting for the Day - Time availability constraint. Due to the complexity of matching the schedule of various courses with the dynamic availability schedule of the students, the Day - Time availability constraint has been divided into two sub-problems. The time mapping module follows immediately after this module and the same sequence must be maintained for achieving the desired results. The sequence of these modules shall be discussed in the final Procedure module.
Schedule Matching module is also a primary component and can be mathematically modelled as:
(2)
If the equation yields true, the days of tuition for the course under inspection are matching with the days of availability of the student.
Multiple-Pair Time Filter module
This module is responsible for handling the second half of the Day - Time availability constraint, which deals with mapping the time availability of the student with the schedules timings of eligible courses. Both, the availability of the students, and the course-conduct timings could be offered at different timings in the same week. This module maps all the corresponding times from each set-of available time-slots, defined by start-time/end-time pairs, and hence, called the Multiple-Pair Time Filter module.
The Multiple-Pair Time Filter module is also modelled mathematically into the following 3 equations:
(3)
(4)
(5)
The inspected course matches students availability if all the three equations yield true.
Course-Status Updation module
While generating the academic plans, courses are updated as taken or nottaken in the cached course pre-requisite network. This is useful for generating the course plans dynamically, per each quarter, and determining what effects would the selection of a set of courses will have on the curation of the rest of the academic plan. Thus, the recommendation engine can evaluate different permutations of courses within an academic plan and deliver the best ones as recommendations. This approach also benefits when the student is required to change the existing academic plan as a result in the altercation of his/her socioeconomic factors, leading to a change in the user-constraints. The Course-Status Updation module tries to maintain the consistency among the status of different courses (taken or not-taken) and the decisions implemented in the recommended academic plan.
Clash Detection - Plan Creation module
This module handles Course Clashes constraint and creates two set of plans if the recommendation engine encounters a clash between the timing of two courses. Each of the newly generated plans contains one of the clashed - courses, being devoid of the other clashed course and its dependencies. The Clash Detection Plan Creation module is also responsible for generating different permutations of courses to create different plans for a set of target courses. Clash detection is a primary component which can be modelled as the following:
(6)
If the above linear inequality holds true for corresponding days of Course A and Course B, then both, course A and course B can be taken in the same quarter.
Multi - Plan Prerequisites module
The Multi - Plan Prerequisites module is responsible for ensuring if the student has already covered all the pre-requisite courses for the course under inspection by the recommendation engine. If the dependencies for the intended course are not resolved by this module, the course is not added to the curated plan. This module is capable of checking for dependencies for a course in all the plans being created by the recommendation engine, parallelly; and hence, the name Multi Plan Prerequisites module.
This module is also a primary component which can be depicted mathematically as following: For 3 courses A, B, and C, if B and C are direct or indirect pre-requisites to A, assign them 3 coefficients such that these coefficients form the sides of a triangle. Hence,
(7)
If the linear inequality holds true, then only then, courses B, and C are the prerequisites to course A.
Quarter - Budget Distribution module
Once the recommendation module has created a draft-set of plans as the suggestion, the Quarter - Budget Distribution module takes into consideration the Financial restrictions and the Minimum credit requirements and maximum credit constraint to distribute the courses into different quarters and decide upon the length of the academic plans across different number of quarters for each plan. This module primarily works as an optimization function and provides the best possible academic plan according to the students budgetary constraints and the credit requirements laid down by the institutions policies.
Create Final Plans Structure module
This module is responsible for translating the plans into a labelled structure that can be written into a JSON translatable file-format and be readable to human inspection.
Procedure module
This is the entry module of VSAs mathematical recommendation engine, which invokes the other 9 components in the right order to generate recommendations. The order is as following: Skim module ? Year Filter module ? Schedule Matching module ? Multiple-Pair Time Filter module ? Course-Status Updation module ? Clash Detection - Plan Creation module ? Multi - Plan Prerequisites module ? Quarter - Budget Distribution module ? Create Final Plans Structure module ? Procedure module. The skimming module trims the search space by many folds before further preprocessing. Year filter also works on a similar concept and removes the non-eligible courses from the pre-requisite network itself.
For handling the day and time constraints, order of both, the Schedule Matching module, and the Multiple-Pair Time Filter module, is important. The schedule matching module checks if the days of availability of the courses and the student matches. Once, days are found to be matching, time-slots are matched from both sides, by using the days of the course as the index. Thus, if any of the time-slots for availability of the student matches with the courses time-slot for the day under inspection, it ensures that the student is available to attend the course lecture. Hence, the sequence of these two modules must check in the form - days first, time later.
The Course-Status Updation module is invoked before the Clash Detection - Plan Creation module whenever the recommendation engine repeats the procedure for any quarter. The Course-Status Updation module provides for an updated cache based upon the recommendations for the previous quarter, made by the Clash Detection - Plan Creation module.
The Clash Detection - Plan Creation
The Clash Detection - Plan Creation module generates the draft-set of plans by dissecting the course master pre-requisite network into different permutations. Each plan in the set-of-plans is a permutation of courses which could be inconsistent if the dependencies are not resolved for all these courses. Hence, the Multi - Plan Prerequisites module is invoked after the Clash Detection - Plan Creation module, to resolve the dependencies and remove any inconsistencies from the plans. The Quarter - Budget Distribution module, as discussed earlier, is an optimization function which adjusts the plans so generated, according to the budgetary restrictions of the student and the credits requirements of the institution.
In the following sections, we will discuss about the implementational details of these components, their input-output specifications, and their syntactical specifications.
0.5 Technologies Used
0.5.1 Linear Programming
The research problem is similar to general vehicle route optimization problems where combinatorial optimization and integer programming is utilized to minimize the total route cost, based upon various parameters. Our research problem involves three basic steps: creation of course prerequisite network, validation and verification of course prerequisites, and filteration/reduction of course prerequisite network based upon user-constraints.
Linear programming is a mathematical technique used in the field of operational research for maximizing or minimizing the yield of linear equations of several variables, such as cost. In our case, various user-constraints can be formulated in the form of linear equations to represent a cost function. For example, credits and credit hours can be set in a linear equation such that the student gains maximum credits by attending to the least number of credit hours. Another advantage which we gain by using linear programming is that various cost functions can reflect student-specific or course-specific trends, over a period of time. These trends can me further used to machine learn our research problem and provide better results in future research. These trends may also reveal societal progression and socioeconomic factors which can be used to better automate the whole problem.
0.5.2 Tools Used
The proposed recommendation engine for VSA uses 2 primary technologies, GNU Octave and JSON. GNU Octave is an open-source implementation of MATLAB, both being the programming languages intended for scientific computing. Using GNU octave provides two distinct advantages, first, being able to research and deploy the developed solution without the inhibition of license agreement; and second, that Octave is a light-weight interpreter-based language which can be easily implemented over different computing environments. JSON (JavaScript Object Notation) is also a light-weight data-interchange format which is easily readable and writeable by humans. This allows us to feed large sizes of standardized data to the recommendation engine easily.
0.5.3 Salient Features
VSA needs to be designed such that it can be secure, robust, scalable, and adaptable to any future changes made to the educational system. In the following subsections, we will consider the design overview, component descriptions, and salient features of the VSA recommendation engine. VSA mathematical recommendation engine has been curated to take care of the present needs of the educational system and compute capacity while keeping in consideration the need for catering future advancements and altercations. The proposed recommendation engine has been developed with the following salient features.
- Security
VSA handles sensitive and confidential data of students which can allow the onlooker to extract Personally Identifiable Information about the students. Such data may become of harmful use for the student and hence, stringent definition of rules and policies have been documented for VSA. These documents lay down various aspects, policies and procedures that must be followed by designers, developers, and operational-staff of the Virtual Student Advisor, to help maintain privacy and security of educational records.
- Robustness
Virtual Student Advisor is currently in a research & development phase, and hence, it will not be fair to assume that VSA is capable of handling any type of input or operational anomalies. These anomalies may emerge as VSA is further developed.
Although, VSAs mathematical recommendation engine is extremely robust because of being developed on the Octave platform, which is a interpreter based programming language for scientific computing. Being an interpreter based programming language allows octave scripts to carry on the function on the next command even if the previous command fails. The atomicity of these commands also allows an easy debugging and testing environment.
- Scalability
Because of being a scripted language, octave programs become easily extensible while maintaining their cohesiveness. A change in functional requirements can be easily fixed by modifying the scripts. The ease of modifiability also allows unrestricted customizability, while avoiding tight coupling of components.
Scalability can be achieved without facing implementational inertia. Running over an interpreter also renders the mathematical recommendation engine light-weight, avoiding the use of heavy libraries, virtual machines or compiling and linking infrastructure. This also makes the employability of the proposed recommendation engine smoother over different varieties of hardware and software configurations.
- Adaptability
Negligible coupling with the host system and almost no dependencies allow the proposed recommendation engine to be less tightly coupled and more cohesive. Thus, the VSAs mathematical recommendation engine can be deployed on heterogeneous system configurations by just installing the Octave interpreter.
- Intuitiveness
Since, curation of academic plans is not a one-time activity but rather a dynamic activity which time-and-again requires revision of various real-life constraints; therefore, VSAs recommendation engine cannot be made by a simple amalgamation of complex algorithms and data-structures. The proposed recommendation engine requires to implement intuitive intelligence to accommodate for plausible changes in the generated degree plans.
- Efficiency
The proposed recommendation engine takes the advantage of being based upon a light-weight interpreter which minimizes both, the memory footprints, and the computation load. Interpreter based design also allows for adopting the parallelized computation approach with less implementational restraints.
0.6 Implementation
The data structures and function specifications of the scripts created in GNU Octave are dissimilar to those of commonly used programming languages. GNU Octave allows for dynamic creation of heterogenous struct constructs, dynamic addition to the struct constructs, and on-the-fly change in the structure of struct constructs. Another advantage of using GNU Octave is that it allows multiple returns from a single function.
0.6.1 Construct Specifications: Common Data Structures
The proposed recommendation engine uses primarily 3 different types of data structures to realize this project:
- reqNetArray
It is the structure comprising of more than one level - 3 reqNet structures.
- reqNet
It is a structure of scalar quantities which are encapsulated within 3 layers. The first layer defines the label of the structure; the second layer comprises of all the course codes as the labels. Each course code further comprises of a heterogenous collection of vector and scalar quantities representing the following:
startTime: start time of the course lecture; endTime: end time of the course lecture; credits: number of credits that can be earnt from studying the course; preReqConst: coefficient assigned by the Multi - Plan Prerequisites module; days: days of the week on which the course lectures are scheduled to be held;
taken: flag to determine if the course has been taken or not; preReqs: array of course codes of the courses that are pre-requisite to this course; preReqs: array of course codes of the courses that are pre-requisite to this course;
Structure:
{
``ReqNet'': {
``CSS220'': {
``startTime'': 1500,
``endTime'': 1700,
``credits'': 5,
``preReqConst'': 100,
``days'': [
2,
4
],
``taken'': 0,
``preReqs'': [
``CSS182'',
``CSS161'',
``base''
]
},
``CSS182'': {
``startTime'': 2000,
``endTime'': 2200,
``credits'': 5,
``preReqConst'': 80,
``days'': [
1,
3
],
``taken'': 0,
``preReqs'': [
``CSS161''
]
}
}
}
- plans
It is a structure of scalar quantities which are encapsulated within 5 layers and represents the output of the proposed mathematical engine. The first layer defines the label of the structure - plans; the second layer comprises of all the suggested plan-numbers as the labels. Each plan number further comprises of a homogenous collection of quarter-numbers as the labels, and all the quarters further contain the array-type variable coursesSuggested representing the array of recommended course codes as strings.
Structure:
{
``plans'': {
``Plan-1'': {
``Quarter-1'': {
``coursesSuggested'': [
``CSS175'',
``CSS161'',
``CSS181''
]
},
``Quarter-2'': {
``coursesSuggested'': [
``CSS341''
]
},
``Quarter-3'': {
``coursesSuggested'': [
``CSS220''
]
}
},
``Plan-2'': {
``Quarter-1'': {
``coursesSuggested'': [
``CSS175'',
``CSS181''
]
},
.
.
.
}
}
}
}
In the following subsections, well discuss the algorithms for each module, input and output specifications for each module.
0.6.2 Skim module
Code Snippet
struct skim (targets,reqNet)
{
struct targetNet;
Assign targets $\rightarrow$ targetNet;
struct nextLayer;
Assign $prerequisites_{targets} \rightarrow prerequisites_{nextLayer}$;
while (!isempty(nextLayer))
{
if (target has prerequisites)
{
$Add nextLayer \rightarrow targetNet;$
Assign $prerequisites_{targets} \rightarrow prerequisites_{nextLayer};$
Assign $nextLayer \rightarrow targets;$
}
}
return targetNet;
}
Input and Output specification
Skim module takes 2 parameters as input - array of target course codes as strings, and reqNet. It also yields reqNet type struct as a return.
0.6.3 Year Filter module
Code Snippet
struct yearFilter (reqNet, year)
{
for Course in reqNet
{
if ($\abs{(year \times 100 - course code) < 100}$)
{
Remove Course from reqNet;
}
}
return reqNet;
}
Input and Output specification
Year Filter module takes 2 parameters as input - integer representing year of the students degree, and reqNet. It also yields reqNet type struct as a return.
0.6.4 Schedule Matching module
Code Snippet
struct scheduleMatching (reqNet, studentDays)
{
for (1 - 7)
{
if ($(\sum_{i=1}^{7} days_{course}^{i} - days_{student}^{i}) \geq 0$)
{
Remove Course from reqNet;
}
}
return reqNet;
}
Input and Output specification
Schedule Matching module takes 2 parameters as input - reqNet, and array of students available days as integers [1-7] . It also yields reqNet type struct as a return.
0.6.5 Multiple-Pair Time Filter module
Code Snippet
struct timeFilter_multiPair (reqNet, studentTimes)
{
for course in reqNet
{
$TF_1 = Course Time_start \geq Student Availability Time_start;$
$TF_2 = Course Time_stop \leq Student Availability Time_stop;$
$TF_3 = $
$Minimum Required Credit Hours \leq$
$\sum_{i=1}^{number of courses} (Class End Time_i - Class Start Time_i) \times days_i$
$\leq Maximum Credits Hours Allowed;$
if !($TF_1 \& TF_2 \& TF_3$)
{
Remove Course from reqNet;
}
}
return reqNet;
}
Input and Output specification
Multiple-Pair Time Filter module takes 2 parameters as input - reqNet, and array of students available times as pairs of integers [24 hour clock] . It also yields reqNet type struct as a return.
0.6.6 Course-Status Updation module
Code Snippet
struct courseStatusUpdation(reqNet)
{
for Course in reqNet
{
if ($Course \in QuarterPlan_{previous}$)
{
Update $Course_{taken} = true$;
}
}
return reqNet;
}
Input and Output specification
Course-Status Updation module takes only 1 parameter as input - reqNet, and yields reqNet type struct as a return.
0.6.7 Clash Detection - Plan Creation module
Code Snippet
struct clashDetection_planCreation (reqNet)
{
for course A in reqNet
{
for course B in reqNet
{
if !($A_{time} \times A_{day} - B_{time} \times B_{time} \geq Class_{time}$)
{
create plan A = reqNet;
remove course B from plan A;
create plan B = reqNet;
remove course A from plan B;
}
}
}
return plan A, plan B;
}
Input and Output specification
Clash Detection - Plan Creation module takes only 1 parameter as input reqNet, but yields 2 or more plans in a reqNetArray type struct as a return.
0.6.8 Multi - Plan Prerequisites module
Code Snippet
struct prerequisites_multiPlans (reqNetArray)
{
for reqNet in reqNetArray
{
for Course A, B, C in reqNet
{
if ($Coefficient_A \leq Coefficient_B + Coefficient_C$)
{
$B, C \in Prerequisite_A$;
if ($B, C \in Taken$)
{
$A \in Courses_{available}$;
}
else
{
Remove A;
}
}
}
}
return reqNetArray;
}
Input and Output specification
Multi - Plan Prerequisites module takes only 1 parameter as input - reqNetArray, and yields reqNetArray type struct as a return.
0.6.9 Quarter - Budget Distribution module
Code Snippet
struct quarter_budgetDistribution(reqNetArray)
{
for reqNet in reqNetArray
{
for Course A in reqNet
{
if !($Credits Limit_{Min} \leq Credits_A \leq Credits Limit_{Max} $)
{
$Shift A \rightarrow next quarter;$
}
}
for Course A in reqNet
{
if! ($cost_{Courses}$ > (budget $\pm$ 10% of budget))
{
$Shift A \rightarrow next quarter;$
}
}
}
return reqNetArray;
}
Input and Output specification
Quarter - Budget Distribution module takes only 1 parameter as input - reqNetArray, and yields reqNetArray type struct as a return.
0.7 Dataset
To test the scalability and reliability of virtual student advisor, we took sample of course prerequisite network for math courses, and generated mock up course prerequisite network containing upto “largestPossibleCourseNumber (lpcb)” courses. The math engine achieves this using the script, ”mockDataset.m”, which can generate random course numbers, assign them to random year and quarter schedules, and allocate different class timing for different days in each quarter. We can also randomly assign upto 10 courses as prerequisites for a course, where courses with higher course-number can only have courses with lower coursenumbers as the prerequisites.
The implementation details for the ”mockDataset.m” script are described in the following subsection.
0.7.1 Code Snippet: mockDataset
The mock up data generation script uses randList nElements(list), a custom function which takes a list as an input and generates a subset of the input list with its elements in random sequence. In the following code snippet, we pass an anonymous list of numbers, i.e. 1:lpcb, as input to the randList nElements function, to generate list of random course-numbers below lpcb. For each course in this list, we generate random list of quarters in which the course would be available. We feed the list 1:4 in the randList nElements function to generate the quarters list. Similarly, for each quarter, we generate a random list of number of days, among 7 days of week. Last, we generate random list of starttimes for each day of each course and add a two hour gap to generate the end time. Here, time is represented by an integer which is denoted by number of minutes modulus 1## 0. In other words, if the time is 1500 hours (3 pm), number of minutes past the start of the day would be 1380, and the integer value will be 1380 modulus 10, i.e. 138.
function [retval] = mockDataset(lpcb)
% lpcb = largestPossibleCourseNumber
Courses = sort(randList_nElements(1:lpcb));
for c = 1:length(Courses)
quarters = randList_nElements(1:4);
for q = 1:length(quarters)
days = randList_nElements(1:7);
for d = 1:length(days)
startTime = randList_nElements(42:138)(1);
% 7 am - 3 pm
endTime = startTime+12;
% 2 hours gap
arr = [startTime, endTime, days(d), quarters(q), year];
ReqNet.(courseName).CourseSchedule{length(ReqNet.(courseName).CourseSchedule)+1} = arr;
endfor
endfor
In the code snippet below, we choose upto 10 random courses from the sorted list of courses with course-number less than the course-number of the course for which details are being generated. These courses are assigned as the prerequisite courses.
allPrevCourses = Courses(1:c-1);
preqCourses = randList_nElements(allPrevCourses);
pcLimit = length(preqCourses);
if pcLimit > 10
pcLimit = unidrnd(10);
endif
for pc = 1:pcLimit
ReqNet.(courseName).preReqs{length(ReqNet.(courseName).preReqs)+1} = preqCourses(pc);
endfor
endfor
endfunction
The mock data generator requires an integer value, “largestPossibleCourseNumber (lpcb)” as the input parameter. As the name suggests, the lpcb denotes the largest possible course number that will be generated by the script. The sample data generated by the ”mockDataset.m” script is attached as the following:
{
{
"ReqNet": {
"1": {
"CourseSchedule": [
[86,98,7,3,1],
[61,73,5,3,1],
[71,83,1,3,1],
[82,94,2,3,1],
[73,85,5,4,1],
[49,61,2,4,1],
[64,76,3,2,1],
[62,74,2,2,1],
[48,60,7,2,1]
],
"credits": 2,
"taken": 0,
"preReqs": null
},
"2": {
"CourseSchedule": [
[76,88,4,1,1],
[54,66,3,1,1],
[48,60,6,1,1],
[83,95,1,1,1],
[70,82,5,1,1],
[43,55,2,1,1]
],
"credits": 2,
"taken": 0,
"preReqs": [
1
]
},
.
.
.
"1198": {
"CourseSchedule": [
[77,89,5,4,1],
[86,98,4,4,1],
[90,102,1,4,1],
[54,66,2,3,1],
[83,95,7,3,1],
.
.
[68,80,7,1,1],
[63,75,1,1,1],
[71,83,3,1,1],
[73,85,6,1,1]
],
"credits": 5,
"taken": 0,
"preReqs": [
1131,
1001,
88,
843,
142
]
},
"1200": {
"CourseSchedule": [
[49,61,1,2,1],
[71,83,5,2,1],
[63,75,2,2,1],
.
.
.
[64,76,5,3,1],
[55,67,1,3,1],
[55,67,3,3,1],
[70,82,7,3,1]
],
"credits": 5,
"taken": 0,
"preReqs": [
850,
559,
873,
189
]
}
}
}
0.8 Conclusion
0.8.1 Results
In this report, we presented the prototype for the project - Virtual Student Advisor which helps students to choose amongst the best possible academic routes to transition from community colleges into the university-based desired degree programs. The prototype mathematical recommendation engine not only takes into consideration the academic prerequisites such as the core courses or the number credits required, but also considers the qualitative and socioeconomic factors about the students such as the time of his/her class, whether he/she can pay for their courses chosen or the course load needs to be spread across a longer time duration, and generates academic plans for them.
0.8.2 Future Work
In future, the Virtual Student Advisor can be improved in the following dimensions:
- Machine-learning based VSA
Although, we may use the mathematical engine to provide initial predictions for courses, which can form some rigid academic plans, but it is required to machine-learn the virtual student adviser so that it can take human feedback and improve upon the results. Machine learning would also enable us to adapt to societal progression more dynamically.
- Trend Analysis
This project can be expanded to enable VSA engine to extract trends, extrapolate data-points from the extracted trends and provide an insight for the ways in which our society is driven by various socioeconomic factors.
- Data remodeling
We can focus towards generating a more realistic model of course prerequisite networks, to test VSA. Presently, we are generating the random course-numbers with random days and times but in reality, coursenumbers may be derived by using naming convention proprietary to an educational institute, and the course schedules may be dependent upon the the availability of professors or classrooms. A more precise remodeling of data may also project various trends pertaining to how courses are structured.
Further, the recommendation engine can be augmented with artificial intelligence to reflect upon the trends and choices over a large segment of society and infer more generalized patterns. Introduction to artificial intelligence would also bring the Virtual Student Advisor to a greater level of autonomy.