This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2018:data:projects [2017/11/27 18:23] – external edit 127.0.0.1 | haas:fall2018:data:projects [2018/11/12 16:57] (current) – [Week 7] wedge | ||
---|---|---|---|
Line 7: | Line 7: | ||
======Projects====== | ======Projects====== | ||
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | [[/haas/fall2018/ |
- | | [[/haas/fall2017/ | + | | |
- | | [[/haas/fall2017/ | + | | |
- | | | + | | [[/haas/fall2018/ |
+ | | EoCE (20181213-172959) | | ||
======Class Stats====== | ======Class Stats====== | ||
- | * [[/haas/fall2017/ | + | * [[/haas/fall2018/ |
======Week 12====== | ======Week 12====== | ||
- | * We cap off our data structures explorations this semester with trees, and the dlt0 project. | + | * EoCE, located |
- | * 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 | + | |
- | * this means each node points to TWO other nodes, the familiar one that comes after (our " | + | |
- | * 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====== | ======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. | + | * Layers. Wrapping up initial |
- | * 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====== | ======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) | + | * Continuing down the linked list rabbit hole |
- | * 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' | + | |
- | * don't rely on fixed counts or positions. Just because we have getpos()/ | + | |
- | * did you know, that checking for equality with < | + | |
- | * Commenting with why/how comments is central and critical! Just because the person you copied from feels above commenting doesn' | + | |
- | * This is also a general plea to understand what you are doing. I see far too much " | + | |
- | * **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()**, | + | |
- | * avoid using < | + | |
- | * 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====== | ======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. | + | * Getting |
- | * 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. | + | * Working |
- | * We continue our singly linked list implementation, | + | |
- | * Some observations from evaluating sln1: | + | |
- | * be mindful of the perspective; | + | |
- | * 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 | + | |
- | * 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()/ | + | |
- | * These are good foundational habits I'm trying to instill should you find yourself working on or with libraries, more complex code-bases, standards/ | + | |
======Week 4====== | ======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. | + | * Structs, pointers |
- | * 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. | + | * Linked nodes |
- | * 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. | + | * sln1 project |
- | * 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' | + | |
======Week 3====== | ======Week 3====== | ||
- | * Some metrics: | + | * Reviewing pointers |
- | * of the 21 people currently in the class: | + | * Introduced linked nodes |
- | * 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 " | + | |
- | * 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 " | + | |
- | * 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" | + | |
- | * lack of conceptual understanding. Some haven' | + | |
- | * unfamiliarity/ | + | |
- | * maybe trying to shoehorn their one familiar loop into less optimal situations | + | |
- | * brute forcing an infinite loop then (quite unelegantly, | + | |
- | * unfamiliarity/ | + | |
- | * things like the = vs. < | + | |
- | * demonstrable inability to express the choices effectively to the computer (both in concept and in syntax) | + | |
- | * unfamiliarity/ | + | |
- | * if something is lacking a terminating newline, and upon suggesting "it is missing a newline", | + | |
- | * trying to use the excuse that "never having done a menu before" | + | |
- | * unfamiliarity/ | + | |
- | * not understanding what the return type is for, nor how to pass parameters | + | |
- | * the difference between prototyping/ | + | |
- | * 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, | + | |
- | * 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/ | + | |
- | * for those who weren' | + | |
- | * Basically: doing your own work, and accomplishing the task on your own, even if incompletely or imperfectly, | + | |
- | * 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, | + | |
- | * 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 " | + | |
- | * 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====== | ======Week 2====== | ||
- | * ael0 project comes due this week, I've seen on-going activity related to development on this project. Good. | + | * Reviewed functions, and parameters |
- | * The next project will be introduced: **sln0** | + | * pass by value |
- | * The project after that (for those working ahead) will also become available: **sln1**, although we won't formally introduce it until next week. | + | * pass by address |
- | * The plan is to continue to talk about pointers, then structs, then start exploring creating " | + | |
======Week 1====== | ======Week 1====== | ||
Line 161: | Line 78: | ||
* 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. | * 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, | * takeaway: for code 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! | ||