class size update
Not too much new here, but the winter quarter is new:
Here’s the college as a whole (we’re better):
Not too much new here, but the winter quarter is new:
Here’s the college as a whole (we’re better):
Okay, check these out:
Some good news, here.
On my way home from SIGCSE, I drew some more pictures.
This shows how each year of incoming students handles 357. Specifically, the x axis shows quarters since the students’ first one, and the y axis shows what fraction of the students have passed 357. Each line shows a different cohort.
Some of the lines are longer than others. This is because some cohorts that take a really long time to pass 357, and also because some cohorts haven’t yet had more than 6 or 9 or 12 quarters since entry.
There’s some sobering news here—since 2005, we’ve never managed to heave more than 75% of the students over the 357 bar.
However, looking more closely, we see that more recent cohorts—specifically, those since 2010 (a.k.a. “when we started 123”) look a lot better.
As part of our work on our recent SIGCSE paper (citation forthcoming), I took another look at our numbers of incoming students. The results surprised me. This table combines CSC, CPE, and SE students, and associates them with the quarter in which they first took a lower-level CS class.
The surprising thing about this—to me, anyway—is that our enrollments have actually been dropping over the past few years. I’m surprised.
People often ask me what the heck is going on with Cal Poly’s nutty quarter numbering system. I’m going to try to summarize it.
Before I begin, I think I’m probably suffering from Stockholm syndrome, here; I’m kind of fond of it, even though it’s non-intuitive.
Based on a very brief conversation with Debbie Dudley, it appears that the current system was designed in 2006, during the migration to PeopleSoft. At that time, Cal Poly had to devise a system for numbering quarters both in the future and in the past (that is, the new system also had to represent existing records of past students).
The rest of this is still largely hypothetical; please feel free to write and correct me about anything I’ve gotten wrong; I think that trying to understand how the system arose helps me (and you?) to understand its quirks a bit better.
Problem: we need a way to represent a particular quarter (e.g.: Fall 2006) as a number. It would be really convenient to be able to sort in a sane way, etc. etc.
Solution: well, let’s use integers, not floats (for what are hopefully obvious reasons). Let’s use the year, then a digit for the quarter. What digits should we use for the quarters? Well, we should probably stay away from zero, because it’s not clear what year a zero would belong to. Okay, let’s use 2, 4, 6, and 8 for the four quarters. This spaces out the four quarters, and allows for the insertion of additional terms, should it become necessary.
So, how should we write Fall 2006? We could write “20068”. But… let’s try to cut that down to four digits.
(Knowing what I now know, I can’t see why you would want to do this unless PeopleSoft has some kind of internal restriction or performance penalty regarding numbers with more digits. Let’s assume this is the case.)
Well, maybe we can encode the century as a single digit. Let’s use “2” for the century from 2000 — 2099. So Fall 2006 becomes 2068.
Great! So how do we represent Spring 1997?
If we’re using century codes, then the one before “2” should be “1”. So in this case, Winter 1997 would be written as 1972.
Apparently, though, we decided that this was confusing, and that we should instead use a “0” for the 1900s, so that Winter 1997 is instead written as 0972.
This scheme is not awful, but it does have some problems if you try to subtract numbers or increment or decrement quarter numbers, because going from a fall quarter to the next winter quarter requires adding four… unless the year is 1999, in which case you have to add 1004. Oh well.
Okay, so let’s summarize. How the heck do we actually read one of these numbers?
2174 : 2000 + 17 = 2017, 4 = Spring. Spring 2017.
2102 : 2000 + 10 = 2010, 2 = Winter. Winter 2010.
976 : 1900 + 97 = 1997, 6 = Summer. Summer 1997.
Actually, I’m going to be precise, and just give you some code.
Yes, in Racket.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
#lang typed/racket ;; given a quarter, return its season: "Fall", "Winter", etc. (define (qtr->season [qtr : Natural]) : Season (match (modulo qtr 10) [2 "Winter"] [4 "Spring"] [6 "Summer"] [8 "Fall"])) ;; return the year in which a quarter number falls (define (qtr->year [qtr : Natural]) : Natural (define century-code (floor (/ qtr 1000))) (define year-code (modulo (floor (/ qtr 10)) 100)) (define century-offset (match century-code [0 1900] [2 2000] [_ (raise-argument-error 'qtr-year "qtr with century code of 0 or 2" 0 qtr)])) (+ century-offset year-code)) |
Good news, folks! We’re continuing to deliver reasonably sized classes for our students. Specifically, more than 90% of our SCUs are currently delivered in classes of size less than 40. The last time we managed that was back in winter of 2011. On the other hand, if you think that class sizes should be below 30, we’re not doing so well.
Here’s the college as a whole (we’re better):
I’ve updated the dependency chart to match the 2017–2019 catalog.
This now includes DATA classes as well as CPE and CSC classes.
Some data: how long is it taking our students to graduate? How is that changing over time?
It looks like CSC and CPE are improving. It looks like CPE students are having trouble getting out in 4 years. On the other hand, the 5-year graduation rate for CPE majors is steadily rising.
It looks like lots of students graduate in four years and one quarter.
It looks like very few students graduate in their sixth year; that may be because there’s nobody left; this graph doesn’t distinguish between those who haven’t yet graduated, and those who are discontinued or disqualified. However, given the very small numbers for six years, it seems reasonable to assume that most of those that haven’t finished after six years already gave up, possibly years earlier.
Note that for students admitted in 2012, none of them are shown as having graduated in 4 years plus 2 quarters or more… because it hasn’t yet been that long since they were admitted. By the same token, we don’t see six-year numbers for 2011 admits, etc.
Also, all of this data uses “adjusted cohorts”. That is, those that change majors out of the program are removed from the denominator and the numerator, and those changing majors into the program are added to the denominator and the numerator.
(EDIT: images updated with 2174 data.)
Here’s a picture of (lecture, non-supervisory) sections taught by CSSE faculty since Fall 2008:
Because the number of sections taught has gone up rather dramatically, here’s the same data, normalized by sections per year, to show the fraction of classes taught in each category:
There are many caveats and things to explain about these pictures.
Following Zoe’s excellent suggestion, I added color to the course dependency chart:
The arrows should be the same as the previous chart, though you’ll notice that because of the way I generated it, the chart now includes the classes that don’t have any edges connected to them.
The colors relate to the number of students that have enrolled in each class. Specifically, the log of the number of students that have taken the class from fall 2010 through spring 2016. Classes with zero enrollment are given log(0.5). The class with the highest value is red, the one with the lowest value is green. Yes, there should be a legend. Classes that aren’t in the Computer Science catalog are gray.
Note that I have no idea how many of these enrolls are repeats. That would be interesting, but I’ll need a different data source to answer that question.
The numbers for each class are interesting, and I think I’ll just publish them separately.