Black Hole Entropy

Success!

danielkatz — Fri, 17 Apr 2009 15:35:21 +0000

Earlier this week, Prof. Khanna noticed that the graphs in Corichi’s article seem to sample more than one point per integer incrementation of (for example, it looks like there are 30 or so points between A = 50 and A = 60). I played around with the incrementation and found that the finer the points, the more my graph was getting shifted up. Why would adding more points increase the graph’s offset? Because my code wasn’t resetting the counting variable between ‘s. The number of states listed as being from one area was actually the sum of all the states for all the areas up to that one. Adding one line of code, I get:

Now, even though this osculating term is below , it seems to agree with Corichi’s results to the best of my ability to squint at them.

Easy part’s over. Time to get this thing to run fast.

Looking at Error

danielkatz — Wed, 15 Apr 2009 15:42:09 +0000

I ran the counting for values of from 0.1 to 2.0 to see how it effects agreement with analytic results. Let the error in a counting be defined to be the difference between the theoretical prediction, adjusted to agree with the results of myself and Corichi, and the numeric result. This error is oscillatory, and we can see the oscillations die out as increases.

Why might the oscillations increas a bit after ? With a bigger more states will satisfy . When some of these states will overlap. Maybe the number of overlapping states becomes apreciable around 1? I’m not sure.

Looking at the average error it seems like the numerical result is converging to something:

Since the slope at is still pretty large, compared to zero, I can’t tell what the average error is converging to. Thinking about it a little more, when gets big enough the algorithm will just count every possible set of j’s for every area. The sweet spot where the error is minimal looks like .

The algorithm is finally working. Now it’s time to make it work faster.

More Interesting Results

danielkatz — Sat, 11 Apr 2009 18:13:41 +0000

In my attempt to implement the projection constraint, I has each being incremented by 0.5 at each cycle. This is incorrect for the reason that the ‘s are spins and as such can only take jumps of 1. With this change I immediately get:

My Initial Results

At first glance these results seem pretty good, but it gets better. Corichi et al get that adding in the projection constraint intruduces an oscillatory correction which is on average logarithmic, as below:

Corichi et al's Results: The top curve doesn't include the PC, the bottom one does.

Elsewhere in their article, the authors increase the tolerance from to to reduce the oscillations, while keeping the average logarithmic correction. I tried reducing to try an get the oscillatory behaviour shown above, but instead it had the effect of linearly shifting down the whole entropy curve. Likewise, increasing has the effect of shifting up the whole graph. For I get an excellent fit:

dA = 0.7

When examining the error (i.e. the difference between the result and ) it is very clear that good agreement begins when A = 61. This seems odd at first, but in several articles on quantum black holes the authors of those articles mention that spin-1/2 edges can only exist for . I haven’t been able to find an explanation for this, though.

My plans for the future are to run the counting for areas between 61 and 125 (arbitrary) with varying values of and see how that effects the average error and the magnitude of oscillations in that error.

Good News, Strange News

danielkatz — Thu, 09 Apr 2009 12:56:08 +0000

First the good: After a whole week of analyzing the algorithm, searching for errors, I came up empty handed. Every little piece seems to be doing its part correctly. I read through some articles to try and figure out if my scheme is leaving out any states and couldn’t find anything. Eventually, I had a really close look at the results of Corichi (whom I’m trying to mimic for now). They claim that their results, sans projection constraint, are linear with a slope of 1/4. They also mention, as is verified in other articles, that LQG’s prediction is that, again sans projection constraint, the relationship between event horizon surface area and entropy is . Here’s the rub: their data doesn’t match this function. Holding a ruler up to thier results, I found that the y-intercept isn’t zero.

In the above figure, I added the dotted line near the origin to illustrate the point. It seems like my results do agree with theirs after all.

Now it’s time to apply the projection constraint. I wrote a bit of code simillar to that which counts states to consider all possible combinations of ‘s such that . I really expected it to work since it’s super-brute-force, i.e. it checks every combination of ‘s with to see if it satisfies the projection constraint. Here’s what I got:

Something’s up. Imposing the projection constraint should reduce the number of acceptable states, not increase it. I looked at how the algorithm counts these m-states for some small n values so I could easily confirm the results by hand. It seems to be working fine for the few randomly selected n = 2 and n = 3 states I checked. Since the algorithm now over-estimates, there must be lots of j-states where the number of projection constraint m-states is greater than . The first such state is for . Here, yet the algorithm counts 243 acceptable states. To check this out I had the algorithm save all these m-states to a text file and manipulated it in Matlab. I found that all of these states do indeed satisfy . More disturbing is that all of these states are unique. How can there be more unique combinations satisfying a constraint then there are combinations total?! That’s where I’m at now.

Oops

danielkatz — Wed, 01 Apr 2009 18:32:03 +0000

I should really learn to read better. The equation of the line I’ve been calling Corichi’s results in previous posts is not right. I measured the slope off their paper using a ruler and assumed a y-intercept of 1 thinking “at zero surface area there can be only one state.” First, a zero event horizon surface area is unphysical. Secondly, these graphs have been of entropy, not number of states. Finally, the actual slope of Corichi’s results is 0.25, as they state in their article. So, accounting for all of that and without changing the code at all, I get this:

