Differences

This shows you the differences between two versions of the page.

--- haas:fall2022:data:projects:dll1 [2017/10/22 22:29] – created - external edit 127.0.0.1
+++ haas:fall2022:data:projects:dll1 [2022/10/15 12:18] (current) – [OVERVIEW] wedge
@@ Line 4: / Line 4: @@
 </WRAP>
-======Project: DLL1======
+======PROJECT: Lists - Doubly-Linked Lists of Nodes (DLL1)======
-=====Errata=====
+=====OBJECTIVE=====
-This section will document any updates applied to the project since original release:
+To continue our journey on doubly-linked data structures, and collaboratively authoring and documenting the project and its specifications.
-  * __revision #__: <description> (DATESTRING)
+=====OVERVIEW=====
+We continue now delving into the realm of doubly-linked data structures. This project: we complete on our doubly-linked list implementation.
-=====Objective=====
+=====UPGRADING=====
-In this project, we continue our doubly linked list re-write, completing the remaining library functions.
+To assist with consistency across all implementations, project files for use with this project, along with the integration of the work you did on the last project, is made possible via a special recipe in the Makefile.
-=====Procedure to Obtain dll1=====
+Simply go into the project base directory, and run:
-As this project utilizes the code you wrote in dll0, you must upgrade to dll1 from dll0 (same thing that we did to transition between the sll* projects):
 <cli>
-lab46:~/src/data/dll0$ make upgrade-dll1
+lab46:~/src/SEMESTER/DESIG/prevPROJECT$ make upgrade-dll1
-...
 </cli>
