On Mon, Oct 12, 2009 at 11:19 AM, Phil Ashby <phil.ashby@bt.com> wrote:

On Mon, 2009-10-12 at 11:08 +0100, Mark Rogers wrote:

...

Can anyone explain this code's output?

<?php     $x = (15/100) * 10.7;     $y = 1.605;     var_dump($x, $y, round($x,2), round($y,2),round(1.605,2)); ?>

Result:     float(1.605) float(1.605) float(1.6) float(1.61) float(1.61)

As you suspect, it's because 15/100 and 10.7 (and 1.605 infact) cannot be exactly represented in IEEE 784 format binary floating point. Thus the calculated value is very slightly below 1.605 and is thus rounded down whereas the constant 1.605 is very slightly above (this is just how the compiler chooses the represent the value of course) and gets rounded up.

Borland had a solution to this problem 25 years ago: they produced a version of Turbo Pascal that worked in binary coded decimal (BCD) instead of base 2, and thus has no problem with decimal representation or calculations. A similar solution is in use today in packages like Sage... perhaps you can find a BCD maths library or compiler switch?

I am so sorry, I did my replies straight to Mark and not to the group: You are absolutely correct, PHP's manual states quite clearly a warning for 0.7 in particular (http://us2.php.net/manual/en/language.types.float.php ) and gives a link to their higher precisions BC library: http://us2.php.net/manual/en/ref.bc.php Also I have suggested not using floats to represent currency instead representing by integer of lowest denomination (i.e. pence: $x = 10.7 * 100; $x = $x * .15 / 100; var_dump( round($x,2)); produces float(1.61) JT

Brett Parker wrote:

Can I make a simple suggestion...

Rather than doing the maths in the order that you have in $x do: $x = 10.7 * 15 * 0.01;

I.e. you're doing the division at the end, rather than the beginning, and so the float is "more accurate".

Ah, good point. That's probably why I don't see this all that often; I normally do things that way around for precisely that reason. Given that the price (10.7) will always be to a maximum of 2 decimal places, how confident can I be that I won't find other cases that fail even though this one now works? -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG

...

...

Can I make a simple suggestion...

Rather than doing the maths in the order that you have in $x do:     $x = 10.7 * 15 * 0.01;

I.e. you're doing the division at the end, rather than the beginning, and so the float is "more accurate".

I'm not sure this will always be true. If you separated it out and put brackets in then maybe you could force it. I'm not sure how PHP would interpret and its order of execution on these.

...

Ah, good point. That's probably why I don't see this all that often; I normally do things that way around for precisely that reason.

Of course you run the risk of going buffer *overflow* on the left - for very big shopping baskets of course!

Of course, I'm assuming that you're actually pulling these from a database engine, so you could just get that to do the maths... you shouldn't *ever* hardcode VAT rate (as Jenny found out with her invoicing system ;)

