Taking a screen video is very easy, once you know where the feature is hidden. The QuickTime Player application has an option to record a screen video:

When you choose New Screen Recording from the menu, a small black window appears:

The little triangle reveals a menu that allows you to add an audio track from a microphone, and change a couple of other settings:

This works very nicely, and you can record a voiceover using an internal or external mic. The only trouble is the video doesn’t include the sounds made by the app itself. In some cases that probably doesn’t matter much, but it’s a real problem if you’re trying to demonstrate an app whose audio matters, like a game.

Fortunately there is a clever little app called Jack OS X that you can use to fix it.¹ So download and install Jack 0.89 or later.² Right now it’s still in beta, so you’ll have to look at the mailing list messages to find a link to the latest beta release. Make sure you have beta 20 or later. (Jack 0.89 should be released pretty soon, then this part will be easier.)

Open JackPilot. The first time you run it, the Preferences window will open. Make sure the option “Auto-Connect with physical ports” is ticked, and press Save. Then you’ll see a little window like this. Click Start.

Now open System Preferences > Sound:

and change the sound output device to JackRouter.

Next open QuickTime Player and choose New Screen Recording from the File menu. Using the dropdown menu in the Screen Recording window, choose JackRouter as the microphone. Then open the app you want to record.

Go back to JackPilot, and click Routing. Select QuickTime Player in the middle column (the column labelled Receive Ports). In the left-hand “Send Ports” column, double-click on the name of the app you want to record. If you’re planning to record a live voiceover, double-click system as well. After you double-click these items, they’ll turn red, so it should look something like this:

Finally you can go to QuickTime Player and click the red button to start recording.

When you’ve finished recording your video, you should connect the QuickTime Player Send Port to the system Receive Port using JackRouter, or else you won’t hear the audio when you play it back.

If you have any trouble with this, post a comment below.

Footnotes:

1. Some blogs recommend using an app called SoundFlower for this. However, there are reports of SoundFlower causing serious problems on Lion (examples: one, two), as well as distorting the sound. The SoundFlower code has not been updated for more than a year, so these problems seem unlikely to be resolved soon. At the moment it does not look like a good choice for Lion users.

2. The released version of Jack didn’t quite work for me when I tried, so I emailed the project mailing list and Stéphane Letz fixed it the very same day. Open source development at its best.

A test of the power of Twitter. Can I reach someone who understands homomorphic encryption, and is willing to help a confused soul? (link)

I should have known better than to challenge the Power of Twitter, because that sparked a frenzy of retweeting. And so I learnt that Twitter is home to a great many kind generous people who like nothing better than to come to the aid of a stranger who calls for help — though unfortunately none of these people knows anything about homomorphic encryption.

Colin Wright was also kind enough to post my question to Hacker News, which led to a depressingly ill-informed but mercifully brief discussion there.

But it worked out well, because somehow or other David Cash found my post. David understood what I was asking, knew the answers, and explained them clearly and succinctly. Thanks, David.

For the benefit of anyone else who is curious, I should explain briefly what I’ve learnt – though I suggest you also look at David’s comments.

In the simplest proof-of-principle presentation of homomorphic encryption, each bit is encrypted separately. I failed to realise this, because I hadn’t understood that the encryption is randomised so the encryption process is unlikely to give the same result twice even when encrypting with the same key. This randomisation protects against the re-encryption attack I mentioned, though of course it means that each encrypted bit must be a lot bigger than one bit, so there is a substantial blow-up in size when encrypting the data.

So as long as there is a way to perform (say) the AND and XOR operations on encrypted values – which there is, since they correspond to multiplication and addition modulo 2 – it’s possible to perform some arbitrary computation with the encrypted values.

There is a little mathematics to be found here as well. It’s something that I probably ought to have known all along; but I didn’t, or if I ever did then I had forgotten, so perhaps you will also find it interesting.

Claim. If F is a finite field, then every function Fⁿ→F can be represented by a polynomial in n variables.

This is not hard to prove, and it’s always more enlightening to prove something oneself than to read someone else’s proof, so I shan’t give it away. If you haven’t seen this before, and you like that sort of thing, do feel free to write your proof in the comments.

The technology is edging towards practicality as better schemes are devised, and it may soon reach the point where it’s useful in some real-world situations.

