when is a move a blunder?

[Kotlov]

That would be be unambigous and logically at least. Alternatively write simply ?(-3.0).

exactly ))

[BeyondCritics]

A blunder is a move that changes the theoretical outcome of the game or makes it notably easier/harder to achieve. Easiest way to look at this is on a human scale of annotations

+- trivially won
+/- winning but still have work to convert it
+= advantage but probably drawn
= equal
=+
-/+
-+

if it changes the game between these 7 categories, it's a blunder. In terms of machine scores you might need to make a mapping function that takes into account game phase as well as score since engine scores with an advantage tend to increase towards the endgame to represent progress += (ending) tends to be a wider range than += (opening) (also there's some selection of endings where engine scores are just going to be too optimistic - doesn't necessarily mean they'll play them wrong, just that an attempt to draw a conclusion that +1 (for example) is +/- might be erroneous at times)

Sorry no, "+/-" means simply that white "has an (definite) advantage".
And "+-" only means, that white "is winning".
"+=" means that white "has a slight advantage".
Look that up in nearly any opening book.

For a serious chess player, feelings and experience are highly important, the basic thing. They surely wouldn't like it, to be fed up with distorted symbology. I avoid them like a plague.

Furthermore, your system as it is described, does flatter around the borders of your categories. That may lead to erratic annotations in volatile positions or positions that coincidentically are lying exactly on one of your borders.

I like your suggestion, to take game phase into account. Kai Laskos estimated once the winning chances, depending on evaluation and move number.

[BeyondCritics]

The term "blunder" is historically simply a derogatory label for a suboptimal move in chess. It implies an aesthetically or instructive judgement of the annotator.
Historically a blunder is not even required to change the theoretical game outcome, but very typically does.

I suppose you mean something like "in human terms" when you say "historically".

My intent was to convey my observation, that the meaning of this term has shifted towards the more simpler evaluation range interpretaion, given by contemporary chess software.

I would agree with Kevin that blunders normally are thought of as being moves that change the likely outcome of the game or the difficulty of achieving the outcome.

This system, as it stands, could lead to flattering around the borders and in turn meaningless blunder annotations. You better take into account the amount of equity loss, as everyone else.
Furthermore, as a matter of fact, this isn't the normal interpretation of the term blunder, as i have already mentioned. A blunder is normally thought of as an "easily avoidable" error.

since typically no two engines can agree on their precise meaning. Your annotations would be unportable.

I'd say it is exactly the other way around. No two engines will agree on the precise meaning of +1.23 and for a human player it means even less (unless the player has done a lot of analysis with the same engine). But if the annotating software has been finely calibrated to distinguish between +/- and += in the way that a human would, then the annotation is portable between engines and humans.

IF annotations were calibrated, they were portable at least. Unfortunately they aren't calibrated and therefore there are not portable and even poisonous. I avoid those annotations, therever i can.

[jhaglund2]

Hi,

When is a move a blunder? How can I programmatically find this?

ChessArtist calls a move a blunder if the score goes down 1,5 pawn. But that doesn't always apply, does it? If all other moves have scores even lower, than the chosen 1,5 pawn is not a blunder is it?

Maybe a better question would be... when is a move not a blunder?

A blunder is mistake move that causes a loss of material or position from a move that's clearly evident by the opponent's next move. It is marked with a double question mark "??".

Some really good examples: https://en.wikipedia.org/wiki/Blunder_(chess)

[syzygy]

A blunder is a move that changes the theoretical outcome of the game or makes it notably easier/harder to achieve. Easiest way to look at this is on a human scale of annotations

+- trivially won
+/- winning but still have work to convert it
+= advantage but probably drawn
= equal
=+
-/+
-+

if it changes the game between these 7 categories, it's a blunder. In terms of machine scores you might need to make a mapping function that takes into account game phase as well as score since engine scores with an advantage tend to increase towards the endgame to represent progress += (ending) tends to be a wider range than += (opening) (also there's some selection of endings where engine scores are just going to be too optimistic - doesn't necessarily mean they'll play them wrong, just that an attempt to draw a conclusion that +1 (for example) is +/- might be erroneous at times)

Sorry no, "+/-" means simply that white "has an (definite) advantage".
And "+-" only means, that white "is winning".
"+=" means that white "has a slight advantage".
Look that up in nearly any opening book.

Keven simply (and correctly) translated the symbols to his theoretical outcome and easier/harder model. So not sure what there is to pick on here...

Furthermore, your system as it is described, does flatter around the borders of your categories.

What does that even mean?

[kbhearn]

For a serious chess player, feelings and experience are highly important, the basic thing. They surely wouldn't like it, to be fed up with distorted symbology. I avoid them like a plague.

Furthermore, your system as it is described, does flatter around the borders of your categories. That may lead to erratic annotations in volatile positions or positions that coincidentically are lying exactly on one of your borders.

I like your suggestion, to take game phase into account. Kai Laskos estimated once the winning chances, depending on evaluation and move number.

Putting aside the semantics about how best to describe the symbols because i don't think we disagree at the core, just view it through different eyes...

The first question is who does an auto-annotater target exactly? I don't feel the serious chess player is the answer here anyways... Surely the serious chess player would like to interact with the engine at least in reviewing the game not just get the cliff notes.

Regarding your concern over borders of discrete zones, i agree something would need to be done about that such that a flutter back and forth over the border doesn't trigger undo chains of annotation - my point was mostly that a X centipawn gap is a lousy way to treat a blunder as well - if there's a complicated mate or a simple win after winning a rook it's surely not a blunder to take the rook. Perhaps the conversion to percentage winning probability and using a percentage gap that someone else suggested might be the best version of using existing strong engines in an annotation program.

Which brings up another point : existing strong engines make a lousy platform as a provider of annotations. They're developed to win and the only feedback they provide is a score and a PV. There's not really a good way to extract volatility, or critical subvariations from them which certainly aren't just the top N multipv lines - many of the needed variations might be really bad scorewise but are the things you had to see the refutations in order to play the move in the first place - the sorts of things a human annotator would know (based on the level of their audience) need to be pointed out or not. While you could always go with the defense that you can always go back and check with the engine if you want to know more, you don't know if you should want to know more from the engine's output - you're given an alternative move and a credible looking PV.