User Tools

Site Tools


Sidebar

projects

wcp1 (due 20240828)
btt0 (due 20240904)
wcp2 (due 20240904)
pct0 (bonus; due 20240905)
pct1 (bonus; due 20240905)
pct2 (due 20240905)
abc0 (due 20240906)
msi0 (due 20240911)
pct3 (bonus; due 20240911)
wcp3 (due 20240911)
msi1 (due 20240918)
pct4 (due 20240918)
wcp4 (due 20240918)
dsr0 (due 20240926)
pct5 (bonus; due 20240926)
wcp5 (due 20240926)
gfo0 (due 20241002)
pct6 (due 20241002)
pnc0 (due 20241002)
wcp6 (due 20241002)
dsr1 (due 20241009)
pct7 (bonus; due 20241009)
wcp7 (due 20241009)
bwp1 (bonus; due 20241016)
pct8 (due 20241016)
pnc1 (due 20241016)
wcp8 (due 20241016)
pct9 (bonus; due 20241023)
pnc2 (due 20241023)
wcp9 (due 20241023)
gfo1 (due 20241030)
mag0 (due 20241030)
pctA (due 20241030)
wcpA (due 20241030)
mag1 (due 20241106)
pctB (bonus; due 20241106)
wcpB (due 20241106)
mag2 (due 20241113)
pctC (due 20241113)
wcpC (due 20241113)
pctD (bonus; due 20241120)
wcpD (bonus; due 20241120)
bwp2 (bonus; due 20241204)
gfo2 (due 20241204)
pctE (bonus; due 20241204)
wcpE (bonus; due 20241204)
EoCE (due 20241216)
haas:fall2024:discrete:projects:lmr0

Corning Community College

CSCS2330 Discrete Structures

PROJECT: Logical Math Routines (LMR0)

OBJECTIVE

To take a first-principles, deep dive into the various math functionality often used but not dwelled upon: here we implement math with basic logical operations and build up further routines from those basic parts. And of course, collaboratively documenting the process.

GRABIT

To assist with consistency across all implementations, data files for use with this project are available on lab46 via the grabit tool. Be sure to obtain it and ensure your implementation properly works with the provided data.

lab46:~/src/SEMESTER/DESIG$ grabit DESIG PROJECT

EDIT

You will want to go here to edit and fill in the various sections of the document:

BACKGROUND

This project is inspired by an idea from DirtPig and Paradox.

How do the math functions from the math.h library work? How can you add, subtract, divide, multiply, raise to a power, find a root, etc. without using binary operators? What is the logic behind your day-to-day mathematic operations? and how can you teach it to a computer?

LOGIC GATES

–Note that 0=false and 1=true–

NOT-Is fed one value, returns true if the value is false
AND-Is fed two values, returns true if both values are true
OR-Is fed two values, returns true if any value is true
NOR-Is fed two values, returns true if neither value is true
XOR-Is fed two values, returns true if only one value is true
XNOR-Is fed two values, returns true if both values are true or if both values are false
NAND-Is fed two values, returns true unless both values are true

SHIFT-Is fed an array of bits |1|0|1|0|,if we shift left, then we have |0|1|0|0|. If we keep going then the remaining 1 will fall off and we will have |0|0|0|0|. Will only ever add 0 to the array.

ROTATE-Is fed an array of bits |1|0|1|0|0|, if we rotate left then we get |0|1|0|0|1|. Will put the bit that falls off in the new bit spot created. NOTE: Notice how the only difference between shift and rotate is that with rotate, the first value is saved and stuck on the end, rather then adding a 0 to the end like shift does.

SPECIFICATIONS

We will be pseudo-creating a math library by creating a 12-element array and functions to perform all basic operands.

This week we will be replicating the functionality of the seven basic logic gates and creating our own bitwise operations:

  • Not
  • And
  • Nand
  • Or
  • Nor
  • Xor
  • Xnor
  • Logical shift (potentially 2 separate operations; Shift Left / Shift Right)
  • Logical rotate (Rotate Left / Rotate Right)

