I have 10+ experience in C/C++ - mostly automation and graphics. I have
never written any business apps though. Recently I've been asked to write a
simple report that would calculate sales commission. The report needs to be
generated from within a C/C++ app. I don't want to mess it up so I thought
maybe someone from this group could give me some advice or point to me to a
place that'll provide some background on the issue.
Here is a description of the problem...
A salesperson sales items for a price (p). Each item category has a
commission rate (r) assigned to it. In a simple way I would calculate a
commission (c) as follows:
c = p * r and then round c to 2 decimal places.
The total for the report would be a sum of all commissions (rounded)
calculated for the items.
Is this the way to do that? Some item prices might be really low and I'm
concerned that floating point arithmetic that can get out of hand. Is
rounding to 2 decimal places a 'standard' in such cases?
I'd appreciate any suggestions,
Thanks
Jurek 7 4311 I have 10+ experience in C/C++ - mostly automation and graphics. I have never written any business apps though. Recently I've been asked to write a simple report that would calculate sales commission. The report needs to be generated from within a C/C++ app. I don't want to mess it up so I thought maybe someone from this group could give me some advice or point to me to a place that'll provide some background on the issue.
Here is a description of the problem... A salesperson sales items for a price (p). Each item category has a commission rate (r) assigned to it. In a simple way I would calculate a commission (c) as follows: c = p * r and then round c to 2 decimal places. The total for the report would be a sum of all commissions (rounded) calculated for the items.
Is this the way to do that? Some item prices might be really low and I'm concerned that floating point arithmetic that can get out of hand. Is rounding to 2 decimal places a 'standard' in such cases?
If you have to add a long list of floating point values (the standard float
and doubles), the correct approach is to sort them beforehand so that you
add the smallest values first. That way the sum will be closest to the
'real' sum you should have because the precision error will be as small as
possible.
You can use doubles instead of floats to increase precision. that should be
fine for most applications. (simple billing , commsions etc)
Do a google for floating point precision and arithmetic precision if you
want to know the exact limits and errors you will have.
rounding to 2 digits is only done for the end result. not for the
intermediates, except perhaps for displaying purposes.
Of course, If you want to be correct up until the last hunderth of a cent,
you can use System::Decimal (.NET) which was made for financial calculations
that do not allow for rounding errors (bank apps and bookkeeping stuff).
That means you would have to use C++/CLI, though.
--
Kind regards,
Bruno van Dooren br**********************@hotmail.com
Remove only "_nos_pam"
"Jurek" <no****@nospam.com> wrote in message
news:OP*************@TK2MSFTNGP05.phx.gbl... I have 10+ experience in C/C++ - mostly automation and graphics. I have never written any business apps though. Recently I've been asked to write a simple report that would calculate sales commission. The report needs to be generated from within a C/C++ app. I don't want to mess it up so I thought maybe someone from this group could give me some advice or point to me to a place that'll provide some background on the issue.
Here is a description of the problem... A salesperson sales items for a price (p). Each item category has a commission rate (r) assigned to it. In a simple way I would calculate a commission (c) as follows: c = p * r and then round c to 2 decimal places. The total for the report would be a sum of all commissions (rounded) calculated for the items.
Is this the way to do that? Some item prices might be really low and I'm concerned that floating point arithmetic that can get out of hand. Is rounding to 2 decimal places a 'standard' in such cases?
If your salespeople are not selling fleets of 747s or A300s, in a quick
one-off application I'd expect that most amounts would be held internally as
pennies in 32 bit "int"s. If that doesn't provide sufficient range you could
use the __int64 type.
Of course when it comes time to display the results, the dollar amount comes
from dividing the penny amount by 100, the cents amount is the remainder
modulo 100.
Regards,
Will
Regards,
Will
Bruno, thanks for your input. Unfortunately I can't use C++/CLI. In
regards to rounding... I think I might need to show commission on a per
item basis as well as a report total. If I do not round the commission at
the item level then the report total (i.e. the sum of item commissions)
might not always be correct 'visually' . For example, I might end up with
something like:
item1 0.21
item2. 2.99
item3 0.01
-----------
total 3.22
In reality I don't think that this would happen when the number of items is
so low. On the other hand, with 100ths of items it is almost certain that
the total will be off (visually) by a cent or more. Rounding at the item
level would eliminate the 'visual' problem but would compromise accuracy of
the total (which is probably more important).
Any idea what is appropriate in this case?
Thanks,
Jurek
"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:Oh*************@TK2MSFTNGP04.phx.gbl... I have 10+ experience in C/C++ - mostly automation and graphics. I have never written any business apps though. Recently I've been asked to write a simple report that would calculate sales commission. The report needs to be generated from within a C/C++ app. I don't want to mess it up so I thought maybe someone from this group could give me some advice or point to me to a place that'll provide some background on the issue.
Here is a description of the problem... A salesperson sales items for a price (p). Each item category has a commission rate (r) assigned to it. In a simple way I would calculate a commission (c) as follows: c = p * r and then round c to 2 decimal places. The total for the report would be a sum of all commissions (rounded) calculated for the items.
Is this the way to do that? Some item prices might be really low and I'm concerned that floating point arithmetic that can get out of hand. Is rounding to 2 decimal places a 'standard' in such cases?
If you have to add a long list of floating point values (the standard float and doubles), the correct approach is to sort them beforehand so that you add the smallest values first. That way the sum will be closest to the 'real' sum you should have because the precision error will be as small as possible.
You can use doubles instead of floats to increase precision. that should be fine for most applications. (simple billing , commsions etc) Do a google for floating point precision and arithmetic precision if you want to know the exact limits and errors you will have.
rounding to 2 digits is only done for the end result. not for the intermediates, except perhaps for displaying purposes.
Of course, If you want to be correct up until the last hunderth of a cent, you can use System::Decimal (.NET) which was made for financial calculations that do not allow for rounding errors (bank apps and bookkeeping stuff). That means you would have to use C++/CLI, though.
--
Kind regards, Bruno van Dooren br**********************@hotmail.com Remove only "_nos_pam"
"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:Oh*************@TK2MSFTNGP04.phx.gbl... Of course, If you want to be correct up until the last hunderth of a cent, you can use System::Decimal (.NET) which was made for financial calculations that do not allow for rounding errors (bank apps and bookkeeping stuff). That means you would have to use C++/CLI, though.
Actually, System.Decimal is nothing more than a wrapper over the OLE
Automation DECIMAL type, which you can use in native C++ programs.
See the functions VarDec* in MSDN at http://msdn.microsoft.com/library/en...asp?frame=true
-cd
> Bruno, thanks for your input. Unfortunately I can't use C++/CLI. In regards to rounding... I think I might need to show commission on a per item basis as well as a report total. If I do not round the commission at the item level then the report total (i.e. the sum of item commissions) might not always be correct 'visually' . For example, I might end up with something like:
item1 0.21 item2. 2.99 item3 0.01 ----------- total 3.22 In reality I don't think that this would happen when the number of items is so low. On the other hand, with 100ths of items it is almost certain that the total will be off (visually) by a cent or more. Rounding at the item level would eliminate the 'visual' problem but would compromise accuracy of the total (which is probably more important).
Any idea what is appropriate in this case?
If you have several items, it is bound to happen as you say.
Increasing number of digits displayed will not solve that. it will only make
it less obvious, and noticeable only when you have a larger number of items.
It hink the correct approach would be to only display as much decimals as
exist in reality for your currency (0,01 $ or 0.01 Euro for example).
Your end result should be calculated with the'real' values and might end up
not 100% the sum of the individual items, but that cannot be helped. I think
the best you could do would be to place a small note somewhere (or perhaps
mention it in a tooltip popup or help item) that the visual representation
might be a few cents off, but that the end result will be correct. And then
add an explanation of why this is the case.
That way your users will know what is going on if they should ask themselves
the question.
--
Kind regards,
Bruno van Dooren br**********************@hotmail.com
Remove only "_nos_pam"
Will, thanks for the suggestion. I have to say that I was thinking of going
with pennies only. The 32bit int is more than I need in this case. My
concern is that I'd still face rounding problems at some point. If, let's
say, a commission on an item is 7% and the price is 12 pennies (0.12) then
the commission amount calculated as:
c = 12 * 7 / 100 will not be very accurate if c is a 32-bit int. Unless,
of course, this is generally acceptable.
Any ideas?
Thanks,
Jurek
"William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
news:Ou**************@TK2MSFTNGP05.phx.gbl... "Jurek" <no****@nospam.com> wrote in message news:OP*************@TK2MSFTNGP05.phx.gbl...I have 10+ experience in C/C++ - mostly automation and graphics. I have never written any business apps though. Recently I've been asked to write a simple report that would calculate sales commission. The report needs to be generated from within a C/C++ app. I don't want to mess it up so I thought maybe someone from this group could give me some advice or point to me to a place that'll provide some background on the issue.
Here is a description of the problem... A salesperson sales items for a price (p). Each item category has a commission rate (r) assigned to it. In a simple way I would calculate a commission (c) as follows: c = p * r and then round c to 2 decimal places. The total for the report would be a sum of all commissions (rounded) calculated for the items.
Is this the way to do that? Some item prices might be really low and I'm concerned that floating point arithmetic that can get out of hand. Is rounding to 2 decimal places a 'standard' in such cases?
If your salespeople are not selling fleets of 747s or A300s, in a quick one-off application I'd expect that most amounts would be held internally as pennies in 32 bit "int"s. If that doesn't provide sufficient range you could use the __int64 type.
Of course when it comes time to display the results, the dollar amount comes from dividing the penny amount by 100, the cents amount is the remainder modulo 100.
Regards, Will
Regards, Will
"Jurek" <no****@nospam.com> wrote in message
news:uc***************@TK2MSFTNGP05.phx.gbl... My concern is that I'd still face rounding problems at some point.
Yes, but that is life. In most environments we don't split pennies. So, as
always, a good plan is to defer the rounding until as late as possible in
the life of a transaction. That minimizes the error. And depending on the
application, _best_ case is an error of no more than .5 cents per
transaction.
If, let's say, a commission on an item is 7% and the price is 12 pennies (0.12) then the commission amount calculated as: c = 12 * 7 / 100 will not be very accurate if c is a 32-bit int. Unless, of course, this is generally acceptable. Any ideas?
Well, you could treat percentages as I propose treating dollar amounts -
scale them up and defer the division until the very end (which narrows the
range of amounts you can deal with, btw)
Of course, it helps to know about the kinds of transactions your application
will process. IIRC the NYSE for many years quoted prices of shares of stock
in eighths of a dollar. As there were no trades on the floor except in
blocks of 100 shares, the fact that a single share may have cost $1.125 was
not cause for concern between "specialists" who moved bazillions of shares a
day because 100 such shares would could $11.25. There was _never_ the
possibility of small rounding errors cascading into something large.
A problem arose only when granny sold her 10 or 12 share portfolio. Then
there was rounding error when the broker / exchange aggregated these small
orders transactions to execute the transaction. But with such a small number
of shares for granny the error for her is "in the noise".
In the end what you do will be determined by the numbers and kinds of
transactions that you expect to handle.
Regards,
Will This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Ciar?n |
last post by:
I have about 7 tables I need to join, but am having a lot of
difficulty with the joins, that I need some help on.
I'll provide the details of four tables to illustrate the scenario.
I have one...
|
by: J-T |
last post by:
Thanks
Here is what I am trying to do without using database :
These is a simple application with the description below, can someone help
me on how to create classes,collections, .... for this:
...
|
by: mike.mcnulty |
last post by:
Canadian-based IT consulting firm, specializing in implementing
Microsoft .NET technologies, seeks individuals for commission
referral-based leads.
We are looking for individuals that may...
|
by: kux |
last post by:
Hello everyone,
I hope someone is out here who can help me with a simple calculation...
I have a sales data base in access with monthly sales history by
product. to make future predictions I...
|
by: kux |
last post by:
Hello everyone,
I hope someone is out here who can help me with a simple calculation...
I have a sales data base in access with monthly sales history by
product. to make future predictions I...
| |
by: rabraham |
last post by:
I have a commission report I’m working on and it is causing to lose hair fast.
I need help customizing this commission report. The current report has a couple conditions:
Condition 1:
Pay 2%...
|
by: SuzK |
last post by:
I am trying to calculate in VBA in Access 2002 a moving average and update a table with the calculations. Fields in my WeeklyData table are
Week Ending (date)
ItemNbr (double)
Sales Dollars...
|
by: spima05 |
last post by:
Hello
I am developing a database to calculate commissions on a sale for each
rep involved in the same and their uplines.
Below is the database structure and the commissions schedule. I am...
|
by: lizBeth |
last post by:
Hi all,
i seem to have gotten stuck on this coursework, i am unsure as to how to implement a method in the main class to calculate the sum of all employees monthly salaries.
Everything...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |