Calculation Problems

I am writing a program for my beginning c++ class. It is supposed to create an invoice in the console window. so far, everything is working perfectly, except for one thing.

My invoice comes out looking like this:

696.60 - 27 Adult Meals at $25.80 each.
+ 46.44 - 3 Child Meals at $15.48 each.
--------
743.04 - Total Cost of All Meals (Add the above numbers together)
+ 52.01 - Weekend Surcharge (743.04 x .07)
+143.11 - Tax/Tip ((743.04 + 52.01) x .18)
--------
938.16 - Total Party Cost
- 57.50 - Deposit Received
--------
880.66 - Balance Due
- 32.84 - 3.5% Prompt Payment Discount (938.16 x .035)
--------
847.83 - Balance Due (If Paid Within Ten Days)

The problem is that if I add these numbers on a calculator, I get as result of $847.82, not $847.83. I checked them individually and they are all being rounded properly. If I add them up using the entire decimal value of the calculations, rather than the truncated value, I get $847.83.

So, the question is as follows:

In C++, how do I do each calculation, round the answer to 2 decimal places, then use only the rounded number in the next calculation?

The easiest thing when dealing with money, is multiply all the numbers by 100, do the calculations, then divide the result by 100.

I agree. That would be easier. However, I need to display the results of each calculation in addition to coming to an end result.

It would be far easier to just display pennies.

Quote:

---

Originally Posted by justasiam

It would be far easier to just display pennies.

---

It's a general problem. How do you represent money in a computer?

The usual reply is to use a money package.

Well, which one?

I can't say I know.

Quote:

---

Originally Posted by justasiam

I agree. That would be easier. However, I need to display the results of each calculation in addition to coming to an end result.

It would be far easier to just display pennies.

---

I'd still do it the same way. Perform the calculations on arithmetic, and divide by 100 or even convert to a string and insert a decimal point to output. Then you don't have to deal with floating point inaccuracies.

Quote:

---

Originally Posted by justasiam

I agree. That would be easier. However, I need to display the results of each calculation in addition to coming to an end result.

It would be far easier to just display pennies.

---

It's good design to separate user interface from business logic in your application. Displaying (intermediate) results is user interface; calculating them is business logic, in this case.
For the business logic, it is best to use integer arithmetics, because that's precise and floating point arithmetics is inherently imprecise on a computer. What's easier or better for the user interface should not affect this at all. When you need to display a result, do the necessary conversions, but keep this code separate from the business logic of your application.

your problem is...

you are calculating values that end up having values that have more digits than 2.
you're only DISPLAYING 2 digits in the report
but the end result with full digits is correct.

You will need to explicitely round every intermediate value or accept the fact you are working with higher precision along the way and rounding at the very end. both methods are used in real life situations.


Follow your result with my changes...

696.60 - 27 Adult Meals at $25.80 each. ok
+ 46.44 - 3 Child Meals at $15.48 each. ok
--------
743.04 - Total Cost of All Meals (Add the above numbers together) ok
+ 52.01 - Weekend Surcharge (743.04 x .07) actually 52.0128 displayed as 52.01
+143.11 - Tax/Tip ((743.04 + 52.01) x .18) actually 143.109 displayed as 143.11
--------
938.16 - Total Party Cost actually 938.1618 displayed as 938.16
- 57.50 - Deposit Received ok
--------
880.66 - Balance Due actually 880.6618 displayed as 880.66
- 32.84 - 3.5% Prompt Payment Discount (938.16 x .035) actually 938.1618*.035 = 32.835663 displayed as 32.84 --------
847.83 - Balance Due (If Paid Within Ten Days) actually 847.826137 displayed as 847.83



the math is correct as y ou see above, you're just getting a different result than you expect because the sum of rounded values is not the same as a rounded sum of those same values

Quote:

---

Originally Posted by OReubens

You will need to explicitly round every intermediate value or accept the fact you are working with higher precision along the way and rounding at the very end. both methods are used in real life situations.

---

I would prefer option #1. Appearance to a customer is more accurate than higher precision behind the scenes.

Again, how do I take the rounded result and use it for the next calculation?

Quote:

---

Originally Posted by OReubens

Follow your result with my changes...

---

I don't see any changes you are suggesting? I see you showing me that the math is correct, and explaining the discrepancy. I already understood this.

If this were only one invoice, it would not be much of a problem, but the data file contains multiple invoice entries.

What changes do I make here?

Quote:

---

Originally Posted by justasiam

What changes do I make here?

---

If you worked for a financial institution, then my advice is that you better get a true money or exact math library.

Otherwise you risk losing information, no matter how hard you try to round, and you would risk getting into legal trouble if a customer finds out you're shorting them some pennies. Rounding may work 95% to 98% of the time -- it's that other 2% to 5% of the time that will get you in hot water.

In other words, the assignment given to you is flawed already due to the inexactness of floating point values. Either you work totally in integer or use a math library, of if you're good enough, come up with your own fixed-point library. Using doubles and trying to finagle with rounding may give you most of the results that you seek -- but the key word here is most.

Regards,

Paul McKenzie

