> I have wondered whatever became of that massive initiative from Google to scan books, and whether that might be looked at as a potential training source, giving that Google has run into legal limitations on other forms of usage.
> The average centipawn loss shows a very slight advantage (less than 1 centipawn) for Gukesh. This connects well with the accuracy metric we got, which showed a negligible advantage for Gukesh.
As I understand, for average centipawn loss, lower is better. It kind of measures how much worse a player’s average moves are compared to the best moves suggested by the engine. Based on your data, Ding has a very slight advantage, not Gukesh. Here is an article from chess.com (https://www.chess.com/blog/raync910/average-centipawn-loss-c...):
> The term average centipawn loss (ACPL) represents how much “value” a player drops by making incorrect moves during a chess game. ..... The lower an ACPL that player has, the more perfectly they played (at least in the eyes of the engine assessing the game).
Thank you, you're right, I corrected this mistake.
As the difference in acpl is negligible anyway, it does not affect the overall conclusions and insights.
Indeed. I'm not normally one to write off an article over a small mistake, but that's such a fundamental mistake that it puts into the question the value of the rest of the analysis.
Nice article! I am about to reach the five-year mark of blogging (https://pncnmnp.github.io/blog.html) - I started during my second year as an undergraduate. Over the years, I've seen that:
* Keeping the blogging stack minimal helps. Using simple tools has helped me focus entirely on the content. For instance, I write everything in Google Docs and then manually convert it to HTML.
* It is beyond okay to feel stuck, especially with technical content. I often have several partially written drafts sitting around. Revisiting these drafts periodically helps me see them with fresh perspectives. Eventually, inspiration strikes, and I end up finishing those half-baked drafts.
* It helps to avoid obsessing over analytics. I have intentionally avoided analytics, and it has kinda allowed me to focus on topics that genuinely interest me, rather than writing solely to please some imaginary audience. It kind of gives me the freedom to explore obscure subjects, even if they appeal to only a small number of my readers.
Hey everyone, if you're looking for a more approachable guide on bitmap compression, I wrote a blog post on it this year: https://pncnmnp.github.io/blogs/roaring-bitmaps.html. It covers run-length encoding, BBC, WAH, Concise, and even Roaring Bitmaps.
That’s a good read, thanks! The history is interesting, but in practice, I’m wondering if there’s any reason not to skip it and just learn about roaring bitmaps?
Absolutely! For inspiration on how roaring bitmaps can be used in practice, check out https://roaringbitmap.org/. The blog post is part of a book I am writing on obscure data structures (https://pncnmnp.github.io/blogs/dsa-book.html), so explaining the history was a way to dive into the evolution of this topic and the limitations of each implementation, in order to motivate a SOTA.
A few years ago, a similar project was posted on HN that I thought was really cool too - E Ink smart screen puts a newspaper on your wall (https://news.ycombinator.com/item?id=22831323).
I was surprised to learn that each recommendation for preferences costs nearly 1 cent. From what I can tell, you don’t seem to be caching preferences. For example, each "Let's Go!" click on a show like say "Succession" generates some variation in the preference recommendations. My hunch is that if we ask LLMs to "over recommend" preferences based on the content you’re using (my guess is a mix of MovieLens, IMDb, TMDB, and Wikipedia) and do so in an ordered fashion (preference1 is a solid, but preference7 is a so-so), you could cache these results and strategically display them. For instance, when users choose to "fix" certain categories and get new recommendations for others, these "over recommendations" could help create variations without additional LLM calls. This could be repeated like N times until new categories require further LLM calls.
I am not sure if this would work with the personalized descriptions of recommendations part. I kind of love how they’re tuned based on my selected preferences.
I am curious about the design of the whole system. Fun project! Thanks.
Thanks, I'm glad you like it! That makes me very happy!
You're correct, I'm not caching the results right now. I determined that caching whole queries would not make much difference in the aggregate, since the vast majority of queries are unique. (However I also just saw that OpenAI added their own caching layer with lower prices for cached results, which is nice!)
However - the new Replace function was my first step toward fetching recommendations one-at-a-time - I agree that potentially opens up interesting new possibilities for caching and other things as well!
I think we are a bit alike in our views, but I have a slightly different take on it. I consider coding something like a Chip-8 emulator to be more fun and optimal. It gives a holistic view of the language - you get to work with simple graphics, sound effects, and gain a feel for memory operations and data structures, as well as control structures like conditionals, looping, and exception handling. If that’s not all - for beginners, it provides an introduction to virtualizing CPUs with registers, stacks, opcode handling, memory units, arithmetic/bitwise operations, and more. You’ll even learn a bit about concurrency and synchronization, and by extension, threading. Also, performance optimization.
I suppose a decent game project could achieve these things too, but the real fun of Chip-8 is in throwing different ROMs at it and debugging the issues until it’s perfect enough to play all your favorite games!
> Two of the important figures of System R were Leonard Liu, who was the person who hired me into IBM, and Frank King, who was the manager of the Relational Database project. ... One of the things that Frank thought was important was for our project to have a name so that we could make slides about it, write papers about it, and get some recognition. In order to get recognition for something it's good for it to have a name. So Frank called a meeting and said, "You guys are going to have to think of a name for your project." We thought, "Well, that's a waste of time. Don't bother us." But he persisted and said, "You guys are going to have to come up with a name." So for lack of anything else we said, "Well, we'll call ourselves System R." R stood for relations, or maybe it stood for research, or Franco Putzolu even thought it stood for Rufus, which was the name of his dog. It was a little bit of artful ambiguity what the R stood for, but that was the name of our project.
Also his earliest interaction with Larry Ellison:
> I’d been seeing some things in the trade press once in a while about a company called Software Development Laboratories that claimed to be developing a relational database system. I hadn’t paid much attention to it, but in the summer of 1978, I got a phone call. It was from a guy named Larry Ellison, and he said he was the president of Software Development Laboratories, and they were developing an implementation of the SQL language. Since we were in the research division of IBM, our philosophy of research was to publish our results in the open literature. As you know, many papers 22 came out of the System R project that were published in conferences and journals, describing the language and the internal interfaces of the system and some of the optimization technology and so on. The project was not a secret and, in fact, we’d been telling everybody about it that would listen. And one of the people that had listened and had read some of our papers was Larry. So he called me up and said that he was interested in implementing the SQL language in the UNIX environment. IBM wasn’t interested in UNIX at all. We were primarily a mainframe company at that time. We had some minicomputer products, but they really weren’t robust enough to manage a relational database, and there was little, if any, attention being paid to the UNIX platform. But Larry was really interested in the UNIX platform. He had a PDP-11, I think, that he was using as the basis for his SQL implementation, and he wanted to exchange visits with us and learn whatever he could about what we were doing, and in particular, he wanted to make sure that his implementation was consistent with ours so that there would be a common interface with compatible error codes and everything else. I was very pleased to get this call. I thought, “Terrific. This is somebody in the world who is interested in our work.” But I had some constraints on what I could do because of my position in IBM. I had to get management approval to talk to somebody on the outside, even though there was nothing secret about our project. Everything that Larry had access to was perfectly available in the open literature. So I went to talk to my boss, Frank King, and Frank talked to some lawyers—there were always plenty of lawyers in IBM that could think of a reason not to do most anything. Sure enough, they said, “You better not talk to other companies who are building products that are competitive with ours. We really don’t want you exchanging visits with these guys, so just tell them ‘Thanks for your interest, and have a nice day.’” So that’s what I did. I told Larry that, unfortunately, due to the constraints of the company, we wouldn’t be able to exchange information other than in the public literature. But that didn’t slow down Software Development Laboratories. They released their implementation of SQL. In fact, it was the first commercial implementation of SQL to go on the market. It was delivered by Larry Ellison’s company, initially called Software Development Laboratories, which later changed its name, I think, to Relational Software Incorporated, and later took on the name of the product, which was called Oracle. As you know, if you drive along Highway 101 in Redwood City and look at the giant 100-foot-tall disk drives over there on the edge of the bay, Larry’s had some success with these ideas. And rightly so. He brought a lot of energy and marketing expertise and a completely independent implementation, and was very successful with it, and had a major impact on the industry.
A few months ago, there was an interesting submission on HN about this - The Tragedy of Google Books (2017) (https://news.ycombinator.com/item?id=41917016).