Corning Community College CSCS2320 Data Structures Assignments, Documents, Information, and Projects ======Projects====== | [[/haas/fall2017/data/projects/dsi0|dsi0]] (20170826) | | [[/haas/fall2017/common/projects/wcp|wcp1]] (20170826) | | [[/haas/fall2017/data/projects/ael0|ael0]] [[[/haas/fall2017/data/projects/ael0/faq|faq]]] (20170830) | | [[/haas/fall2017/common/projects/wcp|wcp2]] (20170902) | | [[/haas/fall2017/data/projects/sln0|sln0]] [[[/haas/fall2017/data/projects/sln0/faq|faq]]] (20170906) | | [[/haas/fall2017/common/projects/wcp|wcp3]] (20170909) | | [[/haas/fall2017/data/projects/sln1|sln1]] [[[/haas/fall2017/data/projects/sln1/faq|faq]]] [[[/haas/fall2017/data/projects/sln1/metrics|metrics]]] (20170913) | | [[/haas/fall2017/common/projects/wcp|wcp4]] (20170916) | | [[/haas/fall2017/data/projects/sll0|sll0]] [[[/haas/fall2017/data/projects/sll0/faq|faq]]] [[[/haas/fall2017/data/projects/sll0/metrics|metrics]]] (20170920) | | [[/haas/fall2017/common/projects/wcp|wcp5]] (20170923) | | [[/haas/fall2017/data/projects/sll1|sll1]] [[[/haas/fall2017/data/projects/sll1/faq|faq]]] [[[/haas/fall2017/data/projects/sll1/metrics|metrics]]] (20170927) | | [[/haas/fall2017/common/projects/wcp|wcp6]] (20170930) | | [[/haas/fall2017/data/projects/sll2|sll2]] [[[/haas/fall2017/data/projects/sll2/faq|faq]]] [[[/haas/fall2017/data/projects/sll2/metrics|metrics]]] (20171004) | | [[/haas/fall2017/common/projects/wcp|wcp7]] (20171007) | | [[/haas/fall2017/data/projects/sll3|sll3]] [[[/haas/fall2017/data/projects/sll3/faq|faq]]] [[[/haas/fall2017/data/projects/sll3/metrics|metrics]]] (20171018) | | [[/haas/fall2017/data/projects/sll4|sll4]] [[[/haas/fall2017/data/projects/sll4/faq|faq]]] [[[/haas/fall2017/data/projects/sll4/metrics|metrics]]] (20171018) | | [[/haas/fall2017/common/projects/wcp|wcp8]] (20171021) | | [[/haas/fall2017/data/projects/dln0|dln0]] [[[/haas/fall2017/data/projects/dln0/faq|faq]]] [[[/haas/fall2017/data/projects/dln0/metrics|metrics]]] (20171025) | | [[/haas/fall2017/data/projects/dll0|dll0]] [[[/haas/fall2017/data/projects/dll0/faq|faq]]] [[[/haas/fall2017/data/projects/dll0/metrics|metrics]]] (20171025) | | [[/haas/fall2017/common/projects/wcp|wcp9]] (20171028) | | [[/haas/fall2017/data/projects/dll1|dll1]] [[[/haas/fall2017/data/projects/dll1/faq|faq]]] [[[/haas/fall2017/data/projects/dll1/metrics|metrics]]] (20171101) | | [[/haas/fall2017/common/projects/wcp|wcpA]] (20171104) | | [[/haas/fall2017/data/projects/dll2|dll2]] [[[/haas/fall2017/data/projects/dll2/faq|faq]]] [[[/haas/fall2017/data/projects/dll2/metrics|metrics]]] (20171108) | | [[/haas/fall2017/data/projects/dls0|dls0]] [[[/haas/fall2017/data/projects/dls0/faq|faq]]] [[[/haas/fall2017/data/projects/dls0/metrics|metrics]]] (20171108) | | [[/haas/fall2017/common/projects/wcp|wcpB]] (20171111) | | [[/haas/fall2017/data/projects/dlq0|dlq0]] [[[/haas/fall2017/data/projects/dlq0/faq|faq]]] [[[/haas/fall2017/data/projects/dlq0/metrics|metrics]]] (20171115) | | [[/haas/fall2017/common/projects/wcp|wcpC]] (20171118) | | @lightgreen:[[/haas/fall2017/data/projects/dlt0|dlt0]] [[[/haas/fall2017/data/projects/dlt0/faq|faq]]] [[[/haas/fall2017/data/projects/dlt0/metrics|metrics]]] (20171129) | ======Class Stats====== * [[/haas/fall2017/data/projects/status|status]] ======Week 12====== * We cap off our data structures explorations this semester with trees, and the dlt0 project. * We'll also be unveiling the EoCE. All celebrate and cheer! ======Week 11====== * Now we're onto queues, another important data structure ======Week 10====== * And now we start to pick up the pace a bit, with dll2 and dls0, our first foray into additional data structures ======Week 9====== * We continue our list implementation with dll1. ======Week 8====== * We are now halfway through the semester. Look at how far we've come! * We will now embark on our first great re-implementation of our nodes and lists, with the addition of another pointer in our node: **fro** * this means each node points to TWO other nodes, the familiar one that comes after (our "to" pointer), and now, one that comes before (our "fro" pointer). * there are some additional features and functionality introduced as well, in the **dln0** and **dll0** projects, kicking our great re-implementation. ======Break 1====== * The week 7 journal entry will be your bonus break week entry. You'll have until Thursday of break week to modify it, at which point I'll roll it to week 8 (which will be a normal weekly entry- our journal entries will now sync up with the week!). If you don't touch week 7 it won't harm you, it will only help you if you contribute any content. * With 7 data points now available, I have populated the class stats page. ======Week 7====== * We're nearing the completion of our singly-linked list endeavors. A lot of details to track and ideas to encapsulate into working code. * I've had some good questions, and discussion in the class chat and e-mail. Still perhaps not as much as I'd prefer. Remember: this won't become any easier unless you immerse yourself in it. * Knowledge assessment in class on Thursday. ======Week 6====== * I'd like to have a knowledge assessment next week, ideally on Thursday. A chance for you to demonstrate your understanding of important Data Structures concepts (nodes, lists) * sll2 is our next project, completing our basic list implementation. * Important things about the linked list implementation: * running mknode() or malloc() and then immediately re-assigning the pointer is **bad**; we call that an intentional memory leak. Don't do it. * error checking is important. Just because malloc() always tends to work, doesn't mean that it will ALWAYS work. * don't rely on fixed counts or positions. Just because we have getpos()/setpos() doesn't mean you should use them to obtain numeric values to evaluate everything upon. * did you know, that checking for equality with myList -> engine lets you verify the start of the list? Don't waste a call on getpos() and compare against 0. That shows me you're still overthinking in brute-force and micro-management mode. We won't always have getpos()/setpos(), so don't use them as a crutch! * Commenting with why/how comments is central and critical! Just because the person you copied from feels above commenting doesn't help your case any more. In fact I may double down even more. * This is also a general plea to understand what you are doing. I see far too much "overhelping" going on, where the solutions are near identical, save for some pointless change (like declaring a useless variable to try and make it seem different). I KNOW who is collaborating, I KNOW who knows what is going on and who doesn't. Your work needs to be your own, you NEED to understand what it is you are doing. Comments are one way of demonstrating to me that you do. Leaving them out is a cop-out and an intentional attempt at misleading me. * **insert()** was probably THE MOST IMPORTANT function from sll0. For those who "just didn't get to it" or "ran out of time", congratulations you avoided the conceptual centrepiece of the whole project. Again, it is a "win the battle but lose the war" type of thing. You NEED to understand things like **insert()**, they will be the concepts coming up again and again with ever-mounting importance. * avoid using -> to -> to in your logic... you are limiting your code's flexibility. You should not need to delve any deeper than a single "to" pointer, and your conditions should generally try to avoid excessive comparisons of the "to" pointer to NULL (not that there aren't valid cases, but generally I see a lot more less optimal approaches, hence why I am pointing it out). * As is increasingly becoming the case, the true abstract nature of data structures is starting to throw some people for a loop. That is the hidden edge that data possesses, unlike discrete, where we generally focus more on exploring new methods of thinking- in data our playground is conceptual and abstract thought. Just getting compilable syntax will not really do you any favors in the long run. * With all this said, there are those who are grokking or doing quite well. Mistakes may be made, but realizations being had, and actual learning taking place. ======Week 5====== * The abstract nature of the class is starting to ramp up, I've already noticed far too many people who are still trying to brute force things. Just like trying to write a program avoiding loops because you never learned them: you're going to run into scalability issues before too long. * The focus needs to be on the concept. The code should then fall in line rather easily. What is it that you are focusing on? A node? A list? Be sure not to be unclear on such intentions. * We continue our singly linked list implementation, with the next round of functions to implement in **sll1** * Some observations from evaluating sln1: * be mindful of the perspective; for instance, the node library functions ONLY care about individual nodes, and are completely unaware of any overarching structures they may be in (such as lists). Nodes JUST do node-y things. * same with lists: we may eventually built on top of lists, and lists are made of nodes, but lists themselves need to only care about doing list-y things. Call the node functions to handle specific node operations, call list functions to handle list operations. Don't worry about if we're just a list, or a stack, or any other arrangement of linked nodes. * error checking! So many of you need to become more cognizant of verifying that your allocation of resources was successful. Don't just malloc() and go. CHECK to see if the result is NULL and proceed appropriately. I've been cutting some slack (depending on other demonstrations of awareness) since we're just starting, but soon that too will become a vicious detractor of points. Just like consistent indentation and good how/why comments, do proper error checking! * Unless the function is specifically meant to do I/O (ie the **displayf()/displayb()** functions), there should be ZERO I/O in any of these functions. Do NOT print out error messages, just return the NULL (or whatever the error case is) you are supposed to. * These are good foundational habits I'm trying to instill should you find yourself working on or with libraries, more complex code-bases, standards/specifications-compliance, etc. All part of evolving from that programmer who thought one for() loop and 20 lines of code was a big thing, we need to go much further than that. ======Week 4====== * I am pleased: more and more people seem to be getting an early start. They are also tending to ask questions! These are both excellent signs. * We'll be introducing **sll0** this week, although some have already commenced on that; **sll1** will be the project after that, continuing our list implementation. * Lists are like a conceptual layer that sit atop nodes. They don't actually encapsulate nodes, but conceptually utilize nodes to create a new means of accessing data. We've been playing with the concept of lists in various projects so far this semester (ael0 and sln0), but with sll0 we actually start implementing our list library. In many ways, it is doing exactly what the node library is doing, only it is operating on the level of a list. * a big piece here is recognizing what functionality already exists and to readily utilize it. Reinventing the wheel will both get you into trouble (added complexity, redundancy) and it generally demonstrates the individual doesn't understand or see the bigger picture, which is absolutely critical to see. ======Week 3====== * Some metrics: * of the 21 people currently in the class: * 9/21 (~42%) had C/C++ with Hans * 8/21 (~38%) had C/C++ with me * 4/21 (~19%) had C/C++ with Joe * of the 15 submissions I received for ael0: * 14 were in C (compilable with gcc), that's 93% of submissions * 1 was in C++ (needed to be compiled using g++) * the reason I point this out? I've been saying the bulk of your C++ experience has really just been as a "lazy C". As 93% of submissions goes (with 42% of the class having had Hans and "ONLY" C++), it seems there was relatively little trouble adjusting. Are there differences? Sure. But not "entirely different language" differences. * of the 6 non-submissions for ael0: * 16% had Hans * 33% had me * 50% had neither Hans nor me. * but I would be the first to point out that "correlation is not causation". Some individuals have more time between taking C/C++ and now; then you have the various degrees of retention- no two people got the same thing out of their initial programming experience. Some actively kept practicing, where others let dust collect. While some may want to draw some conclusive connection for that 50%, from what I have observed, it is entirely up to the individual, and what effort they personally put in (or, more aptly, did not) to be at their current stage of comprehension. Now, some environments may have made it easier to get away with no putting in one's fair share of effort... but still, the onus is still on the individual taking the class to get something out of it. * The **sln0** project is due this week. Again, perhaps something of a deception, in that the project is syntactically easier than **ael0** (not necessarily conceptually easier, however). That's only to help acclimate you to the important concepts that later projects (like our next one, **sln1**) will be expecting you to understand and build upon. * So, how's it going? We've just experienced the review and conceptual intro project, **ael0**. * In an ideal world, review would have meant dusting off some less explored corners, and resuming the strengthening of existing conceptual understanding. * Instead, I got the impression that, for far too many (certainly NOT everyone- I also witnessed those glorious individuals who got a lot out of the project, and those who just tore through it like it was nothing), **ael0** was a challenge due to a number of factors: * lack of programming experience (ie not touching programming since your last programming project was due, which meant not touching programming at all over the summer) * lack of playing and experimenting. Programming is about expressing your ideas, but the less you work on means of expression, the less fluent you are, meaning the more rigid and limited you are in creating solutions (especially ones that are not largely prescribed that you are doing little more than memorizing and regurgitating). You MUST (and regularly) play and experiment. Write small programs that test something so you are more familiar with how the language will react. Not as familiar with do-while loops? Take an existing program and convert it to using them, etc. * lack of proper time management discipline. I suspect some waited until the last minute to really start (thinking "why not? This is how I completed ALL my other projects in the previous class"), and have realized that we're no longer doing the basics, we're now adding content on a layer above (requiring a solid foundation in) the basics. Some took advantage of the time they had, and prospered (and will reap the benefits). Others, I hope it serves as an opportunity to start on improvements to your approach to class work. * lack of conceptual understanding. Some haven't seemed to retain some fundamental basics from the introductory programming experience, be it: * unfamiliarity/clumsiness with loops * maybe trying to shoehorn their one familiar loop into less optimal situations * brute forcing an infinite loop then (quite unelegantly, and in violation of structured programming form) unceremoniously break the loop when some exit condition is met. * unfamiliarity/clumsiness with selection statements * things like the = vs. == in conditions, or stray semi-colons following an if(). * demonstrable inability to express the choices effectively to the computer (both in concept and in syntax) * unfamiliarity/clumsiness with flow of logic * if something is lacking a terminating newline, and upon suggesting "it is missing a newline", one adds it BEFORE, leaving the person confused why it didn't solve the problem * trying to use the excuse that "never having done a menu before" is somehow valid reason for getting a pass. There's nothing special about a menu-- merely a selection structure within a looping structure. * unfamiliarity/clumsiness with functions * not understanding what the return type is for, nor how to pass parameters * the difference between prototyping/declaring a function, calling a function, and defining a function * again, this was a review of old/intro to new type of project, and far too many were experiencing far more significant issues in its implementation. Makes me worry a little bit about what's to come. * If you found resonance with some of the above-mentioned inadequacies, I'd strongly urge you to shape up your act. The programming is not going to get any less intense, the concepts and abstraction is only going to increase (I am expecting the challenge to be in encountering the concepts- they are what are truly new. You should be challenged by that, not how to terminate lines with semi-colons). I AM teaching C/C++ Programming this semester... so if for whatever reason you feel you don't have the requisite understanding of the basics, please DO consider retaking it, or even sitting in on it. It is not yet too late (however, thinking you can just push through with your usual brute forcing tactics, by the time you realize the errors of your ways, it WILL be too late). * Computing is not easy. We have to think about thinking. So many others in the world primarily focus on just following directions and NOT critically thinking. We are the people that come up with the directions. Granted, computers are our prime audience, but the deeper you go down this rabbit hole, the more you see the patterns and concepts of computing popping up EVERYWHERE. * I'll also be watching: * for those who were demonstrating on-going and acute unfamiliarity/clumsiness with various programming tasks, were lagging, were into the late window for **ael0** and then somehow, magically, submit a fully-working project. That's not viable. Not impossible, but just remember the part about doing your own work, and not relying on others who may just think they're helping (because they're not, your challenges remain, only the wall is taller now with the next project). Struggling and submitting an imperfect/incomplete project late? That makes a lot more sense. It is reasonable, and it demonstrates honesty (both personally and academically). This obsession with exactness is a habit many simply have to break. Getting 100% at all costs (including not truly by your own brain and hands) will not yield success in the long term. I'm not saying I'm going to drop the hammer on anyone this time around... let's just say it'll establish some data points allowing me to watch certain individuals even closer (and if one is struggling, who wants to be scrutinized even more closely to ensure they are doing their own work?). See how a perceived "good" short term decision can actually be far less good in the long term? * for those who weren't asking me questions, perhaps trying to escape my discovery of any confusion you were experiencing... that also shows in results. Late, quiet, but perfect? Again... data points and longer-term trends. Not saying a capable person couldn't have just suffered from a bout of undisciplined procrastination... but again, give me time and data points, and I'll be able to ascertain that and distinguish those people as well. * Basically: doing your own work, and accomplishing the task on your own, even if incompletely or imperfectly, is FAR better than struggling and eventually getting "too much" help from others. And some may not even know they are doing it- they'll struggle with something, ask for help. The helpers will give a conceptual pointer on a thing to use. Person will stumble around trying to do it, butchering the syntax left and right. Later, helpers (myself included), will see just how butchered and terrible it is, and neglect to see the whole picture, unknowingly correcting the person's code (even if only to make it compile cleanly). That person has just now received too much help. They didn't accomplish it on their own. They benefit from others just wanting to help. But come the next time, that deficiency will still be present. * As I said, I myself am guilty of this. I was helping some people this past week who were clearly struggling on basic concepts or syntax (or both). I'd suggest some breadcrumbs to follow, and upon being called to offer further help later on, witness the lack of understanding, but fall into the trap of thinking I'm just helping get the code compiled- but the act of doing that bypasses the fundamental issue the individual is experiencing: that they don't understand. The next obstacle just gets that much more insurmountable for them. So, just be vigilant. Even helping with fixing compiler errors, if the person is clueless to what is wrong (there's a difference between not knowing why it isn't working, to wondering why what they're doing is conflicting with the compiler- although being able to make that distinction comes with experience), we should give them breadcrumbs there too- the focus should be on teaching how to read and understand compiler messages, and NOT on "saving the day" by fixing what appears immediately wrong. * Again, we have to weigh issues of context as well. Being that set of eyes pointing out the errant semi-colon affixed to an if() is invaluable, welcome, and sanctioned help. Or one equal sign where we meant two (or vice versa). That is very different from "helping" someone declare a variable to type int, or writing a switch-case, or calling a function. * This is where writing out the ideas on paper, in pseudocode or pictures, can help. If the person understands the idea, we can debug and reason through the idea. Once they become better acclimated to the specifics of the concept, they can then set to coding it. * That leads me to another important piece: if you're not sure how you'd do something, starting off coding is NOT the way to go. If you cannot do it by hand, you have no business trying to code it yet. Work it out on paper first, THEN code it. You'll fight yourself less that way. ======Week 2====== * ael0 project comes due this week, I've seen on-going activity related to development on this project. Good. * The next project will be introduced: **sln0** * The project after that (for those working ahead) will also become available: **sln1**, although we won't formally introduce it until next week. * The plan is to continue to talk about pointers, then structs, then start exploring creating "nodes" for use in our non-array-based "lists". ======Week 1====== * Welcome! * Went over the syllabus, formally introduced **ael0** project. * Started reviewing C by talking about pointers. * we wrote some sample code * pointers are a fixed size, regardless of data type * why? MEMORY ADDRESSING * on lab46 (running on a 64-bit OS/system), memory addresses are 64-bits (64/8 = 8 bytes) * so all pointers (whether char, int, float, etc.) will be 8 bytes in size on this system. * on other systems, notably 16-bit and 32-bit systems (especially late-era hardware that might have incorporated tweaks to support more memory than is typically accessible by the default machine word size), memory address sizes can vary. * takeaway: for code portability, do not assume 8 byte memory addresses. **ALWAYS** use **sizeof()** to maximize portability. ======Week 0====== * Attempting to provide an opportunity to get started BEFORE the semester officially kicks off. If you are interested in keeping your programming skills sharp and current, consider starting work on one of the first projects now, in order to have it done to rack up lots of bonus points once the submission window opens!