But there’s something I don’t understand. I’m hoping that someone who does understand it may come across this and explain it.

The techniques used seem to allow the computation of arbitrary polynomials over various finite rings, and – at least in everything I’ve read – it’s always treated as obvious that this is equivalent to allowing arbitrary computations. Is that actually true? If so, is it really obvious? I’d love some enlightenment here.

A related source of confusion is that clearly any encryption scheme that actually supported arbitrary computations on encrypted values would be hopelessly insecure. For example, suppose you have encrypted a ten-character ascii password. I then run the function that extracts the first character. The result I get is still encrypted, but since there are only 128 possible values for an ascii character, I can encrypt each of these values and compare the result to the result of my computation. (I can do this because I can always encrypt any data of my choice, just by running a constant-valued function inside the encryption.) Then I do the same for the second character, and so on, till I have your complete password. Encryption fail!

The only reasonable conclusion I can draw from this is that fully homomorphic encryption does not really permit arbitrary computations on the encrypted data. In that case,

1. Why do people keep saying it does?
2. What is the class of computations that are in fact permitted? Is it just the evaluation of polynomials?

People of the Internet, I thank you.

Added later: After reading some more about it, I think Gentry’s scheme has the property that each plaintext can be represented by a large number of possible ciphertexts. This could potentially have the effect that the decoding scheme I described can’t be made to work. Is that relevant?

Several people suggested that Binet’s closed-form formula for Fibonacci numbers might lead to an even faster algorithm. That’s an interesting idea, which we’re going to explore in this post. So, what is Binet’s formula? It goes like this:

where is the golden ratio.

I’d like to explain why this formula works, because it’s a lovely story; and, despite what you might think from most of the explanations on the web, it’s perfectly possible to understand and appreciate it without knowing what “eigenvalue” means. But I fear that would be too long a digression here, so I’ll save it for another post.

There is a nice trick we can use to simplify the computation of this expression, taking advantage of the fact we know it always comes out as an integer. Since φ is about 1.618, its negative cousin (1-φ) is about -0.618, which means that the term

is always between -1/2 and 1/2. So we can just compute

and round to the nearest integer.

The simplest way to implement this idea is to use ordinary floating-point arithmetic. For example, in C we might write:

double fib_fixed(long n)
{
    double phi = (sqrt(5) + 1) / 2.0;
    return round(pow(phi, n) / sqrt(5));
}

This is simple and fast. The only trouble is that it almost always gives the wrong answer. On my machine the answer is wrong whenever n > 70. For example fib_fixed(71) gives 308061521170130, whereas the correct answer is 308061521170129, and it only gets worse from there.

We can improve the situation a little by tweaking the computation, but, however cunningly we do that, we’ll soon run into a fundamental obstacle: fib(79) is 14472334024676221, which can’t even be represented in an IEEE double. You can see that illustrated as a comedy Google calculator fail.

So if we want to implement this in a general way then we need to use arbitrary-precision floating-point arithmetic. For some reason this has not gone mainstream in the way that big ints have done, but the GMP library has a good implementation, so we’ll use that. Here’s the code:

void fib_float(mpf_t *result, long n)
{
    mpf_t sqrt5, phi;
    mp_bitcnt_t bitcnt;

    /* We need about n lg(phi) bits of precision */
    bitcnt = n * 7 / 10;

    /* Initialise sqrt5 to the square root of 5 */
    mpf_init2(sqrt5, bitcnt);
    mpf_sqrt_ui(sqrt5, 5);

    /* Initialise phi to the Golden Ratio */
    mpf_init2(phi, bitcnt);
    mpf_set(phi, sqrt5);
    mpf_add_ui(phi, phi, 1);
    mpf_div_2exp(phi, phi, 1);

    /* Compute phi ^ n / sqrt5 */
    mpf_init2(*result, bitcnt);
    mpf_pow_ui(*result, phi, n);
    mpf_div(*result, *result, sqrt5);

    /* Dispose of the temporary variables */
    mpf_clear(sqrt5);
    mpf_clear(phi);
}

This works fine, gives correct answers, and is reasonably fast. But how does it compare to the integer methods? For comparison, I rewrote the fib_fast algorithm from my last post to use GMP integers. Click to see the code:

