PROJECT: Logical Math Routines (LMR1)

OBJECTIVE

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

OVERVIEW

Using the basic logical operations implemented in lmr0, we are seeking to implement the following math routines all upon our 12-bit (or more) custom array:

addition
subtraction
multiplication
integer division
integer remainder
exponent (power)
some additional math operation of your choice (square root, sine, etc.)

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:

https://lab46.g7n.org/notes/discrete/fall2022/projects/lmr1

BACKGROUND

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?

Continuing from where we left off from lmr0, after making bitwise operator functions:

Not
And
Nand
Or
Nor
Xor
Xnor
Logical shift
Logical rotate

This week we will be focusing on creating functions that do basic algorithm operations.

SPECIFICATIONS

Use your bitwise functions from lmr0. Bit arrays should be the output.

*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

OUTPUT SPECIFICATIONS

Determine a unified means of output so that all submissions have an identical format. Should get identical output to running non-bitwise versions of the same functions.

Example: your function subtraction of 27 and 3 should output 24 just like 27 - 3 = 24.

Make sure to be mindful of what numbers you are using in the tests. You should ideally pick numbers that could cause problems in your code, that way you can see if you are missing a case, or maybe a function is incorrect. Other than this, there is no output specification. Show your function does what it's supposed to do.

PROGRAM

Two main ways to approach this project: the more laid out approach, and the straight to the point approach. You can either do the bitwise portion of each mathematical operator and convert it to the bit array, or, just work with the bit array from the start. If you work with the bit array from the start, you might find some functions easier, but some functions could also be harder. There really isn't a “recommended” approach just whatever way you find easier to interpret and understand.

When it comes to binary division and multiplication, you may want to try using your add and subtract functions to complete the division and multiplication functions. For multiplication, you will want to add a 12-bit array to itself n amount of times based on the other function input. This may require the creation of a binary to int converter for this solution to work.

EXAMPLES

COOL BITWISE TRICKS

1. Right-shift is equivalent to dividing by 2
2. Left-shift is equivalent to multiplying by 2
3. AND can be used on the first bit to check for odd/even

VERIFICATION

Make sure to test multiple different numbers, some numbers may work while others may not. Derive a set of tests that all submissions should perform to ascertain correctness (state the tests, the inputs, and the expected outputs). In conjunction with conforming output specifications, all submissions should match (this is the basis for writing a verification script that can automate the process).

Which, being said: once output specifications and verification tests have been established, anyone writing a verification script to automate this can be eligible to receive bonus points.

PSEUDOCODE

C++ operator overloading

C++ operator overloading could be relevant to this project as a means of cleaning up your code. With operator overloading you could go from

multiply(a, b)

To:

a * b

If you're interested in doing this the basic syntax is as follows:

struct MyStruct
{
    MyStruct operator*(MyStruct other_struct) { ... }
    bool operator==(int x) { ... }
}

Its just a function with some nice syntax!

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:

117:lmr1:final tally of results (117/117)
*:lmr1:used grabit to obtain project by the Sunday prior to duedate [13/13]
*:lmr1:clean compile, no compiler messages [13/13]
*:lmr1:implementation passes verification tests [26/26]
*:lmr1:adequate modifications to code from template [26/26]
*:lmr1:program operations conform to project specifications [26/26]
*:lmr1: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

Lab46 Wiki

Sidebar

Table of Contents

PROJECT: Logical Math Routines (LMR1)

OBJECTIVE

OVERVIEW

GRABIT

EDIT

BACKGROUND

SPECIFICATIONS

OUTPUT SPECIFICATIONS

PROGRAM

EXAMPLES

COOL BITWISE TRICKS

VERIFICATION

PSEUDOCODE

C++ operator overloading

SUBMISSION

Submit Tool Usage

RUBRIC

Pertaining to the collaborative authoring of project documentation

Additionally

Lab46 Wiki

User Tools

Site Tools

Sidebar

Table of Contents

PROJECT: Logical Math Routines (LMR1)

OBJECTIVE

OVERVIEW

GRABIT

EDIT

BACKGROUND

SPECIFICATIONS

OUTPUT SPECIFICATIONS

PROGRAM

EXAMPLES

COOL BITWISE TRICKS

VERIFICATION

PSEUDOCODE

C++ operator overloading

SUBMISSION

Submit Tool Usage

RUBRIC

Pertaining to the collaborative authoring of project documentation

Additionally

Page Tools