Much better. The error looks a lot better, too:

Here’s some quick info about this error. The average is 0.8259, it appears to be converging on 0.7767. The average not counting the tail between Area = 50 and Area = 60 is 0.7426. Having the entropy be off by a constant implies that the number of states is off by a multiplicative factor of $latex e^{-0.7767} \approx 0.4599$. So, apparently my algorithm is counting about half as many states as it should. I suspect this has to do with the degeneracy factor introduced in the last post.

Best Yet

danielkatz — Mon, 30 Mar 2009 19:29:31 +0000

First, a word of caution: When comparing graphs I post, be sure to look at the range of the x-axis. Most of them start at Area = 50 , but their upper limits may differ. This is because I run the algorithm for as long as I have patience for (a few seconds if I’m at my desk working, a few hours if I’m leaving to go to class, overnight if I’m going to bed, etc) when generating sample images.

Last week, Prof. Khanna gave me a very valuable tip. In this counting, we do want to count states I had previously considered degenerate: permutations of states. For example, the states and should be considered distinct. However, some permutations do lead to identical states and shouldn’t be counted, for example and . is under the permutation of switching the first and second elements.

Right now (assuming this part of it works correctly) the algorithm only counts states that are unique under any permutation. This means that whenever a factor of is added to the total count, it should be multiplied by

where are the numbers of identical elements in . I’ve written a process for finding this factor which works correctly in a test project on a pre-determined set.

One more thing. In their article Black Hole Entropy from Quantum Geometry, Domagala and Lewandowski state that the case is unphysical and not allowed. This was very easy to integrate into the existing code. So, with all those changes (and a few other minor things) the results I get are

This is a great improvement over my previous results since the error (or disagreement with Corichi) is concave down. The errors I’ve gotten before this have all been concave up, and usually exponential-looking.

Debuggin is Hard

danielkatz — Mon, 23 Mar 2009 22:18:43 +0000

So, I finally got the algorithm running. By “running” I mean that it compiles and doesn’t crash its self or anything else. It still isn’t working right, though. This first graph compares results from my algorithm with those of Corichi, Diaz-Polo, and Fernandex-Borja (three guys who wrote an effective, although not efficient, algorithm):

In this figure and the next “count3″ or “count4″ refers to the version of my algorithm which generated the data. Noting that my algorithm falls short by an increasing amount I decided to see what would happen if I went back to the old counting scheme (i.e. not the one described in the previous post). Here’s what happened:

Drat. Now the algorithm’s prediction is too large by an increasing amount. The algorithm needs debugging before I can optimize it or add in the projection constraint.

Pruning and MPFR

danielkatz — Tue, 17 Mar 2009 14:21:17 +0000

Consider the case . The algorithm begins with and branches off from there, running a loop for each possible value of . At each of these branches, it again creates a loop for each possible value of . This scheme does not account for degeneracy of states. Let’s look at the values of through the first few branches. First, we get the states , , and so on. When things get a little more interesting, for now we get the states , , and so on. But wait, is the same state as . Had we continued writing out all the states with we would have also come across which is the same as . It seems as though we can prune the tree of possible states by having start out, not at zero, but at the value of . The figure below illustrates this for .

I’ve drawn out similar diagrams for and and this principle seems to hold, however, I haven’t been able to prove it (no idea where to begin). One nice thing about this finding (aside from eliminating degeneracy) is that it only requires small modifications to the code I already have.

Keeping track of how many states there are still (I think) requires a multi-precision data type. While we aren’t adding 1 to a large number anymore, may be many orders of magnitude smaller than the current total number of states. It’s a shame that GMP doesn’t support the ln function since the number we’re actually interested in is the natural log of the number of states. Also, GMP’s conversion to standard C data types is somewhat lacking. For example, if you want to convert a 100-digit precision number to a double, gmp_get_d will squeeze in as many least significant digits as it can fit. If it squeezed in the most significant digits, that would be fine for my purposes, but alas. Fortunately, MPFR is compatable with GMP and does support the ln function. Thus, the algorithm is almost done, except for debugging.

Looking Bright

danielkatz — Fri, 06 Mar 2009 22:11:06 +0000

The scheme described in the last couple of posts has a few issues. First of all, whenever it finds an eigenstate it shouldn’t add just 1 to the total, but to account for all of the possible m-states. This renders my large-number-handling method useless, but that’s ok since Chris got GMP properly installed on my computer. In the future, this product will be replaced by another algorithm for counting the m-states which satisfy the projection constraint, . Secondly, my algorithm as is counts degenerate states. Permutations of the j’s in an eigenstate should not be counted as new eigenstates. Taking this into account will likely bring down the computation time to something large but reasonable. I’m not quite sure how to implement it, though.

A Very Big Number

danielkatz — Tue, 03 Mar 2009 20:49:00 +0000

Apparently Matlab has a factorial function which is, according to their documentation, accurate at least to order of magnitude for integers over 21. By a simple calculation, then, if my program is to reproduce the results of previous authors (who used a maximum surface area of 550 ) it will need to run

loops. So for the algorithm to do its job in a week, each loop would need to take seconds. This is ironic since the smallest quanta of time according to LQG is ~. I wonder if maybe the authors of that last paper were being modest when they called their algorithm “brute force.”