void fib_int(mpz_t *result, long n)
{
    mpz_t a, b, c;
    long bit, mask;

    /* Set 'bit' to the most-significant 1-bit of 'n' */
    bit = 1; mask = 1;
    while (n > mask) {
        bit = bit << 1;
        mask = (mask << 1) | 1;
    }
     
    mpz_init_set_ui(a, 1);
    mpz_init_set_ui(b, 0);
    mpz_init_set_ui(c, 1);
    
    while (bit > 0) {
        if ( (n & bit) != 0 ) {
            /*  a, b = (a + c) * b, (b * b) + (c * c)  */
            mpz_add(a, a, c);
            mpz_mul(a, a, b);

            mpz_mul(b, b, b);
            mpz_addmul(b, c, c);
        }
        else {
            /*  a, b = (a * a) + (b * b), b * (c + a)  */
            mpz_add(c, c, a); /* Temporarily set c := c + a */

            mpz_mul(a, a, a);
            mpz_addmul(a, b, b);

            mpz_mul(b, b, c);
        }

        mpz_add(c, a, b);
        bit >>= 1;
    }

    mpz_init_set(*result, b);
    mpz_clear(a); mpz_clear(b); mpz_clear(c);
}

Then I made a graph showing the execution time of both methods, against the input n.

Clearly the integer method is faster, but the curves are not obviously different shapes. A log-log plot shows the relationship more clearly:

which supports the idea (consistent with what you’d expect in theory) that both algorithms have the same big-O complexity, but the integer method is consistently about five times faster.

Floating-point arithmetic has a reputation for being difficult and unreliable; a technique that is good for finding approximate answers quickly, but best avoided when a precise answer is required. And actually I think that’s a fair assessment on the whole, but it’s interesting to see how arbitrary-precision floating point arithmetic can give us an exact answer very easily in this case. Of course we lose a lot of the speed advantage that floating-point conventionally offers, because our hardware doesn’t have the same fast native support for these “big floats” that it does for IEEE doubles.

A related idea is to take advantage of the fact that all the calculations produce numbers of a special form, e.g. a+bφ for integers a and b. This works essentially because φ² = 1 + φ, and so any polynomial in φ can be reduced to that form.

This turns out to be precisely equivalent to the matrix technique we used last time, because φⁿ = fib(n-1) + fib(n)φ, and so computing powers of φ in this representation is just directly equivalent to computing Fibonacci numbers.

A variation of this – as suggested on HN – is to use the fact that φⁿ is always of the form

for integers a and b. This idea leads to the Lucas numbers, because

where luc(n) = fib(n-1) + fib(n+1), and hence to an efficient integer algorithm based on the identities

fib(2n) = luc(n) fib(n)
luc(2n) = 5 fib(n)^2 + 2 (-1)ⁿ

luc(2n + 1) = (5/2) fib(n) (fib(n) + luc(n)) + (-1)ⁿ
fib(2n + 1) = luc(2n + 1) – 2 luc(n) fib(n)

The complete code for this algorithm is here, and more generally all the code used in this post is on GitHub. Remarks and critique would be very welcome. You can follow me on Twitter at @robinhouston.

There are four 2×2 mazes:

So the first interesting case is 3×3. For this, we’ll classify the 3×3 mazes according to which of its four neighbours the central cell is connected to:

One neighbour

Suppose the central cell is connected to the cell above:

Then the rest of the maze must consist of two arms growing from the upper cell, with a combined length of 7, so there are eight possibilities:

These could also be rotated so the single neighbour is at the right, bottom, or left:

making a total of 32 mazes of this type.

Two opposite neighbours

If the central cell is connected to the cells above and below:

then there are two independent arms – one on the left, and one on the right, and there are four possibilities for each arm:

So there are sixteen of these:

And there are another sixteen rotated versions, where the central cell is connected to the two cells to its left and right:

Two adjacent neighbours

If the central cell is connected to two adjacent neighbours:

then there are two possible ways for the corner cell to be connected:

and six possibilities for the long arms:

for a total of twelve possibilities in this orientation:

and the other three orientations make a total of 12×4 = 48:

Three neighbours

If the central cell is connected to three neighbours:

then there are two possibilities for each corner, again, and four for the arms, for a total of 2×2×4 = 16 in this orientation:

and the other three orientations bring the total to 16×4 = 64.