-=====Project Overview=====
+=====EDIT=====
+You will want to go [[/notes/data/fall2022/projects/dll1|here]] to edit and fill in the various sections of the document:
-As we started with the last project, we're implementing the remaining functions of our new doubly linked list implementation.
+  * [[/notes/data/fall2022/projects/dll1|https://lab46.g7n.org/notes/data/fall2022/projects/dll1]]
-As such, new function prototypes have been added to the list.h header file:
+{{page>notes:data:fall2022:projects:dll1&nouser&nodate&nomdate}}
-<code c>
+=====SUBMISSION=====
-code_t  obtain  (List **, Node **);         // disconnect node  from list
+To be successful in this project, the following criteria (or their equivalent) must be met:
-code_t  empty   (List **);                  // empty an existing list
+  * Project must be submit on time, by the deadline.
-code_t  rmlist  (List **);                  // deallocate empty list
+    * Late submissions will lose 33%  credit per day, with the submission window closing on the 3rd day following the deadline.
+  * All code must compile cleanly (no warnings or errors)
+    * Compile with the **-Wall** and **--std=gnu18** compiler flags
+    * all  requested functionality  must conform  to stated  requirements (either on  this document or  in a comment banner in  source code files themselves).
+  * Executed programs must display in a manner similar to provided output
+    * output  formatted,  where applicable,  must match  that of  project requirements
+  * Processing must be correct based on input given and output requested
+  * Output, if applicable, must be correct based on values input
+  * Code must be nicely and consistently indented
+  * Code must be consistently written, to strive for readability from having a consistent style throughout
+  * Code must be commented
+    * Any "to be implemented" comments **MUST** be removed
+      * these   "to  be  implemented"   comments,  if  still  present  at evaluation time, will result in points being deducted.
+      * Sufficient  comments  explaining  the point  of  provided   logic **MUST** be present
+  * No global variables (without instructor approval), no goto statements, no calling of main()!
+  * Track/version the source code in your lab46 semester repository
+  * Submit  a copy of  your source code to  me using the  **submit** tool (**make submit** on lab46 will do this) by the deadline.
-code_t  compare (List  *, List *, ulli  *); // compare two lists
+====Submit Tool Usage====
+Let's  say you  have completed  work  on the  project, and  are ready  to
+submit, you  would do the following:
-code_t  sortlist(List **, int);             // sort list by mode
+<cli>
-code_t  swapnode(List **, Node *, Node  *); // swap nodes in list
+lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit
-</code>
+</cli>
-These functions will also make use of the status/error codes introduced in dll0. Additional effort has gone into identifying likely codes applied in various conditions. Be sure to reference the provided comments as well as the unit tests for more information.
+You should get some sort of confirmation indicating successful submission
+if all went according to plan. If  not, check for typos and or locational
+mismatches.
-The recommended order of implementation is:
+=====RUBRIC=====
+I'll be evaluating the project based on the following criteria:
-  - **obtain()**
+<code>
-  - **empty()**
+:dll1:final tally of results (91/91)
-  - **rmlist()**
+*:dll1:obtained project by the Sunday prior to duedate [13/13]
-  - **compare()**
+*:dll1:clean compile, no compiler messages [13/13]
-  - **swapnode()**
+*:dll1:implementation passes unit tests [26/26]
-  - **sortlist()** (although note that sorting doesn't necessarily need swapping)
+*:dll1:adequate modifications to code from template [13/13]
+*:dll1:program operations conform to project specifications [13/13]
-Implementing them out of order will likely result in unnecessary duplication of efforts, and I really don't want to see a half dozen half-baked **obtain()** implementations dribbled throughout your code.
+*:dll1:code tracked in lab46 semester repo [13/13]
-====list operation status codes====
-Just as with dll0, you'll notice the presence of a set of #define's in the **data.h** file. These are intended to be used to report on various states of list status after performing various operations.
-They are not exclusive- in some cases, multiple states can be applied. The intent is that you will OR together all pertinent states and return that from the function.
-  * **DLL_SUCCESS** - everything went according to plan, no errors encountered, average case
-  * **DLL_MALLOC_FAIL** - memory allocation failed (considered in error)
-  * **DLL_ALREADY_ALLOC** - memory has already been allocated (considered in error)
-  * **DLL_NULL** - result is NULL (probably in error)
-  * **DLL_EMPTY** - result is an empty list (may or may not be in error)
-  * **DLL_DEFAULT_FAIL** - default state of unimplemented functions (default error)
-  * **DLL_ERROR** - some error occurred
-  * **DLL_INVALID** - invalid list condition
-For example, in the case of "DLL_MALLOC_FAIL", there are actually a total of three states raised:
-  * DLL_ERROR (a problem has occurred)
-  * DLL_MALLOC_FAIL (a problem has occurred when using malloc())
-  * DLL_NULL (no memory allocated, so list cannot be anything but NULL)
-ALL THREE states must be returned from the function in question should such an occurrence take place.
-===compare status codes===
-dll1 introduces additional status codes for one of its functions: **compare()**
-Those codes are as follows:
-<code c>
-//////////////////////////////////////////////////////////////////////
-//
-// Status codes for the doubly-linked list compare() function
-//
-#define  CMP_EQUALITY        0x00
-#define  CMP_L1_NULL         0x01
-#define  CMP_L1_EMPTY        0x02
-#define  CMP_L1_UNDEFINED    0x03
-#define  CMP_L1_GREATER      0x04
-#define  CMP_L1_LESS         0x08
-#define  CMP_L2_NULL         0x10
-#define  CMP_L2_EMPTY        0x20
-#define  CMP_L2_UNDEFINED    0x30
-#define  CMP_L2_GREATER      0x40
-#define  CMP_L2_LESS         0x80
 </code>
-====list library====
-In **src/list/**, you will find the addition of a new set of skeletons of the above prototyped functions, hollowed out in anticipation of being made operational.
-Figure out what is going on, the connections, and make sure you understand it.
+===Pertaining to the collaborative authoring of project documentation===
-Be sure to focus on implementing the functionality from scratch (the more you do this from scratch, vs. referencing old code, the more it will help you).
+  * each class member is to participate in the contribution of relevant information and formatting of the documentation
+    * minimal member contributions consist of:
+      * near the class average edits (a value of at least four productive edits)
+      * near the average class content change average (a value of at least 256 bytes (absolute value of data content change))
+      * near the class content contribution average (a value of at least 1kiB)
+      * no adding in one commit then later removing in its entirety for the sake of satisfying edit requirements
+    * adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
+    * content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
+      * no contributions, co-efficient is 0.50
+      * less than minimum contributions is 0.75
+      * met minimum contribution threshold is 1.00
-====List library unit tests====
+===Additionally===
-In **unit/list/**, you will find these new files:
-  * **unit-obtain.c** - unit test for **obtain()** library function
+  * Solutions not abiding  by spirit of project will be  subject to a 50% overall deduction
-  * **unit-empty.c** - unit test for **empty()** library function
+  * Solutions  not  utilizing descriptive  why and  how comments  will be subject to a 25% overall deduction
-  * **unit-rmlist.c** - unit test for **rmlist()** library function
+  * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
-  * **unit-compare.c** - unit test for **compare()** library function
+  * Solutions not organized and easy to  read (assume a terminal at least 90 characters wide, 40 characters tall)  are subject to a 25% overall deduction
-  * **unit-swap.c** - unit test for **swapnode()** library function
-  * **unit-sort.c** - unit test for **sortlist()** library function
-Enhancements to these unit tests may be provided via dll1 project updates.
-There are also corresponding **verify-FUNCTION.sh** scripts that will output a "MATCH"/"MISMATCH" to confirm overall conformance with the pertinent list functionality.
-These are complete runnable programs (when compiled, and linked against the list library, which is all handled for you by the **Makefile** system in place).
-Of particular importance, I want you to take a close look at:
-  * the source code to each of these unit tests
-    * the purpose of these programs is to validate the correct functionality of the respective library functions
-    * follow the logic
-    * make sure you understand what is going on
-    * ask questions to get clarification!
-  * the output from these programs once compiled and ran
-    * analyze the output
-    * make sure you understand what is going on
-    * ask questions to get clarification!
-Also note that, while considerable effort was made to ensure a broad range of tests were incorporated into each unit test, they are by no means a complete nor exhaustive battery of tests. There may be scenarios the unit tests do not currently check for. You are welcome and encouraged to perform additional tests to ensure your implementation is as rock solid as it can be.
-====List library applications====
-===palindrome===
-Now that we've completed our doubly-linked list functionality, we can use these individual functions to piece together solutions to various everyday problems where a list could be effective. After all, that's a big aspect to learning data structures- they open doors to new algorithms and problem solving capabilities.
-Our endeavor here will be to revisit that of palindromes (ie words/phrases that, when reversed, spell the same thing).
-This implementation will be considered an extra credit opportunity, so as to offer those who have fallen behind (but working to get caught up) a reprieve on some of the credit they've lost.
-It is also highly recommended to undertake as it will give you further experience working with these concepts.
-=====Expected Results=====
-To assist you in verifying a correct implementation, a fully working implementation of the node and list libraries should resemble the following (when running the respective verify script):
-====list library====
-Here is what you should get for list:
-<cli>
-lab46:~/src/data/dll1$ make check
-======================================================
-=    Verifying Doubly-Linked  List Functionality     =
-======================================================
-    [obtain] Total:  57, Matches:  57, Mismatches:   0
-     [empty] Total:   7, Matches:   7, Mismatches:   0
-    [rmlist] Total:   7, Matches:   7, Mismatches:   0
-   [compare] Total:  12, Matches:  12, Mismatches:   0
-  [swapnode] Total:  31, Matches:  31, Mismatches:   0
-  [sortlist] Total:  48, Matches:  48, Mismatches:   0
-======================================================
-   [RESULTS] Total: 162, Matches: 162, Mismatches:   0
-======================================================
-lab46:~/src/data/dll1$
-</cli>
-=====Submission=====
-{{page>haas:fall2017:common:submitblurb#DATA&noheader&nofooter}}

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools