After eight of the scheduled fourteen games, Carlsen now leads 5-3.
Today's match was sharp and short, compared to the epic game six marathon. In a queen-and-pawn endgame, Carlsen maneuvered crisply and won two pawns, and Nepomniachtchi resigned on move 46.
The first 5 games were all King Pawn games, but on game six Carlsen opened with the Queen Pawn.
On move 26, Carlsen exchanged his Queen for two Rooks.
Then on move 80, Carlsen exchanged one Rook for a Bishop and two Pawns, leaving Carlsen with Rook, Knight, and three Pawns, while Nepomniachtchi had Queen and Pawn.
The game proceeded, well into its sixth hour by now.
On move 113, a pair of Pawns were exchanged, and it was now Rook, Knight, and two Pawns against Queen.
The game proceeded, move by agonizing move, becoming (by far) the longest game of a World Chess Championship ever, I believe?
By move 130, Carlsen's first Pawn was on the fifth rank. By move 133, it was on the sixth rank, and by move 135 the second Pawn had advanced to the fifth rank to support it.
Nepomniachtchi resigned on the 136 move.
So six of the scheduled fourteen games are complete, and the score is 5 draws, 1 win.
Two more games, two more draws.
The championship is set for 14 total games, so it's still early days.
And, once again, not boring draws, not at all!
The first two games of the Carlsen-Nepomniachtchi 2021 World Chess Championship are now complete.
Two draws, but neither were boring!
Everybody expects this match to be very, very close. It's hard to recall two players as (seemingly) evenly matched as these two, perhaps at least since the years (decades?) of Karpov-Kasparov.
Watch the matches on chess24.com!
Why do I find old bugs so interesting? I'm not sure, but I've always really enjoyed tracking down a bug that turns out to have been present in the code for many years.
In this particular case, the code was in a program which was doing some randomized testing. We didn't need ultra-fancy cryptographically-secure randomization here, we just wanted to spread the testing out in interesting ways. So the programmer kept it simple (which is good!):
java.util.Random random = new java.util.Random();
Now we can get a random number for use in our test, whenever we want, quite simply, by just calling random.nextInt(), as in:
int randNum = random.nextInt();
For this particular test program, however, it's much more convenient to work only with non-negative numbers. Every program is different, but this particular test program didn't handle negative numbers in its other sections of the code.
So that's simple; we'll just use the absolute value of the random integer, so we change the above line very slightly:
int randNum = java.lang.Math.abs(random.nextInt());
And all was well. The test program was put into regular use, running regularly in our Continuous Integration test system, doing a variety of randomized testing after every commit. Over seven years, many trillions of invocations of this code were made.
But very occasionally (twice in the last year, which was just often enough for our automated testing tool to notice a pattern), the test failed, printing an (unfortunately) obscure message:
Row not found:-2147483648
Initially, the problem was not given much notice, lost in the cacophony of day-to-day work, but when it happened a second time, I was intrigued! Bugs which happen only once are always interesting, but bugs which happen twice, but with 9 months between them, seem to raise my hackles in strange ways.
Glancing at it, I was struck by -2147483648. As every programmer knows, this is java.lang.Integer.MIN_VALUE; that is, it is the smallest number that can be stored in a 32-bit twos-complement signed integer.
Hmmm... I said to myself. Does this mean that Math.abs() returned a negative number?
Off I went to RTFM, where I found:
Note that if the argument is equal to the value of Integer.MIN_VALUE, the most negative representable int value, the result is that same value, which is negative.
Of course! The absolute value of -2147483648 is too large to be stored in a 32 bit integer.
And, unfortunately, instead of throwing an exception at this point, the original builders of Java, nearly 30 years ago, decided to simply have Math.abs(Integer.MIN_VALUE) return Integer.MIN_VALUE.
Well, at least they documented it.
It turns out that nine months or so works out to be just enough that a one-in-four-billion chance actually occurs. And it appears that we must have increased our overall testing frequency, because until recently we weren't running enough tests to hit this condition often enough for the automated test analyzer to have two occurrences in its historical database to enable it to see a pattern worth notifying us about.
Time was on our side.
The problem was right there, hiding in plain sight! And yet, none of us saw it. Isn't that interesting?
Over the summer, I happened to watch The Last Magnificent, a fairly interesting documentary of celebrity chef Jeremiah Tower.
Although Tower's particular approach to cooking, and to the restaurant business, are not really my thing, I was interested enough by the documentary, particularly by its Bay Area history aspects, to spend some time reading Tower's memoir, California Dish: What I Saw (and Cooked) at the American Culinary Revolution.
The book is pretty much exactly as promised on the overleaf: it's a chatty and gossipy memoir of Tower's career as a Bay Area celebrity chef during, roughly, the period 1975-2000. Although there are recipes in the book, it's definitely not a cookbook!
Although the book remained interesting enough that I turned the pages to the end, the overall approach of Tower's memoir style can be boiled down to:
Event organizers, famous celebrities, patrons of fine cuisine, restauranteurs, politicians, businessmen, farmers, other chefs; all end up feeling the heat from Tower as somehow he bowls through madcap incident after madcap incident overcoming everybody else's mistakes and shortcomings.
Which is pretty much par for the course for a celebrity memoir, I guess.
Anyway, there is a lot of Bay Area history in California Dish, particularly cultural history of the period 1975-2000, which was a time of tremendous change in the Bay Area, and so even if I didn't learn much about which French wine to pair with grilled Tomales Bay oysters, or how to run a gourmet restaurant, I certainly had an entertaining few hours sitting at the table listening to Tower spin his absurd stories of the good old days.
Stabilization work on the Millenium Tower in San Francisco was halted in late July after the stabilization work appeared to be further destabilizing the structure.
Last month, the construction company announced that an improved stabilization technique had been successfully tested: Millennium Tower Fix Test Declared ‘Successful'
Fix designer Ron Hamburger told Millennium residents in a notice Thursday that the test was intended to “to demonstrate the Contractor’s ability to use improved procedures to install these casings without causing significant additional building settlement and tilting.”
“I am pleased to report that the test was successful,” Hamburger said. “Total building movement during the test was approximately one hundredth of an inch. This demonstrates that it is possible to install the remaining casings.”
He said a second test will follow, which involves installing a two-foot wide pile through an existing casing down to bedrock. “If this second test is successful, we look forward to a resumption of work and completion of the project.”
The city, however, is not so sure:
City officials, meanwhile, released weekly monitoring data showing that the building continues to settle despite a stop on work since Aug. 22, including an unexplained dip in early October indicating about the same settlement rate as measured before pile installation was halted in August.
Meanwhile, if you, like me, are the sort of person who can't tell the difference between Colma Sand and Old Bay Clay, here's a great overall backgrounder from Grady Hillhouse's Practical Engineering blog with a short video to catch you up on all that's been going on: What Really Happened at the Millennium Tower?
I'm certain this will not be the last status update I write about this project.