What Paul hast posted above is correct. floating point values are not an ideal way to deal with for financial type applications that need ACCURACY (floating point numbers are NOT accurate, they're approximations).

In the same way that 1/3 cannot be accurately represented in decimal 0.33333333333333333333333333333333......(endless amount of 3's here) in a finite size type,
the value 1/10 cannot be accurately represented in a finite binary type. You get a similar type endless repetition of bits.

This means that... While you CAN round a double/float to say 2 decimal positions, the result will always be slightly 'off'. This can end up having consequences in the end, and this can be especially annoying if you need to compare values.

Floating point values are good for mathematical/statistical problems where precision is needed but accuracy isn't, but in financial/economic/accounting apps, accuracy is important.

Also: See the floating point FAQ for more info.

I hear what you are saying. Let me give you the exact wording of the assignment and then links to my code. I would post the entire code here, but there are too many characters for this post to hold it.

http://www.jcitech.net/Images-ForumPosts/Lab6C-Dollars.txt is my old code (working in dollars and cents).

http://www.jcitech.net/Images-ForumPosts/Lab6C-Pennies.txt is the new code (working in pennies and converting everything to pennies).

The Output Data File is at http://www.jcitech.net/Images-ForumPosts/Lab6CDataFile-Output.txt

The Output Error file is at http://www.jcitech.net/Images-ForumPosts/Lab6CDataFile-Error.txt
----------------------------------
CSIT 575 – Programming Fundamentals for Computer Science Lab #6C

Objectives
To learn to code, compile and run a program containing three or more functions. This is a catering company.

Assignment
Plan and code a program utilizing one file for input and one file for output to solve the following problem:

• For adults, the deluxe meals will cost $25.80 per person and the standard meals will cost $21.75 per person, dessert included. Children's meals will cost 60 percent of adult meals. Everyone within a given party must be served the same meal type.
• A surcharge, currently 7 percent, is added to the total bill if the catering is to be done on the weekend (Friday, Saturday, or Sunday).
• All customers will be charged the same rate for tip and tax, currently 18 percent (applied only to the cost of the food).
• To induce customers to pay promptly, a discount is offered if payment is made within ten days.
• This discount depends on the amount of the total bill. If the bill is less than $100.00, the discount is 1.5 percent; if the bill is at least $100.00 but less than $400.00, the discount is 2.5 percent; if the bill is $400.00 or more, the discount is 3.5 percent.

Input
Number of adults, number of children, meal type (D, S) character indicating whether or not date is a weekend (Y/N), amount of any deposit. Create the data file below in text editor or Notepad.

Data File
http://www.jcitech.net/Images-ForumPosts/Lab6CDataFile-Input.txt

Output
Output an itemized bill listing the number of adults, children, cost for adult meals, cost for children's meals, total food cost, surcharge (if appropriate), tax and tip, total cost of the party, deposit (if any), total balance due, amount of discount if bill if paid within ten days. Output error data to a separate error file.

Turn in
Top down design with parameters, program listing and program output. Turn in all data files used in the program.

Question:
Since this is not a banking problem, I don't need that level of accuracy. Is there a way to look at the hundredth place on a decimal value and if it is > 4, then add 1 to the tenth place?

Quote:

---

Originally Posted by justasiam

Since this is not a banking problem, I don't need that level of accuracy. Is there a way to look at the hundredth place on a decimal value and if it is > 4, then add 1 to the tenth place?

---

The problem with this is that by the time you need to look at the hundredths place, it may have already been "corrupted" by previous calculations.

The usual calculation is to add a 1/2 penny to the number of pennies, in other words, add 0.005 to the value. Then the hundredths and tenths place take care of themselves. But again, you are dealing with inaccuracies and even this isn't guaranteed to give you the number you desire.

You really need to ask the teacher exactly what is acceptable, as there is no such thing as an "rounding" that works 100% of the time using doubles. It doesn't matter what your assignment says, unless you use an exact math library, or create your own exact math class, or deal totally with integer, you cannot guarantee accuracy with varying data.

Maybe the assignment is to test you on what you're asking us -- if so, then we already gave you the easiest solution, and that is to use integer, and only on output, show the numbers with a decimal point in them by dividing by 100 on the output.

Regards,

Paul McKenzie

Thank you Paul. Can you tell me what exact math library I should be using?

You can read this thread for some more information:

http://stackoverflow.com/questions/4...vas-bigdecimal

But if it's for school work, then again, approach the teacher and state the issue with the assignment. Then you will more than likely get a definitive answer as to how to complete the assignment (i.e. whether inaccuracies are acceptable, etc.).

Regards,

Paul McKenzie

Paul, I agree with you. I will speak to my teacher on Monday about this. However, I do not want to waste and entire weekend waiting to be able to ask her the question.

OK, after reading that article (thank you Paul) and many others, I added modified every calculation I was using that involved a decimal value (.18 for tax, .07 for surcharge and .015-.035 fro discount) to the following tResults.

Code:

---

        double tResult = 0;
        tResult = totalFCost * TIP_TAX_RATE; // .18
        return floor((tResult + 0.005) * 100) / 100;

---

The above may work for your case specifically...
but it is not guaranteed to give you the answer you expect for every possible input (such is the nature of working with floating point).

0.005 cannot be represented in a double so this value is going to end up being an approximation.
tResult equally is not accurate but an approximation.
the end result might be just a notch too high or a notch too low causing floor() to return the wrong value.
The end divide by 100 again introduces additional inaccuracies.


There are methods so you can correct the inaccuracies on each step but this isn't easy stuff, there's reasons why the recommendation is to simply avoid it altogether. :p