Four neighbours

The last case is where the central cell is connected to all four of its neighbours.

Two possibilities for each corner makes 2×2×2×2 = 16:

So there are a total of 192 3×3 mazes.

Unfortunately there’s no obvious way to generalise this nice classification to larger mazes: the next post in this series will look at a general algorithm.

So I’ll say it: Kirchhoff”s theorem. It’s a wonderful theorem, which relates the problem of counting mazes to the problem of computing the determinant of a matrix. But that’s all I’m going to say about it for now.

The trouble is it’s not at all obvious how to compute the exact determinant of a large integer matrix efficiently, so it doesn’t automatically make our task any easier. I don’t just want to describe how to count mazes; I want to explain it — and bringing some fairly complicated linear algebra into the picture at this stage doesn’t really help to keep the story straightforward and comprehensible.

More importantly, it turns out there is a fairly natural way to tell the whole story purely in terms of mazes, so that’s what I’m going to do. Later I’ll explain how mazes relate to matrices, just to round it off.

Before we start, we need to formulate the problem precisely. It’s not enough just to count the number of mazes on a rectangular grid, because we also need to count the number of completions of partly-completed grids. So we need something more general.

There’s a simple trick that will prove incredibly useful: we’re going to think about directed mazes. Suppose we have a maze, say this one:

To convert a maze into a directed maze, you choose a cell to be the root. We could choose any of the 8×8=64 cells in this example maze, but let’s plump for the top-left. Then, in all the other cells except that one, draw an arrow in the direction of the path to the root. Like this:

Because there is always just one path from every cell to every other, so there is just one path from every other cell to the root, wherever we chose the root to be. So every cell – apart from the root itself – has an arrow pointing out of it in a direction determined unambiguously by the maze and the choice of root.

Once we’ve drawn the arrows, we can remove the walls. You can get them back by looking at the arrows: just draw a wall on any cell boundary that has no arrow pointing to it from either side.

So this gives a useful way to represent a maze:

• Choose one cell to be the root;
• For every cell other than the root, draw an arrow from that cell to one neighbouring cell,
• In such a way that there are no cycles (chains of consecutive arrows that return to the starting point).

Also, we don’t only want to count the number of mazes on a grid. Just as importantly, we need to count the number of possible completions of a partial maze. As it turns out – not terribly surprisingly – the simplest way to formulate the problem in sufficient generality is to look at (directed) mazes on general graphs, rather than just grids.

For example, suppose we have a partially-completed 3×3 maze, like this:

We are considering the possible ways this could be completed – and we’re thinking of those completions as directed mazes, so we have to choose a root. Let’s choose the top-left cell. The two cells that are definitely connected to this cell are also part of the root, so we remove all three of them:

Now we mark the possible arrows that a directed maze might have, consistent with the partial completion:

This is a sort of directed graph, but it has one slightly unusual feature: arrows that point away from a node but don’t point to another node. (We’re thinking of the root as being outside our graph, remember.) We’ll call them outgoing arrows.

So these are the graphs we’re going to think about, the substrate for our mazes: directed graphs with outgoing arrows.

The scene is set. Let us count!

But how can we do that? There are a huge number of possible mazes on any decent-sized grid, so it’s not feasible to loop through them one-by-one.

To put this in perspective, if we could somehow generate mazes at a rate of a quadrillion mazes per second – one every attosecond – it would still take ten million times the age of the universe to generate all the mazes that can be drawn on a modest 10×10 grid.

A source of possible hope is the fact that the mazes naturally organise themselves into a binary tree. Here’s what it looks like for the 2×2 grid:

We are taking the boundaries between cells – the places where wall segments might go – and considering them one-by-one. First the boundary between the top two cells is considered: on the left is the partially-drawn maze without a wall on that boundary, and on the right is the one with a wall. Then the other three boundaries are considered in order. If an impossible configuration is reached, we cross it out.

At the end we are left with the four possible 2×2 mazes as the remaining leaves of the tree.

The trees will not be very nicely balanced, as you can see in this case where three of the four mazes are on the left-hand branch. But the depth of the tree is equal to the number of cell boundaries, which in general is much smaller than the number of possible mazes.

