waitlist predictor on enrollment page#1110
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d78551a46f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const runEndTime = new Date(sorted[i].endTime).getTime(); | ||
| const runDays = (runEndTime - runStartTime) / MS_PER_DAY; | ||
| if (runDays >= WAITLIST_ZERO_CUTOFF_DAYS) { | ||
| return runStart - 1; |
There was a problem hiding this comment.
When the zero-waitlist run reaches the cutoff, this returns runStart - 1, which causes waitlistDecreasesAndDaysFromHistory to exclude the first waitlistedCount = 0 interval. That drops the final decrease into zero (for example, 5 -> 0) and the elapsed time up to that transition, so lambda is systematically underestimated for sections that clear their waitlist and the returned probability is biased low.
Useful? React with 👍 / 👎.
| }); | ||
| } | ||
|
|
||
| let lambdaUsed: number | undefined = lambda ?? undefined; |
There was a problem hiding this comment.
The resolver checks k and timeRemainingDays but never rejects negative lambda. If a caller sends lambda < 0, lambdaT becomes negative and poissonCdf returns 0, so the API reports a 100% get-in probability for invalid input instead of returning BAD_USER_INPUT, which produces incorrect results for direct API consumers.
Useful? React with 👍 / 👎.
vaclisinc
left a comment
vaclisinc
left a comment
There was a problem hiding this comment.
maybe we need to disable summer session:
|
@vaclisinc Because summer session enrollment is historically much different, should I completely remove the feature for it, or separate my data to only past summer sessions? although most classes wouldn't have much data. |
I think it's fair we just support spring and fall semester. The summer sessions data probably is lesser and not stable (not sure but I guess every summer sessions may have rly different courses based on professors?) |
vaclisinc
left a comment
vaclisinc
left a comment
There was a problem hiding this comment.
And also another UX aspect questions, once people add more than one class to the enrollment page, then how do the system know whether the user is inputing which course?
I think two solutions:
-
one is showing the course name and courseID on the top - quick solution for now?
-
maybe changing the arrangement (since we will probably make this into the waitlist volatility meter you mentioned before, and I lowk think this is maybe better than a number of probability at this moment - however, the volatility meter will be even bigger height and rn it's already not fitting in the 100% screen size) - maybe discuss with design team, I'll tag them later
2 participants
experimental feature, please test out and give feedback on UI + the overall feature. thinking about maybe pivoting to a less intrusive UI where it can show each course's difficulty to get into (sort by calculated lambda)
uses poisson-based regression from past 3 semesters for data.
future inclusions might include:
only showing the calculator if the semester is the current semester
only showing the calculator if it is during course enrollment season
also, it might be possible to create this feature with less files(?) or neater(?), so i can clean the code up if you find a better way to do so.