Well, bank manager came in today for a chat (nice when they come to you) and was saying how someone he knows directly spent the night at hospital because her son was victim of an attack on a train related to these riots... Apparently a bunch of yoofs went along the whole train with baseball bats or some such.
Funny how things like this find a way of connecting with you somehow.
Given my usual interest in news, it was not until I read about the riots on the uknot mailing list today that I knew this was happening at all.
2011-08-09
2011-08-08
Money making machine
I really do wonder if there should be a stupidity tax some times...
OK, when people pay us, just like every other utility, we need a payment with the right sort-code, account number and reference. Bog standard stuff - same for gas, electric, water, telephone, tax, vat, everything. The beneficiary reference is part of the BACS (Bankers Automated Clearing System) that has been around a long time and is an 18 character string that you need to quote on the payment for the beneficiary (person getting the money) to be able to work out what it is for.
Yes, paying money to a mate - the reference does not matter - but paying your VAT bill? They need to know your VAT number as a reference...
We have a simple system - pay us with your account number, e.g. A12345A on the reference. We automatically allocate it to the right account. No human intervention required. When you have thousands of people paying you - you need a simple automated system.
Now, some people pay with the wrong reference. It happens. People make mistakes. How they pay anyone else right, I don't know. They just make up crap. Sometimes we'll get a payment from "CURRENT ACCOUNT" with reference "BROADBAND" for £19.40 - WTF are we meant to do with that?
And then people post a remittance advice, like that helps anyone...
So, we try to be nice. If we can work out manually who it is then we send a nice letter asking them to put the right reference. Then next time a less nice one pointing out it is actually part of the terms to put the right reference. Finally one explaining that if they really won't put the right reference then there is a £5+VAT admin fee for us manually allocating it. Of course if we can't allocate the payment someone just gets a £40 late payment penalty instead as we did not know they had paid - we credit that and start the nice letters when they eventually complain.
But what the hell do you do with special people that insist on paying you with no reference over and over and over again? They then get an invoice for £6 (£5+VAT) for an admin fee for paying without a reference, and pay the £6, by BACS, without the right reference. Wha?!?!??
This is, for amusement, a government department. But it sounds like we have a hands off money making machine. Every time they pay £6 we can charge them £6 admin fee for paying without the right reference. Rinse, repeat.
Never once had a sensible explanation from anyone that does this.
P.S. We do try and avoid this by including the £6 in the next invoice, so they don't pay it separately. But quarterly billed customers get it separately as the system does not like any debt un-invoiced for more than a month, which seems fair enough to me.
OK, when people pay us, just like every other utility, we need a payment with the right sort-code, account number and reference. Bog standard stuff - same for gas, electric, water, telephone, tax, vat, everything. The beneficiary reference is part of the BACS (Bankers Automated Clearing System) that has been around a long time and is an 18 character string that you need to quote on the payment for the beneficiary (person getting the money) to be able to work out what it is for.
Yes, paying money to a mate - the reference does not matter - but paying your VAT bill? They need to know your VAT number as a reference...
We have a simple system - pay us with your account number, e.g. A12345A on the reference. We automatically allocate it to the right account. No human intervention required. When you have thousands of people paying you - you need a simple automated system.
Now, some people pay with the wrong reference. It happens. People make mistakes. How they pay anyone else right, I don't know. They just make up crap. Sometimes we'll get a payment from "CURRENT ACCOUNT" with reference "BROADBAND" for £19.40 - WTF are we meant to do with that?
And then people post a remittance advice, like that helps anyone...
So, we try to be nice. If we can work out manually who it is then we send a nice letter asking them to put the right reference. Then next time a less nice one pointing out it is actually part of the terms to put the right reference. Finally one explaining that if they really won't put the right reference then there is a £5+VAT admin fee for us manually allocating it. Of course if we can't allocate the payment someone just gets a £40 late payment penalty instead as we did not know they had paid - we credit that and start the nice letters when they eventually complain.
But what the hell do you do with special people that insist on paying you with no reference over and over and over again? They then get an invoice for £6 (£5+VAT) for an admin fee for paying without a reference, and pay the £6, by BACS, without the right reference. Wha?!?!??
This is, for amusement, a government department. But it sounds like we have a hands off money making machine. Every time they pay £6 we can charge them £6 admin fee for paying without the right reference. Rinse, repeat.
Never once had a sensible explanation from anyone that does this.
P.S. We do try and avoid this by including the £6 in the next invoice, so they don't pay it separately. But quarterly billed customers get it separately as the system does not like any debt un-invoiced for more than a month, which seems fair enough to me.
2011-08-05
The new PC term for "Jobsworth"..
Is "Hard turn back policy".
Anyone using BT for broadband repair will be well aware of this.
Anyone using BT for broadband repair will be well aware of this.
GMT and BST
Our favourite telco make use of microsoft tools to arrange calls and meetings.
It is now A&A company policy that if we get an invite to a conference call or a meeting that says, for example :-
When: 08 August 2011 11:00-12:00 (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London.
We are to take it at face value, in that case 12pm local time (BST). Especially if the email has the caveat :-
Note: The GMT offset above does not reflect daylight saving time adjustments.
Which makes it very very clear they really do mean GMT and not local time that would reflect local daylight savings time adjustments.
(unless the meeting or call is for our benefit not theirs, obviously).
Why do big corporates like BT plc not refuse to pay microsoft until they fix this simple buglet? I would if I used microsoft...
What amazes me is that the "Note: The GMT offset above does not reflect daylight saving time adjustments." is clearly new and somehow an attempt to address the error but, in my view, just makes it worse by making it clear you really did mean GMT!
It is now A&A company policy that if we get an invite to a conference call or a meeting that says, for example :-
When: 08 August 2011 11:00-12:00 (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London.
We are to take it at face value, in that case 12pm local time (BST). Especially if the email has the caveat :-
Note: The GMT offset above does not reflect daylight saving time adjustments.
Which makes it very very clear they really do mean GMT and not local time that would reflect local daylight savings time adjustments.
(unless the meeting or call is for our benefit not theirs, obviously).
Why do big corporates like BT plc not refuse to pay microsoft until they fix this simple buglet? I would if I used microsoft...
What amazes me is that the "Note: The GMT offset above does not reflect daylight saving time adjustments." is clearly new and somehow an attempt to address the error but, in my view, just makes it worse by making it clear you really did mean GMT!
2011-08-04
Polygon library working?
A TARDIS does not break it, and neither does a DALEK. Sadly I can still break it with my coffee machine hopper extension - so some bug still lingering. However, it is usable now... I'll publish it when I have the last bug found :-)
Now, why was it so hard?
1. Odd/even vs winding number.
Getting the original design right was tricky. What should it actually do? Even when you know you want a polygon library you do not necessarily know what the spec is. The main issue is how you handle holes. Basically, there are two approaches - something one can see in the postscript language even. If you walk from infinity over the shape, you can consider each line you meet as an edge, i.e. inside, outside, inside, outside, etc... This is odd/even logic. In this case the direction of each line is unimportant. Alternatively you can have a counter, starting at zero, and count each line you passed which is going to your left is plus one and each line going to your right is minus one. When the counter is non zero you are inside. This second approach is winding number logic. To me it seems much more logical so that is what I went for.
However, even with winding number logic you have to think. I just said any non-zero is inside, which is what postscript does. But what happens if you do something to a shale that makes it self intersect or even turn inside out.
Above is an example of a simple shape. A is what you started with. B is inset a bit. C is inset more - see how part of the shape has turned inside out. D is what you wanted - the inside out bit removed. To fix this you do winding number logic but only consider positive number as inside. Negative winding number are thrown away.
In fact the whole logic for basic intersect and union type operation works well with winding number. Union is just keeping all winding number 1 or above. Intersect is keeping winding number 2 or above. You can use it on one polygon to clean up things like this going inside out issue. You could use on more than two polygons at once even.
So, this makes winding number definitely the right way to do it. Else you have lots of other problems to sort out. This is, I believe, the key difference to the general clipper library that I looked at originally. Interestingly Cliff's idea at the beer festival was to have a separate function to simplify each polygon and then have Boolean operation functions which work on two polygons that you know are cleaned up like this. That would work, of course, but is a totally different approach.
2. Floating point numbers.
I coded this all with a typedef for the co-ordinate system, so I could change later. I just knew floats would bite me, but given machines have floating point hardware I thought I would try. Yes, as expected it bit me. Whilst comparison of floats was not the issue as such, there were problems where line intersection logic would happily decide to slice 10^-18mm off a line repeatedly. I am sure it would have finished eventually, but was due to the unit steps of floats and in particular the fact the two floats can have different intervals as different magnitudes. In the end, I simply changed to 64 bit integer which for my 3D stuff I am doing as micrometres. That also made it a lot faster as it happens.
3. Intersection logic.
One issue I then seem to have is that when you break a line because you have decided it intersects another line, you change it. This is made worse in some ways by use of integer maths. Basically, the break point is not going to be exactly on the line - it will be the nearest whole co-ordinate. This should not be an issue as obviously both ends move to the same point. The problem is that intersections you have already checked (off to the left) may change because the angle of the line you have just split has changed. An obscure edge case, but it happened. It meant that the segments needed re-checking as you could end up with self intersecting results. I initially solved most of these simply by making sure the X/Y intersect point was rounded to nearest whole number, not just truncated, but even then it still breaks with some shapes (not surprised). Now I just run the intersect checking code again until no more line segments are chopped up. That got pretty much everything working. I am trying to see if I can improve that.
4. Final bug
Well, I still have one test case breaking it - I need to figure that out. It is clearly even more of an edge case as quite complex shapes (like TARDIS and DALEK) are just working now. Should be easy to track down I am sure.
However, now I can actually get the output, I can continue on the original challenge - new 3D libraries. I can see my inset algorithm is breaking with some shapes so that needs fixing. Then I have new challenges with working out the extrude path and filling over open space, and all sort... But that should be fun, and a lot easier with a working polygon library...
Now, why was it so hard?
1. Odd/even vs winding number.
Getting the original design right was tricky. What should it actually do? Even when you know you want a polygon library you do not necessarily know what the spec is. The main issue is how you handle holes. Basically, there are two approaches - something one can see in the postscript language even. If you walk from infinity over the shape, you can consider each line you meet as an edge, i.e. inside, outside, inside, outside, etc... This is odd/even logic. In this case the direction of each line is unimportant. Alternatively you can have a counter, starting at zero, and count each line you passed which is going to your left is plus one and each line going to your right is minus one. When the counter is non zero you are inside. This second approach is winding number logic. To me it seems much more logical so that is what I went for.
However, even with winding number logic you have to think. I just said any non-zero is inside, which is what postscript does. But what happens if you do something to a shale that makes it self intersect or even turn inside out.
Above is an example of a simple shape. A is what you started with. B is inset a bit. C is inset more - see how part of the shape has turned inside out. D is what you wanted - the inside out bit removed. To fix this you do winding number logic but only consider positive number as inside. Negative winding number are thrown away.
In fact the whole logic for basic intersect and union type operation works well with winding number. Union is just keeping all winding number 1 or above. Intersect is keeping winding number 2 or above. You can use it on one polygon to clean up things like this going inside out issue. You could use on more than two polygons at once even.
So, this makes winding number definitely the right way to do it. Else you have lots of other problems to sort out. This is, I believe, the key difference to the general clipper library that I looked at originally. Interestingly Cliff's idea at the beer festival was to have a separate function to simplify each polygon and then have Boolean operation functions which work on two polygons that you know are cleaned up like this. That would work, of course, but is a totally different approach.
2. Floating point numbers.
I coded this all with a typedef for the co-ordinate system, so I could change later. I just knew floats would bite me, but given machines have floating point hardware I thought I would try. Yes, as expected it bit me. Whilst comparison of floats was not the issue as such, there were problems where line intersection logic would happily decide to slice 10^-18mm off a line repeatedly. I am sure it would have finished eventually, but was due to the unit steps of floats and in particular the fact the two floats can have different intervals as different magnitudes. In the end, I simply changed to 64 bit integer which for my 3D stuff I am doing as micrometres. That also made it a lot faster as it happens.
3. Intersection logic.
One issue I then seem to have is that when you break a line because you have decided it intersects another line, you change it. This is made worse in some ways by use of integer maths. Basically, the break point is not going to be exactly on the line - it will be the nearest whole co-ordinate. This should not be an issue as obviously both ends move to the same point. The problem is that intersections you have already checked (off to the left) may change because the angle of the line you have just split has changed. An obscure edge case, but it happened. It meant that the segments needed re-checking as you could end up with self intersecting results. I initially solved most of these simply by making sure the X/Y intersect point was rounded to nearest whole number, not just truncated, but even then it still breaks with some shapes (not surprised). Now I just run the intersect checking code again until no more line segments are chopped up. That got pretty much everything working. I am trying to see if I can improve that.
4. Final bug
Well, I still have one test case breaking it - I need to figure that out. It is clearly even more of an edge case as quite complex shapes (like TARDIS and DALEK) are just working now. Should be easy to track down I am sure.
However, now I can actually get the output, I can continue on the original challenge - new 3D libraries. I can see my inset algorithm is breaking with some shapes so that needs fixing. Then I have new challenges with working out the extrude path and filling over open space, and all sort... But that should be fun, and a lot easier with a working polygon library...
Our favourite telco refusing to fix faults again
Well, it seems they are refusing to fix faults unless we start using their "eco plus" web based portal to progress any fault.
They have confirmed through their text chat interface, a separate phone call to an support desk operator, and (after over half an hour on this on the phone) with their supervisor. So this is clearly not just a matter of one confused operative - but a clear change of policy. Oddly we did not see the briefing on this.
They are point blank refusing to do anything with a fault, and claim that it is their official policy that we have to use eco plus and has been so for at least six months.
Sadly, this means finding windows machines, and I think even older versions of IE, in order to use it. That would be both expensive and a huge change for the company to start using Windows machines.
Seems a complete waste of months of development to get their B2B XML interface working if we now have to get windows machines and use a web portal.
They have confirmed through their text chat interface, a separate phone call to an support desk operator, and (after over half an hour on this on the phone) with their supervisor. So this is clearly not just a matter of one confused operative - but a clear change of policy. Oddly we did not see the briefing on this.
They are point blank refusing to do anything with a fault, and claim that it is their official policy that we have to use eco plus and has been so for at least six months.
Sadly, this means finding windows machines, and I think even older versions of IE, in order to use it. That would be both expensive and a huge change for the company to start using Windows machines.
Seems a complete waste of months of development to get their B2B XML interface working if we now have to get windows machines and use a web portal.
2011-08-02
Beer mat logic
Well, the polygon library has been through a lot, and still remains "almost working", which is about as useful as "not working at all". Once again I can see the light at the end of the tunnel and once again it looks quite a long way off.
So, again, rather than plough ahead in to a complicated final solution I am going to try and sort this with a tried and trusted technique, usually involving pens and beer mats.
In practice the plan is to take some paper and pens along rather than actually use beer mats. I may have to find paper with a square grid on it. But the venue should be appropriate as it is the Great British Beer Festival in Earl's Court, tomorrow afternoon.
I suspect I will get lots of helpful advice from my friends on this problem and I am sure a lot of squiggly lines will be drawn...
So, again, rather than plough ahead in to a complicated final solution I am going to try and sort this with a tried and trusted technique, usually involving pens and beer mats.
In practice the plan is to take some paper and pens along rather than actually use beer mats. I may have to find paper with a square grid on it. But the venue should be appropriate as it is the Great British Beer Festival in Earl's Court, tomorrow afternoon.
I suspect I will get lots of helpful advice from my friends on this problem and I am sure a lot of squiggly lines will be drawn...
Subscribe to:
Posts (Atom)
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
This is an appeal for (sensible) comments. I am working on revised A&A tariffs for broadband. For those that are not sure how they wor...