Corning Community College CSCS2320 Data Structures Assignments, Documents, Information, and Projects ======Projects====== * [[/haas/fall2016/data/projects/dsi0|dsi0]] (due 20160831) * [[/haas/fall2016/data/projects/sln0|sln0]] (due 20160907) * [[/haas/fall2016/data/projects/sln1|sln1]] [[[/haas/fall2016/data/projects/sln1/metrics|metrics]]] (due 20160907) * [[/haas/fall2016/data/projects/sll0|sll0]] [[[/haas/fall2016/data/projects/sll0/metrics|metrics]]] (due 20160914) * [[/haas/fall2016/data/projects/sll1|sll1]] [[[/haas/fall2016/data/projects/sll1/metrics|metrics]]] (due 20160921) * [[/haas/fall2016/data/projects/sll2|sll2]] [[[/haas/fall2016/data/projects/sll2/metrics|metrics]]] (due 20160928) * [[/haas/fall2016/data/projects/sll3|sll3]] [[[/haas/fall2016/data/projects/sll3/metrics|metrics]]] (due 20161007) * [[/haas/fall2016/data/projects/sll4|sll4]] [[[/haas/fall2016/data/projects/sll4/metrics|metrics]]] (due 20161007) * dka0 [[[/haas/fall2016/data/projects/dka0/metrics|metrics]]] (due 20161004) * [[/haas/fall2016/data/projects/dln0|dln0]] [[[/haas/fall2016/data/projects/dln0/metrics|metrics]]] (due 20161019) * [[/haas/fall2016/data/projects/dll0|dll0]] [[[/haas/fall2016/data/projects/dll0/metrics|metrics]]] (due 20161019) * [[/haas/fall2016/data/projects/dll1|dll1]] [[[/haas/fall2016/data/projects/dll1/metrics|metrics]]] (due 20161102) * [[/haas/fall2016/data/projects/dll2|dll2]] [[[/haas/fall2016/data/projects/dll2/metrics|metrics]]] (due 20161109) * [[/haas/fall2016/data/projects/dls0|dls0]] [[[/haas/fall2016/data/projects/dls0/metrics|metrics]]] (due 20161109) * [[/haas/fall2016/data/projects/dlq0|dlq0]] [[[/haas/fall2016/data/projects/dlq0/metrics|metrics]]] (due 20161116) * [[/haas/fall2016/data/projects/dlt0|dlt0]] [[[/haas/fall2016/data/projects/dlt0/metrics|metrics]]] (due 20161203) * EoCE (bottom of your journal) (due 20161216-105959) ======Class Stats====== * [[/haas/fall2016/data/projects/status|status]] ======Project FAQs====== * [[/haas/fall2016/data/projects/faq|faq]] ======Week 14====== * For those who want a copy of that solitaire thing we started in class that one day, I made a **grabit** project for it (called **solitaire**). * IPKA stats: * shortest time: 50 minutes * average time: 1 hour, 22 minutes * median time: 1 hour, 30 minutes * longest time: 1 hour, 45 minutes * number of people: 5 ======Week 13====== * Second to last week of classes ======Break 2====== * Break week! ======Week 12====== * **dlt0** begins our final project, exploring the venerable tree data structure. * The EoCE has been completed. They have been deployed to the bottom of your journal. ======Week 11====== * **dlq0** is the new project, focusing on queues, another popular and important data structure. ======Week 10====== * Transitioning beyond lists! We have one final list project (a skipping stone), and the first thing that lays beyond- stacks! * **dll2** is similar in nature to **sll3**, that is, adding in a "quantity", and overhauling display(). * **dls0** is our doubly-linked stack implementation, which is built a-top our linked list. ======Week 9====== * Because I deserve nice things, **dll1** will be extended another week. You're welcome. * I believe this is the last week to drop a class with a 'W'. If such thoughts are on your mind (not meant to refer to this class, just in general), you'll likely want to spring into action soon. * Registration for the Spring 2017 semester begins this week. ======Week 8====== * Can you believe it? We're beyond the halfway point. Week EIGHT! * **dll1** will be the next project in sequence, wrapping up our linked-list reimplementation. ======Break Week====== * Hopefully the break has served as a nice chance to relax, catch your breath, and get caught up on things. * I've seen increasing signs that somewhere amidst sll3/sll4 and dln0/dll0 a few more people are experiencing their big "a-ha!" moments. ======Week 7====== * Looking to have the **knowledge assessment** during our Tuesday class * Next round of projects **dln0** and **dll0** unveiled on Thursday * We commence on the next phase this week, with the addition of a second linking pointer to our venerable node-- a **back** pointer, allowing us to link to two nodes. With lists (doubly-linked lists), we now have the flexibility of moving both forward and backward, obsoleting the need for the setpos()/getpos() functions from the singly-linked projects. * This is also where having learned not to count in your algorithms will come in increasingly handy. You do not want to establish counts here; it wastes time, and adds an additional logic layer (and therefore complexity and chance of introducing errors). Those of you who couldn't shake this in the singly-linked projects have likely experienced some of the madness that causes. ======Week 6====== * I am thinking of having a **knowledge assessment** next week, probably on Tuesday (October 4th), where I Will have you implement some code in the same spirit as you've been doing on the singly-linked list projects. * The past few weeks we have been playing on a theme, one of singly-linked lists. A lot of important concepts for sure, but we've been pretty much in the same space. That starts to change with the next batch of projects, as we resume some of our abstract concept explorations. * We have two projects this week- **sll3** and **sll4**. * **sll3** is a small project adding some changes to our existing list implementation to make it better suited for **sll4** * **sll4** adds a new layer on top of things... now there are not only nodes, not only lists, but groups! What is a group? Merely a collection of lists. * Please, use meaningful variable names in your code. Seeing "a", "b", "c", and "d" interwoven is hard to follow at times. Starting with sll2, I'll be cracking down on poorly-named variables in your implementations. So be sure to use more meaningful names! * Also, I've noticed certain people holding on to the tendency of needing to count things where having a count (or merely navigating by number) is not necessary. Think of other ways to approach this, as soon you will not have getpos()/setpos() (and I'll crack down on any attempts to count where it is not needed!) ======Week 5====== * Another week, a little bit further down the rabbit hole we go; sll1 hopefully reinforced some patterns you've been encountering, similarish algorithms, and maybe even some more moments of enlightenment. * sll2 completes our core singly-linked list functionality, by having us look at the operations that manipulate and take nodes out of a list (where in previous sll# projects the general theme was putting nodes in and reading through what was already there). * obtain() function, to disconnect values(nodes) from the list * clearlist() function, to empty a populated list * rmlist(), to de-allocate an empty list * sortlist(), to sort a list's nodes according to a mode * swapnode(), to exchange the places of marked nodes in a list * I will say, historically, this project tends to be more difficult for the class. Maybe overconfidence? Likely people not drawing enough pictures. * drawing pictures has solved so many problems. I've seen a number of people stumped only to work through the problem (largely by themselves) once they draw out step-by-step what is happening or scribble out some pseudo-code as they desk check their process. It really does work, but only if you do it regularly. * the debugger will continue to be your friend (perhaps moreso). Remember, it is an aid, not an authority. You must make decisions based on what the debugger helps reveal to you. * Remember, if you had trouble implementing functions to a previous project, the **test reference implementation** is there to allow you to start on even footing in the next project. Learn to cut your losses and move on... the data structures freight train ain't slowing down (and we're not at 11 yet). * I've seen a couple more people wander in with questions... please, continue to do that! * Also, even though many of the tutors are not officially tutoring in data structures, many of them ARE tutoring in problem solving, or CPROG; and the bulk of problems are generally conceptual (ie not solving the problem effectively) and syntactical (not writing the code syntax properly). The non-Data Structures tutors are in no way obliged to tutor Data Structures, but if you go to them with problem solving/C coding questions, that is very much within their domain. ======Week 4====== * The next batch of list functions to be implemented come our way with sll1; basically, continued exposure to these concepts through code implementation. * make sure to be drawing pictures! I've been encountering people still just trying to get code working that they don't understand the concepts for. If I get the sense you're not understanding the concepts, I'll be asking you to draw pictures! ======Week 3====== * I trust you've been making progress on sln0 and sln1... not too much activity so far on the sln1 metrics page. I suspect that will change in the coming days. * I've had some good back-and-forths with a few of you on nodes, linking, syntax, and concepts... some great questions being asked. * The march forward continues! sln1 dealt with nodes, and now we move on to our next target: lists! **sll0** is our next project. * NOTE: while we will be covering it in class, please do NOT upgrade to sll0 UNTIL you have completed sln1. ======Week 2====== * We dive deeper into the rabbit hole. **sln0**-related activities continue to ramp up, as hopefully the finishing touches are put on **dsi0**. * remember, not only does your dsi0 program need to be correctly functional, its output needs to conform to project specifications. To aid you in this, the **projeval** tool has been made available. * **sln1** will be unveiled, allowing us to start applying our drawings to actual code. **sln1** will also begin the thread of core Data Structures projects. * sln1 introduces us to the node-specific operations we can perform, and will have us implementing the node library which will be a core component of the other Data Structures libraries we'll be building. There are 3 node operations: * **mknode** - create a new node * **cpnode** - duplicate a node * **rmnode** - destroy a node * sln0 and sln1 will be due next week, as sln0 deals with the concept side, and sln1 deals with the more tangible applied side (once upon a time they were one project, but I split it to facilitate project submission). * In case you weren't aware, on Friday (Aug 26), we had a hardware failure, resulting in Lab46 being reboot. So if you had any screen sessions running, they no longer exist. Hopefully that's the last issue for a while. ======Week 1====== * Welcome! I've wrapped all the initial activities into one project, **[[/haas/fall2016/data/projects/dsi0|dsi0]]**, that I'd like you to perform by the given deadline (by 11:59:59pm / 23:59:59). * Some fun first week stats: * across all my classes, there are 41 unique students (as of 08/27/2016 at any rate) * 1 of those 41 is taking 4 out of 5 classes I am teaching this semester * 6 of those 41 are taking 3 out of 5 classes I am teaching * 3 of those 6 are taking data structures * first initials of all in data structures: abcdjmpst * a - 2 * b - 1 * c - 2 * d - 4 * j - 2 * m - 4 (5 counting me) * p - 2 * s - 2 * t - 1 * of everyone in data structures this semester: * 16 (of 20) have taken/are taking UNIX with me (80%) * compared to 13 (of 16) in fall2015 (81%) * compared to 12 (of 15) in fall2014 (80%) * 17 (of 20) have taken CPROG with me (85%) * compared to 13 (of 16) in fall2015 (81%) * the person who attained the highest score in fall2015 data structures had not taken CPROG with me, nor had taken UNIX. * 100% of the people getting a C or lower in fall2015 data structures had taken both CPROG and UNIX with me. * compared to 11 (of 15) in fall2014 (73%) * of the top 4 grades in fall2014 data structures, 2 of the 4 had not taken CPROG with me, nor had taken UNIX; the other two had taken both CPROG and UNIX with me. * the top grade in fall2014 data structures had taken both CPROG and UNIX with me. * a super-procrastinator in fall2014 that otherwise would have gotten the #1 or #2 top grade, had taken neither CPROG nor UNIX from me. * so, in a purely correlative fashion, those who have not taken UNIX are at an advantage for getting a higher grade (I suspect they benefit from lack of preconceived expectations, and it enabled them to be consistently more mindful and aware). * also, in a purely correlative fashion, those who have not taken CPROG with me are not predisposed to getting a worse grade, but historical observation has shown that those individuals who hadn't taken CPROG with me that got good grades really had to work consistently and extra hard.