Computerised Payroll Calculations

Go to page

Frank X

Well if you are talking about the transfer of money between different
entities it will always be integral. However if you are calculating value or
costs you will find a lot of prices are not integral the price of an
electronic component, a litre of petrol, a euro. Add to that the first thing
you do when calculating present value is discount using compound interest
rates, you know you are going to need to convert to a double anyway.

For areas where you aren't concerned about the exact answer to the penny,
then this is ok (which you imply later). But if you're doing accounts, stick
to fixed point/integer arithmetic.

There are also a number of little rounding peculiarities that can happen
when using floating point, which means that no matter how precisely you
store your number, it can still go wrong in an unhelpful manner. Be very
careful!

If you need to round you need to round it doesn't matter how you store the
number.

Define finance Any system I'm involved in uses integral data - but then,
it's mostly accounting, not projections/estimates (1). Any programmer
involved with one of my systems who uses floating point except where
necessary will get severly told off!

Advertisements

Tim

Are you trying to imply that I am a "computer type"?
If so, then what is that meant to mean? - if it is "uses a computer for his
job" then fair enough - I do. But I don't know of many accountants, lawyers
or any other professional people (including & particularly those in my
profession) who *don't* use computers!

If you are trying to imply that I am a programmer / systems analyst / etc,
you are sadly mistaken.

I can argue about a penny as well as the next man - if it is important (and
yes, a lot of the time it may well not be important). I'm also quite
capable of arguing about the millions of pounds (or indeed, hundreds of
millions or more) - as I often have done in my job.

M

Matthew Church

So here we go again with the pedants wanting increasing levels of
accuracy at the fraction of a penny end, at the expense of speed and
capacity at the multiples of pounds end! But you will *never* satisfy
the pedants!

£
Motor expenses 1.50
Sundry expenses 1.50
----
3.00
====

I'm a pedant and I know Motor Expenses and Sundry Expenses are the
same this week. Round this into pounds for me.

P

Peter Saxton

Clive George

So here we go again with the pedants wanting increasing levels of
accuracy at the fraction of a penny end, at the expense of speed and
capacity at the multiples of pounds end! But you will *never* satisfy
the pedants!

I can assure you my code does not suffer from speed and capacity problems
due to my choice of data types. I explained why earlier, I also pointed out
that it is my job to know such things so other people (such as you) don't
need to worry about them.

£
Motor expenses 1.50
Sundry expenses 1.50
----
3.00
====

I'm a pedant and I know Motor Expenses and Sundry Expenses are the
same this week. Round this into pounds for me.

You're the client. You tell me.
Internally I would probably store these as integral pence, to avoid any
problems - that's my job, not yours.

In the absence of any specification from the client, I'd display 2, 2 and 3,
and when the client complained point out the inherent problems involved with
rounding. Ways round the problem include a means of displaying higher
precision (hover over figure, double click, user options) and as Peter's
already pointed out a display of the rounding errors incurred.

I am speaking from experience here by the way - eg I've just rewritten a
piece of code where the numbers were rounded before adding them up, which
gave very stupid answers.

(Actually your example is slightly harder than it initially appears, as in
some cases 1.50 shouldn't always be rounded to 2. But this is getting a bit
harder and like most of the rest of the world I tend to ignore this
problem - I just know it's there.)

clive

P

Peter Saxton

You're the client. You tell me.
Internally I would probably store these as integral pence, to avoid any
problems - that's my job, not yours.

In the absence of any specification from the client, I'd display 2, 2 and 3,
and when the client complained point out the inherent problems involved with
rounding. Ways round the problem include a means of displaying higher
precision (hover over figure, double click, user options) and as Peter's
already pointed out a display of the rounding errors incurred.

I am speaking from experience here by the way - eg I've just rewritten a
piece of code where the numbers were rounded before adding them up, which
gave very stupid answers.

(Actually your example is slightly harder than it initially appears, as in
some cases 1.50 shouldn't always be rounded to 2. But this is getting a bit
harder and like most of the rest of the world I tend to ignore this
problem - I just know it's there.)

A client of mine was having a stock control/invoicing system progammed
and I told him how it should be tested and people try it out and
comment on it but he just had it done and running without anyone being
able to advise. It was a food company that, among other things made
muesli in various types. The programmer had taken prices from the
purchase invoices and then calculated the different purchase prices
and selling prices while totally ignoring rounding and just displayed
the invoices and reports to the nearest penny. The reports didnt add
up if you checked them manually and the invoices looked totally silly:

Matthew Church

In the absence of any specification from the client, I'd display 2, 2 and 3,
and when the client complained point out the inherent problems involved with
rounding. Ways round the problem include a means of displaying higher
precision (hover over figure, double click, user options) and as Peter's
already pointed out a display of the rounding errors incurred.