On this picture I’ve written on the branches the number of mazes that branch ultimately leads to. Because the point is this: if we could, somehow, efficiently compute those numbers, then we could use these trees to solve our problem.

Let’s just number the mazes in the order they appear along the leaves of the tree. Then we can use the branching information to derive each of those mazes from its index number, by considering the cell boundaries in turn. In our example, we know that mazes 0–2 are on the left-hand branch, and maze 3 is on the right-hand branch. So maze 3 has a wall at twelve o’clock, and the others don’t. Now the wall at nine o’clock: on the right, it leads to an impossible configuration, so leave it out; on the left, maze 2 has it and mazes 0–1 don’t. And so on, down the tree.

So next time we’ll start to look at how to count mazes – or rather how to count the number of possible completions of a partial maze, which turns out to amount to more or less the same problem. If we can solve that, then we can use it to solve the random access problem.

I want to write a program that allows “random access” to all possible mazes, and does it quickly enough to be practical. I think I know how it can be done. That’s why I’m writing about mazes now.

When I say “maze”, I’m talking about the sort of thing you see in cheap puzzle-books at railway stations, like this:

Every part of the maze is reachable from every other by precisely one path (so there are no loops). In technical terms, a maze is a spanning tree of a finite rectangular two-dimensional grid.

By random access I mean the following: there are about 8 × 10²⁴⁹ different possible mazes on a 23×23 grid like the one above. To be precise, there are

8,092,641,670,349,801,721,804,781,137,713,499,621,097,587,118,741,157,248,189,969,
007,805,754,000,654,382,335,518,531,150,471,089,108,161,995,245,369,248,205,451,808,
922,452,989,483,589,738,382,020,054,505,965,237,374,754,791,692,455,943,268,962,118,
313,156,618,241,194,351,661,577,177,461,488,002,356,030,814,981,288,323,446,734,848

of them. I want to assign each of these mazes an index number, from 0 to that huge number above, and to write a pair of programs:

• one that can take an index number and generate the corresponding maze,
• one that can take a description of a maze, and return the index number of that maze.

I’m not aware that anyone has done precisely this before – if they have, I’d love to hear about it.

But there won’t be much in the way of actual new mathematics: I think I can do it using well-established theories. On the other hand most of the mathematics is new to me, so perhaps it’s new to you as well, and it’s ever so beautiful.

I haven’t worked everything out yet. My desire to write about anything peaks when I think I understand it completely, and diminishes exponentially after that, with a half-life of only a week or two. If I worked everything out before starting to write this, I am sure I should never finish it. But I believe the summit is attainable, and I’ve explored enough of the route that I’m certain the journey will be enjoyable. The whole landscape is interesting enough that I mean to take a scenic route, with the occasional day-trip to enticing bordering lands.

It’s going to be an adventure! Do join me.

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …

Each number is the sum of the previous two. Let’s say the zeroth Fibonacci number is zero, so:

And let’s say you want to write some code to compute this function. How would you do it? Perhaps something like this? (Python code)

def fib_rec(n):
  assert n >= 0
  if n < 2: return n
  return fib_rec(n-2) + fib_rec(n-1)

This is a pretty popular algorithm, which can be found in dozens of places online. It is also a strong candidate for the title of Worst Algorithm in the World. It’s not just bad in the way that Bubble sort is a bad sorting algorithm; it’s bad in the way that Bogosort is a bad sorting algorithm.

Why so bad? Well, mainly it is quite astonishingly slow. Computing fib_rec(40) takes about a minute and a half, on my computer. To see why it’s so slow, let’s calculate how many calls are made to the fib_rec routine. If we write for the number of calls made when calculating fib_rec(n), then:

So are the Leonardo numbers, . In other words, computing fib using fib_rec takes time O(fib(n)).

So computing fib_rec(40) involves c(40) = 331,160,281 calls to the fib_rec routine, which is pretty crazy considering it’s only called with 40 different arguments. An obvious idea for improvement is to check whether it’s being called with an argument that we’ve seen before, and just return the result we got last time.

cached_results = {}
def fib_improved(n):
  assert n >= 0
  if n < 2: return n
  if n not in cached_results:
   cached_results[n] = fib_improved(n-2) + fib_improved(n-1)
  return cached_results[n]

That’s a huge improvement, and we can compute fib_improved(40) in a fraction of a millisecond, which is much better than a minute and a half. What about larger values?

