|
|
Post by chris on Sept 11, 2015 12:46:49 GMT
It's a fixed precision numeric field, not floating point or binary fraction. It's guaranteed accuracy to that precision. See the numeric data type here. For display this is sometimes converted into a float, but anywhere important we use numeric or an equivalent in other programming languages. Wow. I work in trading systems and double precision or F64 has always been good enough for the bank. But I guess at a bank, at the end of each day, settlement money has to pass between the IB and a counterparty and that has to be in pounds and pence (or equivalent) and the transaction is finished but AC doesn't have that luxury, it has to keep adding fractional parts to other fractional parts over a period of years. I don't envy you that task. The obvious question is why 40 digits? Seemed like a nice number and is the same precision we store people's fractional holdings of a loan. There'll be a few digits of error simply because decimals can't handle every fraction and we have to convert from fraction of a loan into a monetary value in a few places, so if that's something in the region of 10^-34 or so then either as a fraction of a loan or a fraction of a pound that's a small enough number to not be significant to lender's return.
|
|
tonyr
Member of DD Central
Posts: 477 
Likes: 258
|
Post by tonyr on Sept 12, 2015 18:00:18 GMT
I fully understand the issues of rounding for display but I find it difficult to believe AC are using a storage type that can hold numbers to this level of accuracy. Is it quad float or F128? Because if it's not, at least half of the digits displayed are just garbage or noise. It's a fixed precision numeric field, not floating point or binary fraction. It's guaranteed accuracy to that precision. See the numeric data type here. For display this is sometimes converted into a float, but anywhere important we use numeric or an equivalent in other programming languages. So for fixed precision are you using "decimal variable user-specified precision, exact up to 131072 digits before the decimal point; up to 16383 digits after the decimal point"? Whatever you've used when it gets displayed there are a load of zeros at the end before something that looks like a floating point rounding error. Here are some examples: 1.9323076923076923076900000000000000000000 2.7777777777777777777699999999999999750000 78.1587177519296903598063000000000000000000 478.1587177519296903598158000000000000000000 3.4643333333333333333300000000000000000000 1.9018518518518518518599999999999999920000 This is a technical issue but us techies care about this. This is an A level mistake and not hard to fix. personally I think that four decimal places is absolute fine - you have to add a lot of stuff up to make sure you haven't lost as much as 1p,
|
|
oldgrumpy
Member of DD Central
Posts: 5,087
Likes: 3,233
|
Post by oldgrumpy on Sept 12, 2015 18:15:27 GMT
....personally I think that four decimal places is absolute fine - you have to add a lot of stuff up to make sure you haven't lost as much as 1p...
Me too. Whatever AC is doing behind the scenes to comply with all accounting regulations, 4dp is perfectly adequate for display purposes, and they shouldn't have to waste time explaining and arguing on this or any other forum the ins and outs of twenty or thirty or forty decimal places. For those who must see them, I'm trying to think of a suggestion regarding where AC could stick all those extra digits ..... Ummmm!
|
|
|
|
Post by chris on Sept 12, 2015 19:40:51 GMT
It's a fixed precision numeric field, not floating point or binary fraction. It's guaranteed accuracy to that precision. See the numeric data type here. For display this is sometimes converted into a float, but anywhere important we use numeric or an equivalent in other programming languages. So for fixed precision are you using "decimal variable user-specified precision, exact up to 131072 digits before the decimal point; up to 16383 digits after the decimal point"? Whatever you've used when it gets displayed there are a load of zeros at the end before something that looks like a floating point rounding error. Here are some examples: 1.9323076923076923076900000000000000000000 2.7777777777777777777699999999999999750000 78.1587177519296903598063000000000000000000 478.1587177519296903598158000000000000000000 3.4643333333333333333300000000000000000000 1.9018518518518518518599999999999999920000 This is a technical issue but us techies care about this. This is an A level mistake and not hard to fix. personally I think that four decimal places is absolute fine - you have to add a lot of stuff up to make sure you haven't lost as much as 1p, That's not a floating point error, that's a decimal fraction error. Remember loan holdings are stored as a fraction of the loan total. So if you have £100 invested in a £100,000 you have 0.1% of the loan or 0.001 as a decimal fraction. When buying or selling that then needs to be converted back into a £ value so gets multiplied out by the principal remaining. That's fine for nice round numbers but if you have a £37 holding in a £450k loan then the fractions will not necessarily fit nicely into a decimal representation, especially with amortised loans that have a non-round denominator. No A level mistakes or floating point errors. Simply a reflection that some fractions can't be represented cleanly by decimal notation even to 40 decimal places.
|
|
skippyonspeed
Some people think I'm a little bit crazy, but I know my mind's not hazy
Posts: 787
Likes: 424
|
Post by skippyonspeed on Sept 13, 2015 5:10:06 GMT
At the moment it appears that it is impossible to sell a complete holding in a loan as one will be left with all the odd fractions. Under the old system you could just set your target to 0. There was also an "Opt Out" option which I assume did the same thing as I never used it. Perhaps a "Sell All" option could be added to overcome this problem
|
|
|
|
Post by chris on Sept 13, 2015 5:20:45 GMT
At the moment it appears that it is impossible to sell a complete holding in a loan as one will be left with all the odd fractions. Under the old system you could just set your target to 0. There was also an "Opt Out" option which I assume did the same thing as I never used it. Perhaps a "Sell All" option could be added to overcome this problem In the old system it would also leave you with fractions as you could only sell whole pence. Sometimes you were lucky and the system rounded it up if it was nearly a whole penny but there's plenty of odd fractions lying around. Now you can sell any fraction. It you sell instruction just set it for 1p more than your holdings and it will sell that last fraction. We'll come up with a tidier way of specifying "everything".
|
|
|
|
Post by chielamangus on Sept 13, 2015 11:23:00 GMT
So this is what you call a holiday, chris? What does your long-suffering wife have to say? Get down to the sea with that toddler of yours and forget AC for a few days, FGS. The AC ship won't capsize just because you are not in contact for a few days. Let the underlings step into the breach! |
|
tonyr
Member of DD Central
Posts: 477
Likes: 258
|
Post by tonyr on Sept 13, 2015 14:28:48 GMT
So for fixed precision are you using "decimal variable user-specified precision, exact up to 131072 digits before the decimal point; up to 16383 digits after the decimal point"? Whatever you've used when it gets displayed there are a load of zeros at the end before something that looks like a floating point rounding error. Here are some examples: 1.9323076923076923076900000000000000000000 2.7777777777777777777699999999999999750000 78.1587177519296903598063000000000000000000 478.1587177519296903598158000000000000000000 3.4643333333333333333300000000000000000000 1.9018518518518518518599999999999999920000 This is a technical issue but us techies care about this. This is an A level mistake and not hard to fix. personally I think that four decimal places is absolute fine - you have to add a lot of stuff up to make sure you haven't lost as much as 1p, That's not a floating point error, that's a decimal fraction error. Remember loan holdings are stored as a fraction of the loan total. So if you have £100 invested in a £100,000 you have 0.1% of the loan or 0.001 as a decimal fraction. When buying or selling that then needs to be converted back into a £ value so gets multiplied out by the principal remaining. That's fine for nice round numbers but if you have a £37 holding in a £450k loan then the fractions will not necessarily fit nicely into a decimal representation, especially with amortised loans that have a non-round denominator. No A level mistakes or floating point errors. Simply a reflection that some fractions can't be represented cleanly by decimal notation even to 40 decimal places. It still looks like quoting far more digits than the floating point precision to me. Take this example from today: Sale of loan part 13257442 (new id 13259335) for 101.0101010101010101010100000000000000000000 GBP with a 1% Discount (99.9999999999999999999999000000000000000000 GBP paid) - fee 0 GBP, annualised rate 10, loan: Midlands Trade Finance Provider Loan (104)
I wanted to sell £100 exactly at 1% discount, so someone else gets 101.01010101010101010101 to within the precision of 64 bit floating point (I presume) and this gets converted back to me receiving £99.9999999999999999999999. If you want about 50 digits of accuracy then all intermediate calculations have to be done to that accuracy as well, if you are going to do them as doubles then they shouldn't be displayed with spurious accuracy. But I'm taking your time on some non-urgent matter when you should be on holiday - sorry.
|
|
mikes1531
Member of DD Central
Posts: 6,453
Likes: 2,320
|
Post by mikes1531 on Sept 13, 2015 15:10:03 GMT
I haven't worked out why AC decided to presume that when a lender says they want to buy £100 of a loan, and there happens to be parts available for a 1% discount the system buys £101.01.01.01... of the loan for £100. Wouldn't it have been simpler to buy exactly £100 of the loan for exactly £99?
If I have £500 of a loan and I want to increase my holding I'd expect an instruction to buy £100 would bring my holding to £600. Is that an unreasonable expectation?
|
|
|
|
Post by chris on Sept 13, 2015 15:19:06 GMT
I haven't worked out why AC decided to presume that when a lender says they want to buy £100 of a loan, and there happens to be parts available for a 1% discount the system buys £101.01.01.01... of the loan for £100. Wouldn't it have been simpler to buy exactly £100 of the loan for exactly £99? If I have £500 of a loan and I want to increase my holding I'd expect an instruction to buy £100 would bring my holding to £600. Is that an unreasonable expectation? The reason is that the system will buy at better discounts as well, so if you've set aside £100 for a loan and there are some loan units available with a 2% discount then you're still investing your £100. Likewise when you set it so that you're happy to pay a premium that will also stop you over spending. I'm sure you'd grumble if the system spent £101 against your £100 target. This is also the same methodology used in buy / sell orders with shares (or so I'm told by my fellow directors), so should be familiar to those already used to thinking that way.
|
|
|
|
Post by chris on Sept 13, 2015 15:29:16 GMT
That's not a floating point error, that's a decimal fraction error. Remember loan holdings are stored as a fraction of the loan total. So if you have £100 invested in a £100,000 you have 0.1% of the loan or 0.001 as a decimal fraction. When buying or selling that then needs to be converted back into a £ value so gets multiplied out by the principal remaining. That's fine for nice round numbers but if you have a £37 holding in a £450k loan then the fractions will not necessarily fit nicely into a decimal representation, especially with amortised loans that have a non-round denominator. No A level mistakes or floating point errors. Simply a reflection that some fractions can't be represented cleanly by decimal notation even to 40 decimal places. It still looks like quoting far more digits than the floating point precision to me. Take this example from today: Sale of loan part 13257442 (new id 13259335) for 101.0101010101010101010100000000000000000000 GBP with a 1% Discount (99.9999999999999999999999000000000000000000 GBP paid) - fee 0 GBP, annualised rate 10, loan: Midlands Trade Finance Provider Loan (104)
I wanted to sell £100 exactly at 1% discount, so someone else gets 101.01010101010101010101 to within the precision of 64 bit floating point (I presume) and this gets converted back to me receiving £99.9999999999999999999999. If you want about 50 digits of accuracy then all intermediate calculations have to be done to that accuracy as well, if you are going to do them as doubles then they shouldn't be displayed with spurious accuracy. But I'm taking your time on some non-urgent matter when you should be on holiday - sorry. We're not using floating point maths anywhere in the trading algorithms - great care is used to avoid this, with the database only using numeric types, numbers being sent too / from the database as text strings, and an arbitrary precision library being used for the non-database based routines. Being on holiday I'm not going to look into the specifics but what is probably happening is that it's trying to buy / sell £100 but when that gets converted into a fraction of the loan to buy that fraction is ever so slightly out. We then multiply the actual fraction back out to get the true amount the buyer should pay (in case the amount requested exceeds the amount for sale or is otherwise truncated). The inaccuracy will be introduced from one of these calculations.
|
|
|
|
Post by bracknellboy on Sept 13, 2015 16:06:57 GMT
I haven't worked out why AC decided to presume that when a lender says they want to buy £100 of a loan, and there happens to be parts available for a 1% discount the system buys £101.01.01.01... of the loan for £100. Wouldn't it have been simpler to buy exactly £100 of the loan for exactly £99? If I have £500 of a loan and I want to increase my holding I'd expect an instruction to buy £100 would bring my holding to £600. Is that an unreasonable expectation? As currently worded on the UI, your instruction to the system is to 'Invest' a £100 of your money in the loan, at discount/premium within your bounds; it is not a request to buy £100's worth based on par value. It would be more obtuse / non-intuitive / down right misleading for it to then go and under or over invest based on parts at premium/discount. Whether one likes the 'new' way of placing effective buy/sell orders on the system or not, the above is surely the only behaviour which is internally consistent ?
|
|
mikes1531
Member of DD Central
Posts: 6,453
Likes: 2,320
|
Post by mikes1531 on Sept 13, 2015 16:07:39 GMT
If I have £500 of a loan and I want to increase my holding I'd expect an instruction to buy £100 would bring my holding to £600. Is that an unreasonable expectation? I'm sure you'd grumble if the system spent £101 against your £100 target. Not if I said I was willing to pay a 1% premium. This is also the same methodology used in buy / sell orders with shares (or so I'm told by my fellow directors), so should be familiar to those already used to thinking that way. My broker gives me a choice. I can either say I want to invest £XXX and the number of shares I buy will depend on the price at the time I buy. Or I can say I want to buy NNN shares, and the actual amount I pay will vary depending on the actual share price. I always use the latter method, because I prefer to hold round numbers of shares. Some of that preference is due to concerns that may no longer be issues. Share price executions used to be at higher prices and commissions used to be higher when buying non-round numbers of shares. I may just be showing my age! 
|
|
|
|
Post by chris on Sept 13, 2015 16:20:47 GMT
mikes1531 - I can understand it being interpretable either way. I think for now it's more intuitive than with the suggested methodology but perhaps in a future release I can include an advanced option which lets you choose.
|
|
|
|
Post by jevans4949 on Sept 15, 2015 10:38:13 GMT
chris: Can you fix it so that I can shift the £0.0057... from my cash account to my MLIA (or other investment account)? Maybe if the available balance is short of the requested transfer by less than 1p, then transfer the whole balance? Not earth-shattering, just annoying.
|
|