We will be writing different functions that will have this functionality. While it seems simple, we have to start somewhere, and you might find the later parts in shift/rotate a bit harder. Your functions will contain a bunch of if, else if, and else statements. Rest assured that you are doing fine if your code consists of a bunch of these.

You must define your own set of values that represent the value true/on and false/off. Could be the traditional TRUE or FALSE, 1 or 0.

IMPORTANT: You will not use the already included bitwise operators from C, since we are creating our own. This would defeat the entire purpose of this iteration of the project.

Make use of the relational operators (==, !=, >, <, >=, ) to complete this project. (Comparison operators such as (&&, ||) are also okay.)

Each bitwise operation function will take 2 arguments and return the result of the operation. Logical shift (left & right) and logical rotate take only one argument and return the result of the operation.

Although this project is intended to be a library, there must be some form of demonstration in the int main() portion of your code. This can be something such as truth tables for each function you have created.

*Our task is to ask questions on Discord or in class and document our findings on this wiki page collaboratively, regarding the functionality of this project.

*For anybody interested in editing the wiki page, here is the dokuwiki user guide: https://www.dokuwiki.org/wiki:syntax#basic_text_formatting -Ash

PROGRAM

You are free to use c++ with this project as well. Remember, if you do so, to edit the makefile to be able to compile your c++ code. To do this, edit your makefile and change CC = gcc to CC = g++. Furthermore, you can make use of gdb if writing this program on a raspberry pi for necessary debugging. To run gdb type gdb file to debug, then type run at the prompt. You can make use of list (lists lines) and break # (to set a breakpoint). You can use display to show the values of variables, and you can make use of N (next), S(step), and C(continue)-resume the execution to breakpoint.

OUTPUT SPECIFICATIONS

Output the display of what the functions do by calling them and printing them inside your main function. This can also be used to confirm that all your functions work correctly. For the bit array you can either display both initial and result or find another way to get input into your bit array.

VERIFICATION

There is no make verify with this project. Your verification can be in the form of the main function displaying the truth tables. You can also display the rotate left and right array values after calling your function. The truth tables are located above to refer to.

EXAMPLE

Heres an example output:

USER@lab46:~/src/fall2022/lmr0$ ./lmr0
--NOT--
--------
 x | out
 0 |  1
 1 |  0

--AND--
 x | y | out
------------
 0 | 0 |  0
 0 | 1 |  0
 1 | 0 |  0
 1 | 1 |  1

--OR--
 x | y | out
------------
 0 | 0 |  0
 0 | 1 |  1
 1 | 0 |  1
 1 | 1 |  1

--NOR--
 x | y | out
------------
 0 | 0 |  1
 0 | 1 |  0
 1 | 0 |  0
 1 | 1 |  0

--XOR--
 x | y | out
------------
 0 | 0 |  0
 0 | 1 |  1
 1 | 0 |  1
 1 | 1 |  0

--XNOR--
 x | y | out
------------
 0 | 0 |  1
 0 | 1 |  0
 1 | 0 |  0
 1 | 1 |  1

--NAND--
 x | y | out
------------
 0 | 0 |  1
 0 | 1 |  1
 1 | 0 |  1
 1 | 1 |  0

Bitset:                1010
Bitset (after LSHIFT): 0100
Bitset (after RSHIFT): 0010

Bitset:                 10100
Bitset (after LROTATE): 01001
Bitset (after RROTATE): 10100
 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • 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.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following (assuming you have a program called uom0.c):

lab46:~/src/SEMESTER/DESIG/PROJECT$ make submit

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.

RUBRIC

I'll be evaluating the project based on the following criteria:

78:lmr0:final tally of results (78/78)
*:lmr0:used grabit to obtain project by the Sunday prior to duedate [13/13]
*:lmr0:clean compile, no compiler messages [13/13]
*:lmr0:implementation passes verification tests [13/13]
*:lmr0:adequate modifications to code from template [13/13]
*:lmr0:program operations conform to project specifications [13/13]
*:lmr0:code tracked in lab46 semester repo [13/13]

Pertaining to the collaborative authoring of project documentation

  • 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

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • 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
  • 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
haas/fall2024/discrete/projects/lmr0.txt · Last modified: 2022/09/04 22:11 by 127.0.0.1