The only other suggestion I would have is why do you have the vat as a fraction (15/100) ? - if its a constant (which it is (bearing in mind iDunno's hardcode comment) wouldnt it be better to have it as 0.15 and :. reducing one calculation by the PHP? No ones said it yet, so I will. Use a different language!!! JT

This seems to work: function safe_round($x, $dp) { $x *= pow(10,$dp); $x = explode('.',(string)$x); $res = (int) $x[0]; if ( (count($x)>1) && ($x[1][0] >= 5) ) { $res++; } return $res/100; } In other words: safe_round(1.605,2) stepped through gives 1.605 * 10^2 = 160.5 160.5 => "160.5" => ("160","5") $res = 160 if something after "." and the first digit of that is 5 or higher (it is here): $res++ (=161) return $res/100 = 1.61 This relies on the fact that PHP seems to "work" when you convert the float to a string. Any reasons why this shouldn't work in general? ($x<0 would be a test case I haven't considered). -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG

On Mon, Oct 12, 2009 at 2:27 PM, Chris G <cl@isbd.net> wrote:

As a general point re this VAT rounding lark - the VAT rules say that you're allowed to *truncate* fractions of a penny.  In other words if the VAT on an item you sell is anywhere between (say) 95.00000001 pence and 95.99999999 pence then the amount you have to send the VAT man is 95p.

*Lots* of accounting packages don't follow this rule though, I regularly had to adjust my invoices when I was a contractor because the agency paid me 1p more than my (truncating) software said was due.

I am not a lawyer or accountant, but from google (and Ive pasted the section below).

From HMRC: http://customs.hmrc.gov.uk/channelsPortalWebApp/channelsPortalWebApp.portal?_nfpb=true&å=pageLibrary_ShowContent&id=HMCE_CL_001543&propertyType=document#P574_44405

I take this to mean you can do whatever you like as long as you're consistent - but you can only round down the TOTAL not the individual items (which might equate to more then a penny lost (consider 10 * 0.9p items = 0 p if rounded down separately and 9p if rounded at the end)) JT ----- Paste start ----- 17.5 Calculation of VAT on invoices – rounding of amounts Note: The concession in this paragraph to round down amounts of VAT is designed for invoice traders and applies only where the VAT charged to customers and the VAT paid to Customs and Excise is the same. As a general rule, the concession to round down is not appropriate to retailers, who should see paragraph 17.6. You may round down the total VAT payable on all goods and services shown on a VAT invoice to a whole penny. You can ignore any fraction of a penny. 17.5.1 Calculation based on lines of goods or services If you wish to work out the VAT separately for a line of goods or services, which are included with other goods or services in the same invoice, you should calculate the separate amounts of VAT either by rounding: down to the nearest 0.1p - for example, 86.76p would be rounded down to 86.7p; or to the nearest 1p or 0.5p - for example, 86.76p would be rounded up to 87p. Whatever you decide, you must be consistent. The final total amount of VAT payable may be rounded down to the nearest whole penny. 17.5.2 Calculation based on tax per unit or per article If you want to work out the VAT per unit or per article (for example, for use in price lists), you must work out the amounts of VAT either to: 4 digits after the decimal point and then round to 3 digits - for example, if the VAT is £0.0024, it should be rounded to £0.002 (0.2p); or the nearest 1p or 0.5p. If you decide to do this, you must not round the VAT down to “nil” on any unit or article that is liable at the standard or reduced rate - for example, if the VAT is £0.0024, it should be rounded to £0.005 (0.5p).

This may be irrelevant for the aqpplication being considered, but if things are being done on Linux there is the program 'bc', which does its arithmetic using an internal *decimal* representation, and to an arbitrary precision (truncating, rather than rounding, for the purpose of returning numbers to a given number of decimal disgits). You set the precision (number of digits after the decimal point) by giving a value to the 'scale' variable. Therefore I would expect that (given the VAT specification to work to 4 d.p.) you could use 'bc' with scale=5 or scale=6, and then doing a bit of extra tweaking to evaluate the rounded value. One more comment (on a point which does not seem to have been mentioned). "Rounding" is usually understood to mean "return the nearest "integer" at the right-hand end of the return range, so that (e.g.) round(1.234, 1) -> 1.2. round(1.234, 2) -> 1.23 round(1.23456, 2) -> 1.23 round(1.23456, 3) -> 1.235 But what about round(1.2345, 3)?? Is this 1.234 or 1.235? There are different conventions. A: Round "5" up: round(1.2345, 3) -> 1.235 round(1.2355, 3) -> 1.236 B: Round "5" down: round(1.2345, 3) -> 1.234 round(1.2355, 3) -> 1.235 C: Round "5" to the nearest *even* result: round(1.2345, 3) -> 1.234 round(1.2355, 3) -> 1.236 (You can never get an odd last digit with method C). This is the method of the IEC 60559 standard. The VAT rules seem to say that *any* fraction (in the final result) may be rounded down, though there seem to be ifs & buts about it! This is rounding by truncation (as also done in 'bc'). Just a few thoughts ... Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 12-Oct-09 Time: 15:15:28 ------------------------------ XFMail ------------------------------

Brett Parker wrote:

Well, how about giving a range that we can play in, and then I can tell you ;)

Well the site will sell products from a few pence up to a few hundred pounds, and people buy between one and several hundred items at a time. VAT is obviously within a fairly narrow range (15-17.5%).

Of course, I'm assuming that you're actually pulling these from a database engine, so you could just get that to do the maths... you shouldn't *ever* hardcode VAT rate (as Jenny found out with her invoicing system ;)

The problem I have is that I'm trying to fix one problem in a large system so I don't get to re-make initial design decisions like these, and no, at present these are not coming directly from a database. VAT is not hardcoded, and the system doesn't even assume that the number of decimal places is always going to be 2 (which is part of the problem - if it were always 2 then making a design decision to doing everything in pence/cents would probably have been made by the original developers). The cart I'm working with (ZenCart) has some very weird and wonderful ideas when it comes to calculating the total of a shopping cart (particularly when discounts come into play). I'd dearly like to be in a position to rewrite it! -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG

2009/10/12 Brett Parker <iDunno@sommitrealweird.co.uk>:

Of course, I'm assuming that you're actually pulling these from a database engine, so you could just get that to do the maths... you shouldn't *ever* hardcode VAT rate (as Jenny found out with her invoicing system ;)

Pah, it had been the same for donkey's years: they changed it just to spite me. Jenny