Print your money amounts with a dollar sign and two decimal places after the decimal point. Non-money amounts should print with one decimal place after the decimal point. Print a blank line before the input lines and output lines, as shown in the example below.
A sample run is shown below. This run is from the command line; yours can run under IDLE or another IDE. However, the TA should be able to run your program file at the command level. Your output should be exactly like this for these input data. There is a single space after each colon and two spaces before the indented lines. Include blank lines as indicated.
> python3 Payroll.py Enter employee's name: Smith Enter number of hours worked in a week: 10 Enter hourly pay rate: 9.75 Enter federal tax withholding rate: 0.20 Enter state tax withholding rate: 0.09 Employee Name: Smith Hours Worked: 10.0 Pay Rate: $9.75 Gross Pay: $97.50 Deductions: Federal Withholding (20.0%): $19.50 State Withholding (9.0%): $8.78 Total Deduction: $28.27 Net Pay: $69.22 >
Your file must compile and run before submission. It must also contain a header with the following format:
# File: Payroll.py # Student: # UT EID: # Course Name: CS303E # # Date: # Description of Program:
If you submit multiple times to Canvas, it will rename your file name
to something like Payroll-1.py, Payroll-2.py, etc.
Don't worry about that; we'll grade the latest version.
But if you do it manually and use a combination of tabs and spaces, it's easy to get it wrong. A tab takes you to the next tab stop on the line, which is set (rather arbitrarily) by your editor. If you combine both tabs and spaces, Python might complain about bad indentation even if it appears that all lines in the block start in the same column. If you're having that problem, try globally substituting all tab characters by some number of spaces (perhaps 8) and see what happens. It will at least show where the indendation issue is.
Format vs. round: A floating point number is stored in memory with a certain precision (usually 32 bits or 64 bits). For example math.pi is 3.141592653589793. Since pi is an irrational, this is still an approximation; there is no finite decimal expansion that represents pi exactly. So when you want to print pi (or any other float) you need to decide how much of the representation you want to retain. If you don't specify, you'll get a decimal approximation to as many significant digits as are stored.
Python function format() is the way you tell Python how you'd like a number printed. It generates a string representation suitable for printing. Notice it doesn't change anything in memory or store a new number. If you want to see pi printed to 4 decimal places you might do:
>>> math.pi 3.141592653589793 >>> format(math.pi, ".4f") '3.1416' >>> math.pi # note formatting didn't change pi 3.141592653589793
Python function round() is a way of generating a new number that you could then store in memory. If you then print it, Python will not display trailing zeros. So round() is not a good way to get a certain precision printed.
>>> round(math.pi, 4) 3.1416 >>> math.pi # you didn't change pi 3.141592653589793 >>> x = 2.5002 >>> format(x, ".2f") '2.50' >>> y = round(x, 2) >>> x 2.5002 >>> y # the rounded value you stored 2.5Bottom line: for printing use format(). Only use round() if you really need a new number that is an approximation of the original, e.g., if you're doing limited-precision arithmetic. But that's pretty rare.
Payroll processing: Writing software to process payrolls is big business. In 1998-2000, I was part of a team working for the large computer corporation EDS finding and correcting "Y2K" issues in large software. The Y2K problem (aka the Year 2000 bug) was a widespread, anticipated computer glitch where two-digit year formats ("99" for 1999) could cause systems to interpret the year 2000 as 1900, potentially crashing critical infrastructure like banking, utilities, and transportation. Fears of a technological apocalypse led to massive global investment to fix the issue. While minor problems occurred, the catastrophic failures predicted by some did not happen due to extensive pre-emptive work by programmers and governments, making it a notable "non-event" that revealed society's deep reliance on technology.
My team at EDS took in packages of Cobol code from various companies and fixed problems with the computation of dates, including bugs in the computation of leap years. We wrote software systems to find and fix Y2K defects in the code. You might think this is pretty straightforward, but not when you consider that the packages we remediated were 8M to 15M lines of code. Almost all were payroll processing systems.