Computerised Payroll Calculations

[Frank X]

I decided to have a look at these calculations. It can't be difficult I
thought ;o)

Each tax (PAYE, NIC, Employers NIC) has rates and has bands that the rate
applies to in a linear fashioned, PAYE also has a personal allowance before
tax is applied, for genericity say the NIC have 0 allowance.

So I naively think :

generic calculation for total tax in each band is

portion of Year = weekNo/ 52 (or monthNo / 12)
low = lower limit of band * portion of Year
high = higher limit of band * portion of Year
allowance = Personal allowance * portion of Year

tax in band = min( max((pay to date - allowance - low),0) , high - low) *
rate.

Sum up the bands for each tax and round to pence as the end. (up , down,
normal or even banking conventions)

Ok the anal may want to round intermediate results ( but this is unnecessary
as the portion of year is in weeks or months, e.g. no probs with computer
precision).

So I read http://www.inlandrevenue.gov.uk/ebu/payerout10.pdf.

It appears that the revenue have decided that rather than use a clean and
simple generic algorithm (as is allowed for NIC) PAYE calculations should be
far more complex to match results given by looking up tables.

Why would they do this?

To my unprofessional eye it appears that they should have been drowned at
birth.

Even if it was important to exactly match the results from tax tables does
anybody still use them in the age of the free spreadsheet?

 

[Frank X]

You dont have to use the tax tables.

IR's E13 "day-to-day payroll", seems to imply you do have to *match* the
tables. I know people don't use them but the software calculation needed to
match them is unnecessarily complex.

Do you have a ref for other methods of calculation?

 

[Matthew Church]

Even if it was important to exactly match the results from tax tables does
anybody still use them in the age of the free spreadsheet?

Worrying about such things you are doomed to an unhappy life.

What is 2.01 in binary? There is no answer, every computer uses an
algorithm, each spreadsheet gives a different "wrong" answer. Do x*y/z
(large numbers) in your calculator, then x/z*y, like as not you will
come up with different answers.

I once had the joy of seeing a pedant like yourself trying to use
Fourth Shift integrated manufacturing software. Because Fourth Shift
is very large it has to aggressively conserve memory in its number
algorithms. Imagine this pedant's joy when he found that for "Shares
in group companies" he could choose from £1.99 or £2.01 but get no
closer than that!

 

[Clive George]

I once had the joy of seeing a pedant like yourself trying to use
Fourth Shift integrated manufacturing software. Because Fourth Shift
is very large it has to aggressively conserve memory in its number
algorithms.

substitute old and/or badly written for large and I'll believe you.

Imagine this pedant's joy when he found that for "Shares
in group companies" he could choose from £1.99 or £2.01 but get no
closer than that!

I would call that a bug, which makes it sound like 'badly written' to me.
There's no excuse for that sort of nonsense these days. Eg Oracle get this
sort of thing right, and they do large.
TBH the symptoms don't look like aggressive memory conservation, but just
stupid rounding somewhere.

(Pedantry is a very useful attribute when dealing with software.)

clive

 

[Matthew Church]

substitute old and/or badly written for large and I'll believe you.


I would call that a bug, which makes it sound like 'badly written' to me.
There's no excuse for that sort of nonsense these days. Eg Oracle get this
sort of thing right, and they do large.
TBH the symptoms don't look like aggressive memory conservation, but just
stupid rounding somewhere.

(Pedantry is a very useful attribute when dealing with software.)

clive

But the point is it doesn't matter. £1.99 *IS* £2, £2.01 *IS* £2.

If a number can be held in one byte, then doubling it to two bytes
will double every part of every calculation. Your factory will close,
your work force will be on skid row, babies will starve, little fluffy
kittens will mew as they are being drowned, and it's all your fault
for being a pedant!

 

[Frank X]

"Frank X" <[email protected]> wrote in message

Worrying about such things you are doomed to an unhappy life.

This is uk.business.accountancy, surely I won't be unhappy here!

What is 2.01 in binary? There is no answer, every computer uses an
algorithm, each spreadsheet gives a different "wrong" answer. Do x*y/z
(large numbers) in your calculator, then x/z*y, like as not you will
come up with different answers.

