Randomness in move selection
Robert Hyatt
Chris Whittington (chr...@cpsoft.demon.co.uk) wrote:
: Simon Read <bbr...@ftc.gov> wrote:
: >
: > Simon Read <s.read@ cran ffffield.ca.ku>
: > SR> May I ask, Chris, if different root moves have different random
: > SR> values passed to them and subsequently to their trees, and if
: > SR> so, how transpositions are dealt with?
: > -->
: > CW: Chris Whittington <chr...@cpsoft.demon.co.uk>
: > CW> This thread is madness.
: > CW> Everybody (mostly) is talking at cross purposes
: > CW> Nobody (mostly) is listening.
: > CW> Stuff that gets posted doesn't get read (mostly).
: > -->
: > See, Vincent? Now I'm talking to myself! I'm replying to my own
: > postings! Madness indeed!
:
: Ok, I can see you'ld read the comments above as directed at SR.
: That wasn't intended. It was almost the entire thread and many postings
: that I was grumbling about, no one specific.
:
: >
: > CW> You store the score minus the random value for that branch.
: > CW> When reading the hash, you read the stored score and add the
: > CW> random value for that branch.
: > CW>
: > CW> So the hash contains scores without no random value contained within.
: > -->
: > Yes, yes, yes, yes. I understand this. Now, we come to the half-better
: > algorithm. It's got some scores from somewhere else in the tree,
: > perturbed by the diseased mind of the programmer.
: > So it will occasionally fail high if the move is close, and it will
: > occasionally fail low when it shouldn't, meaning an almost-best
: > move will sometimes get there instead of the un-perturbed best move.
However, the above is still *wrong*. You say that as though every position
has a "score" stored. That's incorrect. 99.999% of the positions have a
"bound" stored rather than a score. You can't just add and subtract things
at random from this bound...
:
: That's right. And was the original idea - it means that 'several'
: moves might be available to become best rather than just one.
:
: And it also means that there is *no* hash table strange behaviour
: as previously alleged.
You need to first *implement* it, before making this claim. I don't
see how you can avoid odd behavior...
:
: >
: > ( I still think that adding a small _consistent_ random value to the
: > evaluation function is a simpler way, and even has advantages. )
: >
: > I think the only way for this to be solved is for a couple of different
: > methods to be implemented in a program, so that we can compare speed
: > and quality of play of the results. This might address one argument
: > which has been advanced, saying that subsequent re-searches would be
: > more frequent, costing some time.
:
: This is the remaining canard.
: There is *no* time penalty.
:
: Just for the moment suspend disbelief and treat the
: random value, not as garbage, but as a 'knowledge' value.
:
: Just to help, isn't a O-O bonus rather like this, especially if
: O-O takes place at ply 1, and *early* castling is prefered ?
I don't know of anyone that would try this, because it is a "known
no-no". The transposition table does not hold "path" information, only
"position" information. If you try to do this, you are guaranteed to get
oddball behavior, because when you *search* a position you know whether
you castled early or not, but when you reach a hashed position, you have
no clue about the path below that hashed position. Hence random side-effects
that simply don't cut it...
:
: So why should knowledge addition increase the search time ?
:
:
: Or look at it yet another way:
: Does good knowledge speed the search or slow it ?
: Does bad knowledge ... ditto ... ?
The only thing that will hurt the search is if the randomness makes the
program "change its mind" during the search, where it would not without the
randomness. If this happens, there's a huge performance penalty. If you
try adding scores to the root, you will break the hashing algorithm and have
problems there instead...
:
: OK, if there is *no* knowledge at all then the search will be
: extremely fast (the first move generated each time will be best,
: since all moves will give the same score). So addition of knowledge
: from a base of zero slows the search. But once there is a degree of
: variance in the scores, why should changing the elements of that
: variance make any difference to search time ?
:
: The search process is, by and large, independant of its domain.
: In other words the search doesn't care if the game is chess or
: tic-tac-toe or whatever. I think this means that the search is
: non value-judgemental with regard to the objective good/bad nature
: of the knowledge. As long as the knowledge elements
: are applied consistently, all the search does is build the tree
: as 'designed' by the knowledge. There is no reason to assume that
: the tree sizes will be influenced by the nature of the knowledge. Is
: there ?
:
: I'ld agree that if the evaluation function just threw random values
: at each node, then chaos would ensue. But the key is the *consistent*
: nature of the randomness. If consistent, the search will just see
: the random value as a piece of knowledge, hence no time penalty.
:
: There is, of course, a penalty to consistent randomness. Its called
: increasing the chances of playing weaker moves. But its not a time
: penalty.
:
:
: Chris Whittington
:
: >
: > Simon
: >
: > If you're a human being with a modicum of intelligence, I can be reached at
: > "ac cranfield read s uk" but in this order: s(dot)r_(at)c_(dot)a_(dot)u_
: > Robots beware! Sending advertising email to the address in the header of this
: > posting will get you into a _lot_ of trouble, ha ha ha!!!!
: >
:
Robert Hyatt
Dan Oetting (oet...@gldfs.cr.usgs.gov) wrote:
: Randomization of root ply. 20 test positions were searched for 3 minutes
: each with randomization off and +/- 5 centipawns. The last ply completed
: in both runs is compared. This sample test shows a 3.2% average increase
: in the nodes searched and almost 6% increase in time to reach the common
: ply when randomization was on. The worst case shows both nodes and time
: nearly doubled. In 4 positions a different root move was selected when
: randomization was on.
:
: random = 0 random = +/-5 centipawns log2(ratio)
: depth move score nodes sec. move score nodes sec. nodes seconds
:
: 6 c8d7 -5 542229 65 c8d7 -5 570051 70 0.072 0.107
: 7 g4c8 -167 1092390 128 g4c8 -162 1237102 143 0.179 0.160
: 6 e4g4 -24 623520 82 e4g4 -20 611763 88 -0.027 0.102
: 11 b3d4 -201 1512930 168 b3d4 -196 1521074 162 0.008 -0.052
: 6 e4d5 -5 396969 70 e4d5 -10 403197 70 0.022 -0.000
: 7 f4d3 10 818764 95 f4d3 5 803301 103 -0.028 0.117
: 7 c6c5 -18 390395 47 c6c5 -15 290084 37 -0.428 -0.345
: 5 g6g5 31 189341 25 g6g5 35 195326 26 0.045 0.057
: 6 h2h3 28 668767 98 h2h3 28 561966 84 -0.251 -0.222
: 6 c8c3 -38 642513 83 c8c3 -34 679502 99 0.081 0.254
: 6 e1d1 -3 556149 84 e1d1 1 668832 100 0.266 0.252
: 11 h2h4 65 1322867 147 h2h4 60 1450122 155 0.133 0.076
: 6 e3c5 38 382856 55 e3c5 43 754891 109 0.979 0.987
: 7 a2a4 51 750799 86 a2a4 51 842278 105 0.166 0.288
: 7 c1c2 44 674382 78 *a2a3 45 682675 87 0.018 0.158
: 8 e4g3 53 766204 94 *e2e3 55 1035401 135 0.434 0.522
: 8 e2e3 76 641144 75 e2e3 74 600126 68 -0.095 -0.141
: 7 f2f3 81 533022 59 f2f3 87 620500 66 0.219 0.162
: 8 d3e4 68 917376 107 *f5d6+ 71 583595 73 -0.653 -0.552
: 9 d5d3 59 1594185 174 *d5d2 62 1390106 155 -0.198 -0.167
:
: log average 0.047 0.088
: percent 3.2% 5.9%
: --
: Dan Oetting <oet...@gldfs.cr.usgs.gov>
Can you describe your search? IE null-window as in PVS or NegaScout? What
about hashing? How did you handle the random values? etc...
Bob
Dan Oetting
Dan Oetting
In article <57v37j$q...@juniper.cis.uab.edu>, hy...@crafty.cis.uab.edu
(Robert Hyatt) wrote:
Dan Oetting (oet...@gldfs.cr.usgs.gov) wrote:
: Randomization of root ply. 20 test positions
>
> Can you describe your search? IE null-window as in PVS or NegaScout? What
> about hashing? How did you handle the random values? etc...
>
> Bob
If you don't trust my results post your own! Actually I don't trust my
own results and was somewhat supprised by a lower than expected cost. The
test positions were ones I found posted here several weeks back and I
don't expect that they are a representitive sample.
The search is a generic alpha/beta with extensions, broken NULLMOVE and
incomplete PVS. (Sorry but this is what I have). The hash table uses
selective replacement and ageing. The first ply nodes were randomized with
the following code: [Note: randy is recomputed each ply but will always
return the same value for a given move until the next game.]
randy = (dither && alpha >= -9000 && beta <= 9000)
? ((GameSeed*hashbd) % (dither + 1) - dither/2) : 0;
score = -search (xside, ply + 1, depth - 1, ext,
-beta+randy, -alpha+randy);
...
score = score + randy;
I would like to see the root ply randomization test results with a modern
search engine on a better selection of positions.
--
Dan Oetting <oet...@gldfs.cr.usgs.gov>
Ed Schröder
From: hy...@crafty.cis.uab.edu (Robert Hyatt)
: Just to help, isn't a O-O bonus rather like this, especially if
: O-O takes place at ply 1, and *early* castling is prefered ?
> I don't know of anyone that would try this, because it is a "known
> no-no". The transposition table does not hold "path" information,
> only "position" information. If you try to do this, you are
> guaranteed to get oddball behavior, because when you *search* a
> position you know whether you castled early or not, but when you
> reach a hashed position, you have no clue about the path below that
> hashed position. Hence random side-effects that simply don't cut it...
In Rebel castling do get a small bonus *only* at PLY=1. As long as you
do not put PLY=1 positions in the hash table I do not see any problems.
To KK...
Castling in Rebel is probably the only case where Rebel is not
symmetric... :) Sorry Alan for hurting your Komputer feelings... :)
- Ed -
Robert Hyatt
Dan Oetting (oet...@gldfs.cr.usgs.gov) wrote:
: In article <57v37j$q...@juniper.cis.uab.edu>, hy...@crafty.cis.uab.edu
Wasn't implying "non-trust" at all. I'm interested in how close your search
is to what I do so that I can see if your results are transferable or not...
Robert Hyatt
Ed Schröder (rebc...@xs4all.nl) wrote:
: From: hy...@crafty.cis.uab.edu (Robert Hyatt)
:
: : O-O takes place at ply 1, and *early* castling is prefered ?
:
: > I don't know of anyone that would try this, because it is a "known
: > no-no". The transposition table does not hold "path" information,
: > only "position" information. If you try to do this, you are
: > guaranteed to get oddball behavior, because when you *search* a
: > position you know whether you castled early or not, but when you
: > reach a hashed position, you have no clue about the path below that
: > hashed position. Hence random side-effects that simply don't cut it...
:
:
: To KK...
: Castling in Rebel is probably the only case where Rebel is not
: symmetric... :) Sorry Alan for hurting your Komputer feelings... :)
:
: - Ed -
:
you still get bad scores. For example: search this first...
o-o Nf3 Nc6 ... and you add in your small bonus for castling
at ply=1.
then search this:
Nc6 Nf3 o-o and you get a hash hit, and the score has the
ply=1 castling bonus already in it. Which means your early castling
bonus either doesn't work or works too well, depending on how you think
about it. In any case, it won't encourage early castling in the above
because the transposition table doesn't know anything about the path
leading to the position...
Brian Sheppard
Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
<5818i7$n...@juniper.cis.uab.edu>...
>
> you still get bad scores. For example: search this first...
>
> o-o Nf3 Nc6 ... and you add in your small bonus for castling
> at ply=1.
>
> then search this:
>
> Nc6 Nf3 o-o and you get a hash hit, and the score has the
> ply=1 castling bonus already in it.
>
There is a technically superior implementation that does not
have this problem. You increase the *score* returned from the
search whenever the ply=1 move is a castling move.
There is a fine point in this implementation, related to alpha-
beta cutoffs. If you (naively) implement your code as follows:
castling_move_score = BONUS + search(alpha, beta);
then you don't get correct alpha-beta cutoffs within the search,
because the search is "not aware" that BONUS will later be added
to the value of the move. The correct implementation is
castling_move_score = BONUS + search(alpha + BONUS, beta + BONUS);
which has all desirable properties:
1) It encourages playing a move that is, a priori, a good one, and
2) It has correct alpha-beta cutoffs, and
3) to our amazement, the xref table is 100% correct.
Note that this implementation is independent of the ply; we could do
the same trick at any node in the search and still have the same
properties.
Regards,
Brian Sheppard
Robert Hyatt
Brian Sheppard (bri...@mstone.com) wrote:
: Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
What do you do if the *actual* score for the PV starting with o-o is
*below* alpha+BONUS, but is, as expected, > alpha? Re-search? It
seems that anytime you fudge the window, you blow something up.
Alpha/Beta is pretty tightly defined as to how/when it works. Shifting
the bounds is tricky at best, dangerous at worst.
Needs more thought at best, but seems to not work after a brief
analysis...
Ronald de Man
oet...@gldfs.cr.usgs.gov (Dan Oetting) writes:
>Randomization of root ply. 20 test positions were searched for 3 minutes
>each with randomization off and +/- 5 centipawns. The last ply completed
>in both runs is compared. This sample test shows a 3.2% average increase
>in the nodes searched and almost 6% increase in time to reach the common
>ply when randomization was on. The worst case shows both nodes and time
>nearly doubled. In 4 positions a different root move was selected when
>randomization was on.
The small performance penalty might be explained by the hash table losing
a little efficiency. But only 6% increase in time is affordable (note that
you only want to use randomization the first three moves (say) out of book,
so that it is probably not a problem to allocate 10% extra time (say) for
these moves). On a chess server this small loss in time will be greatly
outweighed by the reduction in games lost to people repeating their wins.
Of course a learning algorithm might also help, but takes a lot more time
to develop. And if you only learn how to use your book, you still have
the problem of people leaving book very early, getting the same position
over and over again, and finding out how to win it eventually (because
the computer is predictable from that point on).
Maybe it's an idea to vary the amount of randomization (number of moves
randomized, and randomizing factor) based on the probability that the
moves that were actually played by the computer, will be played again
the next time. By this probability I mean the following. Suppose you have
been in book for 10 moves. Then every time you played a book move, you have
chosen between some candidates. Every move had a probability between 0 and 1
of being played. The probability that the computer will play the same
moves the next game (assuming the opponent also repeats his moves) is the
product of the 10 probabilities for these 10 moves.
So if you leave the book, and this probability number is very low, the chance
of this position appearing in an arbitrary game is small (of course, I forget
about transpositions here). But if the probability number is very high,
it is much more likely to reach this position again in another game, maybe
because you left the book early, of because there were many forced moves.
So in this case you might want to add some randomization to the first few
moves that follow. And as we know now, that is not expensive done the right
way.
Ronald de Man
Simon Read
oet...@gldfs.cr.usgs.gov (Dan Oetting) wrote:
>Randomization of root ply. 20 test positions were searched for 3 minutes
>each with randomization off and +/- 5 centipawns.
This is absolutely excellent stuff. Not we have some hard numbers to
talk about, so we can really see the advantages and disadvantages.
Is it possible to compare the above with an alternative scheme, viz:
adding +/- 5 centipawns to the evaluation function? The randomness
must be consistent so I suggest it's derived from the hash value,
which is sort of random, but also gives the same number for the same
position each time.
Simon
s(dot)read(at) ... ... ... .. cran (no dot here!) field(dot) ac (dot)uk!!!!!!!
.but the address in my header is wrong. Don't use it!!!
Dan Oetting
In article <32a47...@news.cranfield.ac.uk>, Simon Read <bbr...@ftc.gov>
wrote:
> oet...@gldfs.cr.usgs.gov (Dan Oetting) wrote:
> >Randomization of root ply. 20 test positions were searched for 3 minutes
> >each with randomization off and +/- 5 centipawns.
> > [with lots of results...]
>
> This is absolutely excellent stuff. Not we have some hard numbers to
> talk about, so we can really see the advantages and disadvantages.
BS! Those numbers were created by a program that has never been on
anybody's rating list. You could probably get better results from Wood
Pusher!
Let's get some solid results from well known programs before these numbers
get written up as fact in some journal.
> Is it possible to compare the above with an alternative scheme, viz:
> adding +/- 5 centipawns to the evaluation function? The randomness
> must be consistent so I suggest it's derived from the hash value,
> which is sort of random, but also gives the same number for the same
> position each time.
>
> Simon
The same randomizing function could be used in eval but a more efficient
form would be better. The hash alone is not random between games so it
needs to be modified. Try something like:
eval += (((signed)(GameSeed * hashbd) >> (wordsize-16)) * eval_dither) >> 16;
where the random number GameSeed is changed before each game.
--
Dan Oetting <oet...@gldfs.cr.usgs.gov>
Brian Sheppard
> What do you do if the *actual* score for the PV starting with o-o is
> *below* alpha+BONUS, but is, as expected, > alpha? Re-search?
If the score is low, then the move is cutoff (castling is bad). If
the score is high, then castling is best.
> It seems that anytime you fudge the window, you blow something up.
> Alpha/Beta is pretty tightly defined as to how/when it works. Shifting
> the bounds is tricky at best, dangerous at worst.
Actually, AlphaBeta is guaranteed to produce the minimax bounds, so there
is nothing dangerous about it. All I have done is ask the search to regard
a different range of scores to be cutoffs.
Brian
Vincent Diepeveen
>Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
><5818i7$n...@juniper.cis.uab.edu>...
>>
>> you still get bad scores. For example: search this first...
>>
>> o-o Nf3 Nc6 ... and you add in your small bonus for castling
>> at ply=1.
For this reason i removed ALL bonusses diep got for moves.
I gave for example a penalty when a piece was moved more than twice.
This makes alfabeta inconsistent.
Because of the same reason this castling bonus doesn't work.
>> then search this:
>>
>> Nc6 Nf3 o-o and you get a hash hit, and the score has the
>> ply=1 castling bonus already in it.
>>
>
>There is a technically superior implementation that does not
>have this problem. You increase the *score* returned from the
>search whenever the ply=1 move is a castling move.
>
>There is a fine point in this implementation, related to alpha-
>beta cutoffs. If you (naively) implement your code as follows:
>
> castling_move_score = BONUS + search(alpha, beta);
>
>then you don't get correct alpha-beta cutoffs within the search,
>because the search is "not aware" that BONUS will later be added
>to the value of the move. The correct implementation is
>
> castling_move_score = BONUS + search(alpha + BONUS, beta + BONUS);
>
>which has all desirable properties:
>
> 1) It encourages playing a move that is, a priori, a good one, and
> 2) It has correct alpha-beta cutoffs, and
> 3) to our amazement, the xref table is 100% correct.
Problem is that at in the tree where this occurs you store in the
root the wrong alfa
current alfa = search+bonus, for all positions that are the same.
for example: Next iteration with a transposition you get to the same position,
and you get a search+bonus cutoff instead of a bonus cutoff.
>Note that this implementation is independent of the ply; we could do
>the same trick at any node in the search and still have the same
>properties.
You also search with a different window which is a huge
disadvantage. Suppose you give +10 for castling and you search with +5
then whole alfabetawindow you normally search with is not containing
the window you search when castling, causing a slow search.
>Regards,
>Brian Sheppard
Vincent
--
+----------------------------------------------------+
| Vincent Diepeveen email: vdie...@cs.ruu.nl |
| http://www.students.cs.ruu.nl/~vdiepeve/ |
+----------------------------------------------------+
Ed Schröder
From: hy...@crafty.cis.uab.edu (Robert Hyatt)
: In Rebel castling do get a small bonus *only* at PLY=1. As long as you
: do not put PLY=1 positions in the hash table I do not see any problems.
: - Ed -
> you still get bad scores.
Yes an no...
>For example: search this first...
> o-o Nf3 Nc6 ... and you add in your small bonus for castling
>at ply=1.
> then search this:
> Nc6 Nf3 o-o and you get a hash hit, and the score has the
> ply=1 castling bonus already in it. Which means your early castling
> bonus either doesn't work or works too well, depending on how you think
> about it. In any case, it won't encourage early castling in the above
> because the transposition table doesn't know anything about the path
> leading to the position...
In Rebel the castling bonus differs from 0.00 to 0.40 decided in the
pre-processor.
Let's say the bonus is 0.10 for the below example...
0-0 Nf3 Nc6 will (for example) score 0.80 (bonus is included)
Nc6 Nf3 0-0 will produce a hash hit, score is 0.80
About "Yes"...
You are right, looking at the goal of the pre-processor the score of:
- 0-0 Nf3 Nc6 should be 0.80 (which is)
- Nc6 Nf3 0-0 should be 0.70 (which is not!)
About "No"...
Due to normal mini-max 0-0 will stay as best move.
So I still reach my goal stimulating castling.
- Ed -
Robert Hyatt
Ed Schröder (rebc...@xs4all.nl) wrote:
: From: hy...@crafty.cis.uab.edu (Robert Hyatt)
:
I agree, and that's the "maddening" part. But if things are even a little
"turbulent" so that you "change your mind" a lot during the search, the
initial move ordering might not hold up. For example, you start the search
a pawn up, but you really can't hold the pawn, although it looks like you can
for the first few plies. Or, you start off even, but a few oddball moves
appear to win a pawn and move to the front of the list... All it takes is a
little "confusion". While this is not a "bad" thing to happen of course, it
is an "inconsistent" thing to have happen (at times.)
Brian Sheppard
Vincent Diepeveen <vdie...@cs.ruu.nl> wrote in article
<584hin$r...@krant.cs.ruu.nl>...
> Problem is that at in the tree where this occurs you store in the
> root the wrong alfa
> current alfa = search+bonus, for all positions that are the same.
>
> for example: Next iteration with a transposition you get to the same
position,
> and you get a search+bonus cutoff instead of a bonus cutoff.
This does not cause incorrect search behavior, since search + bonus is
the correct minimax value for the root move.
> You also search with a different window which is a huge
> disadvantage. Suppose you give +10 for castling and you search with +5
> then whole alfabetawindow you normally search with is not containing
> the window you search when castling, causing a slow search.
If you only give bonuses at the root position, then you have a
slowdown because different pathways to a node could occur that
have different alpha beta bounds, and then the xref cutoff value
might not be useful.
However, if you give a bonus to castling at every position in
which castling is legal, then you do not have this problem,
because all the transposition pathways would have the same
bonuses, so they will arrive at the xref node with the same bounds.
So: no slowdown in this case.
Brian
Robert Hyatt
Brian Sheppard (bri...@mstone.com) wrote:
: Vincent Diepeveen <vdie...@cs.ruu.nl> wrote in article
Correct, but then the program falls for "a bird in the bush is as good
as a bird in the hand" and as long as it can castle somewhere in the
PV it's happen. If the castle move is near the end, it's probable that
something later will come into the programs "horizon" and it will continue
to delay castling, until the point where it no longer can do so.
Personally, I've worked long and hard on Crafty to defer castling to the
point where it needs to do so, because castling too early gives the human
players too much "lead time" to build up an attack. If they don't know
where you king is going to live, they can't attack as easily.
However, many still go for early castling. I'm of the famous old quote
schood: "castle if you want to, or if you have to, but not just because
you can..." If you want to castle soon, you have to have a depth-dependent
factor, and it's guaranteed to bust your transposition table every time. :)
Bob
Simon Read
oet...@gldfs.cr.usgs.gov (Dan Oetting) wrote:
>BS! Those numbers were created by a program that has never been on
>anybody's rating list.
I think you are denigrating your own program and you don't need to.
You are implying that all programs react differently to random schemes.
I think this isn't the case. A few percent difference in average node
count between with-random and without-random is caused by the nature of:
(1) chess game trees
(2) a-b search
(3) how many moves exist which are of similar worth.
Factor (2) is meant to be transparent - it is meant to be a tool for
efficient calculation of (1). If chess programs were wildly different
in the impact of randomness, it would imply that the program internals
were interfering with the chess.
>Let's get some solid results from well known programs before these numbers
>get written up as fact in some journal.
Well, I never suggested writing the numbers up, but at least they are
the first numbers to appear on this newsgroup on this question, the
first attempt to show the costs/benefits of randomness, and as such
they are to be congratulated. Hopefully this will encourage others to
post similar results and also answer the complimentary question:
"What is the impact upon playing strength?"
Remember the MVV/LVA v. SEE discussion -
eventually people started posting numbers
about the differences when implemented in their programs. Until then
it was just theoretical. Most programmers knew their programs well
enough to have a pretty good idea, but actually testing it and posting
the numbers gave a greater degree of certainty.
>[...] where the random number GameSeed is changed before each game.
This is indeed true, and is something I hadn't thought of.
Maybe the clock in microseconds at the game start?
Simon
SReadCranfieldAcUk <--- that's me!!! (not the address in my header)