Magnus is just so tenacious. From a lost position he snatched a victory. Take a look at the five hour mark (plus or minus) for the crucial moments of the key game: https://www.youtube.com/watch?v=s6ey5Up4S7w
A read-it-later app. Pocket, you had one job. Just one job. And for a while that was my killer app on mobile. But, as we see, the enshitification of the web continues.
"What began as a read-it-later app evolved into something much bigger. After Mozilla acquired Pocket in 2017, we invested in building our content curation and recommendation capabilities so people everywhere can discover and access high quality web content. While Pocket is shutting down, we will continue to invest in this promise—through the New Tab experience, our email newsletter, and more."
Here's an idea: Compensate any on-call work received during off hours at 10X the normal hourly rate. E.g., if my salary is $150K per year, then my hourly pay rate is about $75 per hour, so compensate my on call work at a rate of $750 per hour. Thus if I get a call at 10pm, log in to my laptop and work for 30 minutes to resolve the issue to a satisfactory level, then I pocket $375. That puts a financial incentive on companies to structure their on call protocols so that only the most important calls are handled. And I can envision variations on this theme. Different sorts of on-call disasters could offer bids for how much they're worth to fix based on some automated rubrick, and anyone on the ENG team could pick these up on a first-come, first-serve basis. Or various combinations of the above for a guaranteed backup person. But the companies should offer enough incentive to make it worthwhile. And this is in the companies' own best interest. To maintain a workforce that can think clearly during the normal work, to have a good reputation in the industry, to get good reviews on Glassdoor, etc.
Have a minimum of say, 60 minutes, and if that is exceeded, the issue gets escalated or deferred. If deferred, presumably to the next day shift, the cost is limited. If escalated, the second person must also defend the time spent. If management still doesn't trust their workers to be honest, then the company has other issues that tweaking on-call will not solve.
Many systems that pay hourly for task-based work like this deal with this problem by instituting a minimum number of hours of pay per-instance, which is usually higher than the expected time it takes to complete a typical quick task.
That way, by taking longer on any but the hardest issues, you are instead removing your ability to make more money on other, faster issues.
If you call out a master electrician to flip a circuit breaker, they are going to charge you a lot more money than for the half second it took to flip the switch.
Also, if the reason they have to come flip that switch is that they screwed up the job they did earlier that week, you don't get charged at all.
This thread is full of people acting like highly experienced trade workers are idiots who have never thought of how hourly work might be gamed for more money. All of this has been long since solved by the industries that actually operate this way.
> Many systems that pay hourly for task-based work like this deal with this problem by instituting a minimum number of hours of pay per-instance, which is usually higher than the expected time it takes to complete a typical quick task.
That's how it works for the occasional on-the-side server/printer tech jobs I occasionally take (long story short: I took a temp IT job years ago, resigned to go somewhere else, but the company never took me off their payroll so I get the occasional call to go install some number of printers or some number of servers/switches/etc. for some customer of HP or Dell, respectively). The usual rates are pretty abysmal for someone of my experience and skill level, but the 4-hour minimum means that if I can bang out one of these jobs in an hour or less I'm making more per-hour than at my day job. Nice bit of occasional money to blow on craps or penny stocks or shitcoins or whatever, and it keeps my fingers on various industry pulses.
> If on-call engineers were to receive compensation for each incident they resolved, it would incentivize them to intentionally build systems that fail so they could increase their pay by increasing their on-call load.” My guy, that is sabotage and fraud. You are hypothesizing a scenario where your subordinates are committing actual crimes. If somebody is doing criminal acts at work, fire their ass! Not to mention that anybody who deliberately self-inflicts on-call load is a goddamn idiot and should be sacked just on that basis alone.
It's a matter of degree.
Sabotage doesn't always mean instant breakage.
In "The Simple Sabotage Field Manual" we learn to slow down the organization by things like "Bring up irrelevant issues as frequently as possible", "Work slowly. Think out ways to increase the number of movements necessary on your job.", and "Do your work poorly and blame it on bad tools, machinery, or equipment."
If you are the person who consistently takes 10x longer than everyone else to fix issues, then someone has a conversation with you. It's not that hard.
Good suggestion and I can see the benefit for honest people, but unfortunately it’s as equally a system for financial abuse for others - sometimes enough to prevent people fixing things during their regular hours just to benefit at other times.
A good counter balance to this might be to offer even more compensation for no incidents, or otherwise well handled incidents that go on to squash types of that incident now and into the future.
Not necessarily, but agree that bad managers or organisations have a tedency to do this.
I guess the ultimate goal is to keep everyone happy right? Everyone has different ideals, you can probably assume the business wants everything to work by spending as little as possible, employees want to be paid as much as possible while enjoying their job. Striking that balance is always a challenge.
Some long haul truckers have a relatively workable pay scale. If it wasn’t for how far they expect you to drive in 24 hours, it might be considered good.
The general shape of it at least makes sense. You get paid when you’re on the road. More if you’re driving than if you’re parked, and more if you drive for more than your 40 hours a week.
That’s true for any hourly paid job. Employers can choose to fire those who don’t work efficiently enough. What they can’t do is not pay people for hours worked —and with tech it’s easy for them to tell how long you are logged in for, to avoid them underpaying you.
It is also in my interest to skip spotting bugs during code review so I can look like a genius when I fix them when they cause issues in production. Of course I don't do that because this is incredibly stupid and I have better ways to spend my time.
10x pay is significant. Personally, I would remediate asap even with $1500/hour on the line. I do have ethical standards.
But would I be as motivated to stop the root cause of the recurring issues that keeps giving me an extra $3k every shift? Well, I probably would, but my coworkers already need to be goaded into fixing root causes, and they're not getting paid extra!
In general, I think conflicts of interest must be handled carefully, and ideally avoided. Paying 10x wages when incidents happen is a clear conflict of interest.
Having overtime pay that is a multiple of regular hourly rate is mandatory is many countries in Europe. Are you saying that European software tends to be more obfuscated? (answer: it is not).
Employees are also subject to the Working Time Directive in EU countries which sets limits to the amount of overtime that is permitted in a week and in a month. Unfortunately in most countries it's full of loop holes.
Here's a FEN of the famous position from the Spassky-Fischer world championship match where Fischer weirdly played Bxh2 on move 29 and Spassky went on to win the game:
My father-in-law told me he watched that game live when he was a kid, and he just gasped when Fischer played Bxh2. (This is before engines or eval bars). Spassky did well to convert, but this is more about Fischer's mistake than Spassky.
This is the kind of blunder that you'd expect from a strong club player, not from Bobby Fischer. Although I understand that Fischer was brilliant but inconsistent, and to be fair, the last chess championship matches had a share of blunders.
It's almost a certainty Fischer didn't just "not notice" the bishop would be trapped, he just miscalculated further down the line (in fact if you plug it into an engine, it shows an equal evaluation)
It's one of the single biggest misconceptions ever, it gets repeated endlessly
> in fact if you plug it into an engine, it shows an equal evaluation
I don't think this is true, and engine evals aren't everything.
Two positions can have equal evaluations, but one can be trivial to play optimally and the other can be tricky and have a 10 move long sequence of "only moves" that are really hard to calculate. The latter is a much worse move, if you are not a chess engine.
Your last paragraph is the nicest capsule description of this very important and yet widely misunderstood computer chess concept I've seen. Thanks! I'm going to use this (probably poorly paraphrased due to my failing memory:).
That’s reasonable, but the question we really want to know is how difficult it will be to equalize, which is a measure of both the number of equalizing moves and how difficult it is to find them. If the only moves are obvious, it’s not as bad as you might originally think.
In other words the correct calculation of subjective difficulty is a dot product, not simply a count of the number of equalizing moves.
Yah, I'm not saying that a way to figure out the "difficulty of position" is to simply count the number of "only moves" or a volatility measure. There's sometimes a sequence of obvious trades to make, and that's hardly a difficult position.
It's hard to capture "obvious". One metric is how far you need to look down the eval tree to know a move is good, but even that is flawed.
Yes, it would be hard to avoid stepping into the scope of psychology to truly answer the question, because what might be easy for you might not be for me, even if we had equal elo ratings. (Trivial example, we might have equal elos but I try out a new opening you normally play.) You can probably learn a function to give a reasonable estimate though.
I prefer something kind of objective rather than looking at player strengths. The "depth needed to search to pick equal move" is my best answer, maybe revised to be "and isn't found with a couple of simple heuristics" to clean it up some.
you are replying to a comment that says "he miscalculated an equal position further down the line" and your point of objection is that he miscalculated an equal position further down the line?
If on move 29, you choose a move that is slightly worse but leave yourself in an extremely difficult position for you but an easy one for the other guy...
And then only on move 40 does the eval extremely diverge...
In my opinion, your real blunder was on move 29, not 40. Just because an engine could hold a position doesn't make it a reasonable move.
but that says nothing about what Fisher was thinking, so while your opinion is valid, it's not more valid than the comment you replied to, especially when your comment mimics the structure of his comment in the way I pointed out.
Fisher had said that he was seeking to complicate the game-- which is something that black wants to do, in general-- add uncertainty for both sides.
In practice, the move only added uncertainty for black. White faced easy choices, and black difficult ones.
I didn't disagree that Fisher thought the move was safe and miscalculated. Indeed, he didn't even miscalculate badly-- engines think they can hold the position.
I'm asserting that the move fails because it made the subsequent game more complicated for Fisher without imposing an equal penalty on his opponent. It made a bad miscalculation almost inevitable.
> Fisher had said that he was seeking to complicate the game-- which is something that black wants to do, in general-- add uncertainty for both sides.
This is not something Black wants to do in matchplay chess in general. Usually he would be happy with a sterile draw and hope to take advantage of having an extra white in the remaining games.
Fischer, on the other hand, liked to play for a win in every game. And IIRC this match gave the defending champion draw odds, so the challenger had more incentive than normal to take risks, even in game 1.
Still, I generally agree with the analysis of Kasparov etc in this position. Fischer didn't miss the game continuation and he didn't assess the piece-down position as offering Black his share of winning chances. He more likely missed that after Bxh2 g3 h5 Ke2 h4 Kf3 h3 Kg4 Bg1 Kxh3 Bxf2 Bd2! White still traps the bishop.
A better engine or running the engine deeper will show 0.0 (or you need to show there are alternatives for White before 40... f4?!)
Though this may be a situation where the weaker engine is actually more helpful in assessing the practical situation: +0.7 is a better reflection of the relative chances in a human game than 0.0.
Interesting, I never knew that. Engine does give +0.6 to Spassky, so the move slightly made Fischer's position worse (https://lichess.org/study/Eyl4uwTZ/TUx5RZIk) and the engine thinks f4 (on move 40) was the blunder.
I'm not qualified to analyse this, I read into it a bit more and apparently he was trying to complicate the game, the 1973 tournament book only marks it as ?!.
> the engine thinks f4 (on move 40) was the blunder.
The engine knows what move would be a blunder for computer play.
It doesn't know what move made the position impossibly tricky for a human to maintain for black.
Every game that I analyze, there's possible moves where the computer will trade endless complexity for one's side for a couple centipawn advantage. These are moves that a human should not play.
It's difficult to convey why computer evaluations are not always a good measure for whether a move made by a human is good.
I think the main point is that computers are so much better than humans at playing chess that what might be a reasonable move for them is effectively a terrible blunder for a human. It's like comparing a student driver with an F1 pro, and saying, "It's totally reasonable for the student driver to yank the wheel to the right when driving at 300 km/h, because an F1 driver would be able to recover from that." The point is that the student driver won't be able to follow up with near-superhuman ability to save the situation.
Of course, in this case, the engine doesn't think this is a particularly reasonable move; the evaluation just fails to show how bad it would be for a human-- even a near-superhuman chess player like prime Fischer-- to play.
> It's one of the single biggest misconceptions ever, it gets repeated endlessly
FM Roese here (best DWZ 2399).
I agree, figuring or even conjecturing that Fischer overlooked 30.g3 is totally insane. However he also did not saw the theoretical draw, this strikes me even more off.
He never opened up about his idea, so in all likelihood he calculated something very stupid.
> if you plug it into an engine, it shows an equal evaluation
They criticized this argument rightly, but many basically repeated your mistake in the process of doing so. All engines use some evolved adaption of iterative refinement, be it either "Iterative deepening" (of an alpha beta search) [1] or "UCT" [2]. If you post computer evaluations you should at the very least give the reported nominal search depth and the engine name and version, otherwise you are just asking for trouble. On computer chess fora [0] they often post the whole log file bluntly.
I don't think it was purely a calculation error, it was probably also an intuitive evaluation. Bobby was trying to complicate the game and create an imbalance, where there were still winning chances if misplayed by spassky, but obviously it was a bad evaluation and it backfired. I think he was in a bit of a mood and got reckless. He had been making a lot of demands leading up to this and threats to not participate, probably got frustrated by the drawn endgame and took a big risk. I don't think he ever really opened up about his reasoning to be fair, but was asked along the lines of "were you trying to complicate the game" and he said "something like that". After losing those first two games he demanded the cameras to be removed from the playing hall and started to play really well against spassky, so possibly a psychological aspect from the cameras were also to blame. Maybe he knew he was throwing the game and it'd make for an entertaining match... the guy was sort of insane
Maybe, and you can argue it was a bad practical choice, but the way it usually gets DESCRIBED is basically "Fischer missed bishop get trap lol". It's really braindead
{"moves":[{"p":"P","f":"d2","t":"d4"},{"p":"n","f":"g8","t":"f6"},{"p":"P","f":"c2","t":"c4"},{"p":"p","f":"e7","t":"e6"},{"p":"N","f":"g1","t":"f3"},{"p":"p","f":"d7","t":"d5"},{"p":"N","f":"b1","t":"c3"},{"p":"b","f":"f8","t":"b4"},{"p":"P","f":"e2","t":"e3"},{"p":"k","f":"e8","t":"g8","castle":"K"},{"p":"B","f":"f1","t":"d3"},{"p":"p","f":"c7","t":"c5"},{"p":"K","f":"e1","t":"g1","castle":"K"},{"p":"n","f":"b8","t":"c6"},{"p":"P","f":"a2","t":"a3"},{"p":"b","f":"b4","t":"a5"},{"p":"N","f":"c3","t":"e2"},{"p":"p","f":"d5","t":"c4","x":"P"},{"p":"B","f":"d3","t":"c4","x":"p"},{"p":"b","f":"a5","t":"b6"},{"p":"P","f":"d4","t":"c5","x":"p"},{"p":"q","f":"d8","t":"d1","x":"Q"},{"p":"R","f":"f1","t":"d1","x":"q"},{"p":"b","f":"b6","t":"c5","x":"P"},{"p":"P","f":"b2","t":"b4"},{"p":"b","f":"c5","t":"e7"},{"p":"B","f":"c1","t":"b2"},{"p":"b","f":"c8","t":"d7"},{"p":"R","f":"a1","t":"c1"},{"p":"r","f":"f8","t":"d8"},{"p":"N","f":"e2","t":"d4"},{"p":"n","f":"c6","t":"d4","x":"N"},{"p":"N","f":"f3","t":"d4","x":"n"},{"p":"b","f":"d7","t":"a4"},{"p":"B","f":"c4","t":"b3"},{"p":"b","f":"a4","t":"b3","x":"B"},{"p":"N","f":"d4","t":"b3","x":"b"},{"p":"r","f":"d8","t":"d1","x":"R","c":1},{"p":"R","f":"c1","t":"d1","x":"r"},{"p":"r","f":"a8","t":"c8"},{"p":"K","f":"g1","t":"f1"},{"p":"k","f":"g8","t":"f8"},{"p":"K","f":"f1","t":"e2"},{"p":"n","f":"f6","t":"e4"},{"p":"R","f":"d1","t":"c1"},{"p":"r","f":"c8","t":"c1","x":"R"},{"p":"B","f":"b2","t":"c1","x":"r"},{"p":"p","f":"f7","t":"f6"},{"p":"N","f":"b3","t":"a5"},{"p":"n","f":"e4","t":"d6"},{"p":"K","f":"e2","t":"d3"},{"p":"b","f":"e7","t":"d8"},{"p":"N","f":"a5","t":"c4"},{"p":"b","f":"d8","t":"c7"},{"p":"N","f":"c4","t":"d6","x":"n"},{"p":"b","f":"c7","t":"d6","x":"N"},{"p":"P","f":"b4","t":"b5"},{"p":"b","f":"d6","t":"h2","x":"P"},{"p":"P","f":"g2","t":"g3"},{"p":"p","f":"h7","t":"h5"},{"p":"K","f":"d3","t":"e2"},{"p":"p","f":"h5","t":"h4"},{"p":"K","f":"e2","t":"f3"},{"p":"k","f":"f8","t":"e7"},{"p":"K","f":"f3","t":"g2"},{"p":"p","f":"h4","t":"g3","x":"P"},{"p":"P","f":"f2","t":"g3","x":"p"},{"p":"b","f":"h2","t":"g3","x":"P"},{"p":"K","f":"g2","t":"g3","x":"b"},{"p":"k","f":"e7","t":"d6"},{"p":"P","f":"a3","t":"a4"},{"p":"k","f":"d6","t":"d5"},{"p":"B","f":"c1","t":"a3"},{"p":"k","f":"d5","t":"e4"},{"p":"B","f":"a3","t":"c5"},{"p":"p","f":"a7","t":"a6"},{"p":"P","f":"b5","t":"b6"},{"p":"p","f":"f6","t":"f5"},{"p":"K","f":"g3","t":"h4"},{"p":"p","f":"f5","t":"f4"},{"p":"P","f":"e3","t":"f4","x":"p"},{"p":"k","f":"e4","t":"f4","x":"P"},{"p":"K","f":"h4","t":"h5"},{"p":"k","f":"f4","t":"f5"},{"p":"B","f":"c5","t":"e3"},{"p":"k","f":"f5","t":"e4"},{"p":"B","f":"e3","t":"f2"},{"p":"k","f":"e4","t":"f5"},{"p":"B","f":"f2","t":"h4"},{"p":"p","f":"e6","t":"e5"},{"p":"B","f":"h4","t":"g5"},{"p":"p","f":"e5","t":"e4"},{"p":"B","f":"g5","t":"e3"},{"p":"k","f":"f5","t":"f6"},{"p":"K","f":"h5","t":"g4"},{"p":"k","f":"f6","t":"e5"},{"p":"K","f":"g4","t":"g5"},{"p":"k","f":"e5","t":"d5"},{"p":"K","f":"g5","t":"f5"},{"p":"p","f":"a6","t":"a5"},{"p":"B","f":"e3","t":"f2"},{"p":"p","f":"g7","t":"g5"},{"p":"K","f":"f5","t":"g5","x":"p"},{"p":"k","f":"d5","t":"c4"},{"p":"K","f":"g5","t":"f5"},{"p":"k","f":"c4","t":"b4"},{"p":"K","f":"f5","t":"e4","x":"p"},{"p":"k","f":"b4","t":"a4","x":"P"},{"p":"K","f":"e4","t":"d5"},{"p":"k","f":"a4","t":"b5"},{"p":"K","f":"d5","t":"d6"}],"opening":{"ECO":"E56"},"site":"Reykjavik ISL","event":"Spassky-Fischer World Championship Match","result":"W","type":"C","players":[{"handle":{"domain":"UNK","value":"Boris Spassky"}},{"handle":{"domain":"UNK","value":"Robert James Fischer"}}]}
Why replace PGN, which any decent chess player can simply read and follow (1 e4 e5, 2 Nf3 Nf6…), or if needed play out on a chessboard, with such a huge, unparseable monstrosity?
PGN [1] already supports all the features of BGN. The only complaint of not having long algebraic notation can simply be added as a comment, maintaining the simple readability of PGN. And then it works with the extensive ecosystem of existing tools.
Well... it's actually more parseable. Human readability is not the primary goal of BGN. It's precise capture of information esp. things ending up in PGN comments like %eval and %clk
Again, if you need long algebraic, a single comment in a PGN stores it, it is smaller than your format, is still readable. And it could use a shorter, faster to parse, more cache friendly, format than inserting a soup of useless braces, colons, quote marks, and other clutter that simply makes BGN a complete mess to parse.
:-) You visited the site so props for that. But I find it odd you call the soup of braces, colons, and quotes a complete mess. That's JSON. As in industry standard everyone-uses-it JSON. If you're not familiar with the space I can see why PGN has more human readable appeal.
I've written some of the high perf JSON code used in industry, so I am well aware of it. A main reason companies (and me, and many others) work so hard on making high speed readers is to get them withing a fraction of the speed of reading many native formats.
For example, converting a 32 bit float to text for JSON, then parsing it back in later, is orders of magnitude slower than simply using the binary one. And in many languages it's not bit exact, so it creates a giant mess. I've worked on getting many projects that try to roundtrip floats correctly since the JSON layer was breaking projects (hint: C++ has precisely one, corner and rarely used, format/parse that promises to roundtrip, and this is not even guaranteed across compilers or systems or versions - only one compiler version. To do better you import your own Grisu or successor and implement tests to catch system errors.... or switch to hex format, which is much nicer). So yes, I have done tons of JSON, but I get called mostly to fix/remove/mitigate JSON since groups and people know I am the guy that fixes idiot-added JSON where it breaks things.
Next, JSON is also an order of magnitude bigger than many other formats. There's good reason AI models are not JSON, video is not JSON, etc. JSON slows down major pipelines because of the size increases and slowness of formatting and parsing compared to simply using a smarter format. Junior engineers love JSON because they don't understand the pros/cons and can jam it everywhere. Many projects I've been called in to speed up were slow due to "JSON all the things!".
Next, I've also written high performance chess engines (and all sorts of custom searching engines to do stuff like find proof games, do various things related to retrograde analysis, and construct richer data for endgame tables for my own analysis, some published...), with all the bells and whistles and bit tricks and used things like Z3 to invent better magic bitboard constants, which also improved state of the art there. So I also know that space.
Naming your format BGN for "Better Game" Notation (?) to replace PGN, when your format breaks pretty much every thing PGN was designed to be used for, and is widely used for, is simply ludicrous. It's not a better game notation - it's an unusable game notation. You want it to be a searchable, queryable format, of which many already exist, yet again yours is going to be orders of magnitude slower since you chose JSON, replacing at most bytes of chess move info with variable length (thus ensuring you cannot random access information but must parse the 1000+ characters before move 50 to see move 50...) 25+ to ~40 bytes each. Your format is simply a terrible data format, solving nothing.
And most big engines and certainly all big chess database software support all the major formats.
Did you look at either the motivation for PGN or for existing chess query supporting database format before you made this? Or in the intervening 5 years?
So I don't think you have improved anything over the previous technology. There's a reason you have zero downloads over 5 years.
Here's a hint: if you're going to make something claiming to be a better X, then you should reproduce what X was designed for, and then, and only then, add features.
> As in industry standard everyone-uses-it JSON
That's PGN. As in industry standard everyone-uses-it PGN. If you're not familiar with the space I can see why JSON has more human unreadable appeal.
UGN -- unusable game notation. That has a ring to it.
UGN was designed with SPARK and AWS S3 pbzip2-aware threading JSON readers in mind. For an analysis of a year's worth of lichess games -- over a billion, maybe more -- I believe UGN is a good solution. Try bucketing clock time vs. blunders or castling analysis or opening vs. ELO on 1 billion PGNs. Not simple search; aggregation. In the end, UGN is an information architecture; JSON is used as a convenient implementation/representation but it happens work well with SPARK and S3. And you can reliably use jq or even grep on the same UGN files. I didn't feel the need to create yet another binary format.
> Try bucketing clock time vs. blunders or castling analysis or opening vs. ELO on 1 billion PGNs
No one uses PGN for that. Strawmen are easy to defeat.
Heck, I can crush your example by simply using a proper binary format, fixed length records, and reading flat files directly into memory, all for about 1 hour of coding to transcode your format into something designed for analysis.
Better yet, compare your examples to any of the current best chess DB formats. They all support all your query examples a massively more. And are properly designed, tested and improved over decades of actual use, by professionals and researchers alike.
People have been doing billion+ chess game analyses for well over a decade. Chess.com added 1 billion games in Feb alone two years ago , they just passed 100 billion games total in Jan, they regularly run all sorts of analyses on all the games, and provide datasets and services to researchers for similar work.
It's hard to improve on what you do not understand. If you spent some time understanding the space you may be able to improve on it. Until then a lone wolf, unaware of what is in the space, will simply de-invent a worse wheel.
reply