2.01 does have precise binary representations either as a fraction or as an
infinite recurring binary *point* number (I would say decimal point but
obviously it isn't).

There is a correct answer the IR specifies it. Any software that does not
match the IR specification is wrong and sloppy. No rounding errors would
occur unsing this spec in a computer with decimal precision over 4 or 5
decimal places.

The problem is that the way the IR specifies the calculations, differences
of pounds can occur, much bigger than rounding errors. So every time I use a
naive calculation to check against IR examples I have to spend time
considering is the error due to the algorithm difference or due to faulty
input of tax rates or thresholds.

Most computers do not display x*y/z and x/z*y as different. Internally in
software it is a common error for incompetent programmers to check floating
point numbers for equality, the correct procedure is almost always to check
floating point numbers as being "equal" if their absolute difference is less
than a given small number.

I once had the joy of seeing a pedant like yourself trying to use
Fourth Shift integrated manufacturing software. Because Fourth Shift
is very large it has to aggressively conserve memory in its number
algorithms. Imagine this pedant's joy when he found that for "Shares
in group companies" he could choose from £1.99 or £2.01 but get no
closer than that!

I have no knowledge of Fourth Shift but this sounds like second rate
programming to me. "Aggressively conserve memory in its number algorithms"
sounds like the bullshit a company rep might try to sell someone gullible.

If the system only allowed approximate price specification it should have
explained exactly what the approximation was. If, as you imply, the problem
was due to a decimal conversion to binary the developers were idiots because
£2.01 is really an integer, 201 pence.

 

[Frank X]

But the point is it doesn't matter. £1.99 *IS* £2, £2.01 *IS* £2.

No its not.

If a number can be held in one byte, then doubling it to two bytes
will double every part of every calculation.

This isn't true almost all internal computer operations are done on 4 byte
or more blocks. Doing an operation on single byte numbers is more expensive
and slower than doing the same calculation on a 4 byte number.

 

[bobve]

hehehehhe

 

[bobve]

hehehehhe

 

[bobve]

hehehehhe

 

[bobve]

hehehehhe

 

[Matthew Church]

No its not.


This isn't true almost all internal computer operations are done on 4 byte
or more blocks. Doing an operation on single byte numbers is more expensive
and slower than doing the same calculation on a 4 byte number.

Depends how you define "byte". As a general rule the more detail there
is in a number, sound or picture the more memory it takes up and the
longer it takes to process.

So for quick processing and economical storage you want small numbers,
sounds and pictures. If you double the size of your numbers you can
store half as many of them, and they will take twice as long to
process.

And whatever you mean by "done on 4 byte or more blocks", make sure
you are being consistent with the 8080 processor which is where Fourth
Shift started, right through to the [insert word here] processor in
the year Fourth Shift will finish.

 

[Matthew Church]

£2.01 is really an integer, 201 pence.

But 201 exceeds 2 by a factor of 100. You want us to reduce our
capacity by 1/100th but still take 100 times longer to process it!

You seem to know what you are talking about, so answer me this:

1) What is the largest number you would allow as data in an accounting
package?
2) How long is that in binary/bytes?

 

[Tim]

But 201 exceeds 2 by a factor of 100. You want us to reduce our
capacity by 1/100th but still take 100 times longer to process it!

What on earth are you mumbling about? How would storing 201 pence instead
of £2.01 pounds ever "reduce our capacity by 1/100th"? And why on earth do
you think it would "take 100 times longer to process it"? You are surely a
mad-man.

1) What is the largest number you would allow as data in an accounting
package?

That might depend. In 32-bits you can store numbers up to over 2 billion (2
thousand million) - or 4 billion if you use the "sign" bit for data. That
may well be enough for most purposes, even in accounting.
For some large entities (corporations/governments), this may not be enough -
but using 64-bits will always be enough, even for very small currencies (eg
old lira) and for many years to come of inflation/growth (maximum number
then over 9,000 million billion - even without using the sign bit).

2) How long is that in binary/bytes?

Answered above.

 

[Tim]

Depends how you define "byte".

There is only one definition of "byte" - short for "by-eight" - and it is
8-bits.

Not so - see below.

As a general rule the more detail there
is in a number, sound or picture the more memory it takes up and the
longer it takes to process.
So for quick processing and economical storage you want small numbers,
sounds and pictures.

Only partly true.

If you double the size of your numbers you can
store half as many of them,

Correct! - for a change.

and they will take twice as long to
process.

Not true - as stated by others here, 32-bit data is processed quicker than
16-bit data.
Think about it this way. The processor works in 32-bit "chunks" (see
below). If you have 32-bit data, you simply:
1. Get the 32-bit data;
2. Process the 32-bit data;
3. Store the resulting 32-bit data.