>>> fib_improved(1000)
43466557686937456435688527675040625802564660517371780402481729089536555417949051890403879840079255169295922593080322634775209689623239873322471161642996440906533187938298969649928516003704476137795166849228875L

That looks good, and it’s still apparently instant. How about 10,000?

>>> fib_improved(10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in fib_improved
  File "<stdin>", line 6, in fib_improved
  [...]
  File "<stdin>", line 6, in fib_improved
RuntimeError: maximum recursion depth exceeded

Oh dear! We’ve blown the stack. You could blame Python here for having a hard (if configurable) limit on stack size, but that’s not the real point. The problem here is that this algorithm creates n stack frames when you call fib_improved(n), so it uses at least O(n) space.

(Actually it uses O(n²) space — later we’ll get into why that is. Thanks to CoderKyd on reddit for pointing that out.)

It’s easy enough to write a version that only uses constant space — well, not really: but it only uses twice as much space as we need for the end result, so it’s within a small constant factor of optimal — as long as we’re willing to forgo recursion:

def fib_iter(n):
  assert n >= 0
  i, fib_i, fib_i_minus_one = 0, 0, 1
  while i < n:
    i = i + 1
    fib_i, fib_i_minus_one = fib_i_minus_one + fib_i, fib_i
  return fib_i

This is much better. We can compute fib_iter(100,000) in less than a second (on my computer, again), and fib_iter(1,000,000) in about 80 seconds. Asymptotically, this algorithm takes O(n²) time to compute fib(n).

(Maybe you think it should be O(n) time, because the loop runs for n iterations. But the numbers we’re adding are getting bigger exponentially, and you can’t add two arbitrarily-large numbers in constant time. If you think that sounds a bit theoretical, you might enjoy the post where Peteris Krumins measures the running time of fib_iter, and explains why it’s quadratic rather than linear.)

That’s not the end of the story. Since the Fibonacci numbers are defined by a linear recurrence, we can express the recurrence as a matrix, and it’s easy to verify that

Since we can get from to by squaring, this suggests we can compute fib(n) using just log₂(n) iterations:

def bits(n):
  """Represent an integer as an array of binary digits.
  """
  bits = []
  while n > 0:
    n, bit = divmod(n, 2)
    bits.append(bit)
  bits.reverse()
  return bits

def fib_mat(n):
  assert n >= 0
  a, b, c = 1, 0, 1
  for bit in bits(n):
    a, b, c = a*a + b*b, a*b + b*c, b*b + c*c
    if bit: a, b, c = b, c, b+c
  return b

This is certainly much faster in practice. We can compute fib_mat(1,000,000) in less than a second and a half. The asymptotic complexity depends on the multiplication algorithm used. If it’s conventional long multiplication then multiplying two k-bit numbers takes time O(k²), in which case this algorithm is actually still quadratic! I believe Python uses the Karatsuba algorithm, which makes it about O(n^1.6) in Python.

While we’re writing code, let’s improve the constant factor. Each step of fib_mat uses six multiplications, but we can halve that just by observing that c can always be computed as a+b and rearranging things a little:

def fib_fast(n):
  assert n >= 0
  a, b, c = 1, 0, 1
  for bit in bits(n):
    if bit: a, b = (a+c)*b, b*b + c*c
    else:   a, b = a*a + b*b, (a+c)*b
    c = a + b
  return b

And this does indeed run about twice as fast. Further improvement is possible, but I think the point has been made so let’s leave it there. If you want to see a super-efficient version, have a look at the algorithm in GMP.

Another good article on the subject: David Eppstein’s lecture notes, which cover similar ground to this.

If you’re thinking “This is silly! You can just compute Fibonacci numbers using the closed-form expression.” then you’ll probably enjoy the follow-up article on computing Fibonacci numbers using Binet’s formula.

Are you wondering what this has to do with mazes? We’ll get to that eventually, I hope…

I started to think about mazes after reading Jamis Buck’s excellent series of posts, and found that mazes lead quite directly to some interesting mathematics and some remarkable algorithms. So I’d like to share some of that here.

To whet your appetite, here is an exhaustive list of the 3×3 weave mazes:

I may or may not do it all on this site. Ideally I would like to post some interactive demos, which isn’t possible here.