User Tools

Site Tools


Sidebar

projects

pct0 (bonus; due 20230823)
wcp1 (due 20230823)
abc0 (due 20230830)
btt0 (due 20230830)
pct1 (bonus; due 20230830)
pct2 (due 20230830)
wcp2 (due 20230830)
mpg0 (due 20230906)
pct3 (bonus; due 20230906)
wcp3 (due 20230906)
pct4 (due 20230913)
ttb0 (due 20230913)
wcp4 (due 20230913)
pct5 (bonus; due 20230920)
ttb1 (due 20230920)
wcp5 (due 20230920)
dap0 (due 20230927)
gfo0 (due 20230927)
pct6 (due 20230927)
wcp6 (due 20230927)
cgf0 (due 20231004)
pct7 (bonus; due 20231004)
wcp7 (due 20231004)
bwp1 (bonus; due 20231018)
pct8 (due 20231018)
wcp8 (due 20231018)
yol0 (due 20231018)
bjm0 (due 20231025)
pct9 (bonus; due 20231025)
wcp9 (due 20231025)
bjm1 (due 20231101)
gfo1 (due 20231101)
pctA (due 20231101)
wcpA (due 20231101)
pctB (bonus; due 20231108)
set0 (due 20231108)
wcpB (due 20231108)
mor0 (due 20231115)
pctC (due 20231115)
wcpC (due 20231115)
bwp2 (bonus; due 20231129)
pctD (bonus; due 20231129)
wcpD (bonus; due 20231129)
gfo2 (due 20231206)
pctE (bonus; due 20231206)
wcpE (bonus; due 20231206)
EoCE (due 20231214)
haas:fall2023:discrete:projects:lmr2

Corning Community College

CSCS2330 Discrete Structures

PROJECT: Logical Math Routines (LMR2)

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 and basic math operations we implemented in the prior projects in the series and build up further functionality. And of course, collaboratively documenting the process.

OVERVIEW

Using and adapting the basic logical and math operations implemented in lmr0 and lmr1, we are seeking to implement floating point functionality into the mix.

Expand our 12 element “binary” array to support the binary32 single precision format of the IEEE 754 floating point standard.

Adapt the math functions as needed to support floating point operations.

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

Here is a link to a wikipedia article describing how the binary32 (also known as float in C) format works within the IEEE 754 standard: https://en.wikipedia.org/wiki/Single-precision_floating-point_format

Also, here is a presentation showing basic math operations on floating points: https://www.cs.utah.edu/~rajeev/cs3810/slides/3810-20-11.pdf

For those who prefer a video format, here are some videos to help explain the standard:
Basics of IEEE 754: https://www.youtube.com/watch?v=RuKkePyo9zk
Floating Point Addition: https://www.youtube.com/watch?v=aH11flclJDI
Floating Point Subtraction: https://www.youtube.com/watch?v=JnorFLL86DE

Here is an example: Given in IEEE 754: 11000000110110011001100110011010 First bit (bit 0)- Represents positive or negative. In this case, the first bit is one, hence negative. Bit 1-8 represents the exponent, 10000001 or 129 Bit 9-32 represents the fraction, .10110011001100110011010, or ~~.7000000.

Hence, we have -1 (because first bit is 1) times (1.7000000)×2^129-127 = -6.8 Here is a helpful resource: http://mathcenter.oxford.emory.edu/site/cs170/ieee754/

SPECIFICATIONS

Math functions should perform float operations following the IEEE 754 standard. You should have a demo showing off the functionality of the math functions you have made. The way you do this is up to you, but if you have any questions whether your demo is up to standard, you should ask in discord before submitting.

OUTPUT SPECIFICATIONS

Your display demo should output the result of whatever math function you are displaying.

PROGRAM

EXAMPLES

VERIFICATION

No verification script this week. Better luck next ti… wait there isn't a next time! Anyways, all verification will be manual for lmr2. Since we're working with 32 bit arrays this week, if your demo is based on user input, it might be easier to comment out the demo and manually set the array's to values you want to test.

PSEUDOCODE

Cool pattern I found

Let's say we are trying to convert a standard decimal value into a float. We can begin by diving out all valid exponent bits, for example if we are converting 5.125 then our one and only valid exponent would be 4. We thus set the bit representing 4x bit to 1, and then arrive at our precision bits. After dividing by 4, we are left with 1.28125. We can subtract 1 from our value, which leaves 0.28125. We continue this until we have 0 or have passed by the smallest valued precision bit.

 

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:

156:lmr2:final tally of results (156/156)
*:lmr2:used grabit to obtain project by the Sunday prior to duedate [13/13]
*:lmr2:clean compile, no compiler messages [13/13]
*:lmr2:implementation passes verification tests [39/39]
*:lmr2:adequate modifications to code from template [39/39]
*:lmr2:program operations conform to project specifications [39/39]
*:lmr2: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/fall2023/discrete/projects/lmr2.txt · Last modified: 2022/10/31 12:49 by 127.0.0.1