Now, if you have 16-bit data, the processor will need to:
1. Get the 16-bit data;
2. Pad this data out to 32-bits, by setting the higher 16-bits to zero.
3. Process the 32-bit data;
4. Convert the resulting 32-bit data back to 16-bit data, by removing the
high-order 16-bits;
5. Store the final 16-bit data.

And whatever you mean by "done on 4 byte or more blocks", make sure
you are being consistent with the 8080 processor which is where Fourth
Shift started, right through to the [insert word here] processor in
the year Fourth Shift will finish.

*All* mainstream processors nowadays are 32-bit. They have been around for
well over a decade - which means that any computers left using 16-bit (or
8-bit!) processors are housed in museums!
OK, so Itanium is out - which uses 64-bits. But how many of these have been
manufactured so far, and how much do they cost? I rest my case!

 

[Clive George]

There is only one definition of "byte" - short for "by-eight" - and it is
8-bits.

Ob pedant - see the jargon file for a better definition.
http://www.catb.org/~esr/jargon/html/B/byte.html is where I saw it last.

cheers,
clive

 

[Frank X]

"Frank X" <[email protected]> wrote in message

But 201 exceeds 2 by a factor of 100. You want us to reduce our
capacity by 1/100th but still take 100 times longer to process it!

You seem to know what you are talking about, so answer me this:

1) What is the largest number you would allow as data in an accounting
package?
2) How long is that in binary/bytes?

Never written an accounting system as such. However for financial systems
use of double precision floating point numbers is almost universal.

*doubles* give about 15 significant figures and allow numbers in the range
+/- 1.7 * 10^+/-308.

The reason we use these for money instead of integer values is because we
do a lot of calculations with them, logs and division etc and it is easier
not to have to convert them to doubles the whole time. (which would be
required internally by the computer).

Also often the money amounts calculated are intermediate/notional and
better final results are obtained without rounding them to real money
integer values.

Modern computer Floating Point Units are also optimised to handle doubles,
it is possible smaller single (32 bit) floating point numbers might be
handled quicker but these would only be used in exceptional circumstances.

When writing systems we always have to take into account resources, space
and processing time as well as accuracy before we pick a data
representation.. Having said that almost everyone in finance now use doubles
;o)

I only suggested using integers in my earlier post because the inability to
represent 2.01 accurately meant that the system obviously already used non
standard numeric formats which presumably had to be converted before numeric
calculations could be carried out (efficiently) by the CPU..

 

[Clive George]

Never written an accounting system as such. However for financial systems
use of double precision floating point numbers is almost universal.

<gasp>

I've met people's code where they've done this. I've rewritten it too. It
worked much better afterwards.

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!

Modern computer Floating Point Units are also optimised to handle doubles,
it is possible smaller single (32 bit) floating point numbers might be
handled quicker but these would only be used in exceptional circumstances.

32 bit floats are almost as useless as 16 bit integers - 24 bits of accuracy
often isn't enough.

When writing systems we always have to take into account resources, space
and processing time as well as accuracy before we pick a data
representation.. Having said that almost everyone in finance now use doubles
;o)

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!

(1) Do you do things like the software for writing the pension forecasts?
I'd let that use doubles, but I'd expect the software that actually handles
my pension account to use integers.

cheers,
clive

 

[Tim]

Ob pedant - see the jargon file for a better definition.
http://www.catb.org/~esr/jargon/html/B/byte.html is where I saw it last.

Harummphhh!! Back when I did my 'O' levels (no, not GCSE's!) - we were
taught that "byte" meant 'by-eight' and was always 8-bits. A nybble was
4-bits. Has this changed also?

 

[Matthew Church]

So for quick processing and economical storage you want small numbers,
sounds and pictures. If you double the size of your numbers you can
store half as many of them, and they will take twice as long to
process.

Not true.

And whatever you mean by "done on 4 byte or more blocks", make sure
you are being consistent with the 8080 processor which is where Fourth
Shift started, right through to the [insert word here] processor in
the year Fourth Shift will finish.

(I bet their code no longer works on an 8080.)

I meant 8386. I am not so pedantic that I insist on getting every tiny
detail correct.

Provided that they're not stilll using the 8 or 16 bit processors, ie
they've noticed the 80386 arrived over 15 years ago, storing numbers in one
or two bytes _is_ inefficient - the 32 bit processors handle 32 bit numbers
fastest. They particularly prefer their data to be aligned on 4-byte
boundaries.

Presumably you're not a programmer, so you don't need to know such things.

clive

No I am the world's leading accountant. I did however translate The
Bible into Fortran as part of my IT thesis at Cambridge in 1986.

Start. Pop. Poke etc