idea for generating defensive problems

[richard]

Lots of good comments here.

Argentum's suggestion is fairly easy to implement within the current generator, in fact I'm not sure why these type of problems are not being seen already (i.e. problems where one side is losing and there is a possiblity to get back to even), I suspect the "winning advantage" checks are leading these to be considered non-interesting positions, but this should be fairly easy to adjust for.

I agree that the defensive problems of the chesseric type would be great do have (especially as I see my son improve greatly on seeing his own tactics , but if anything getting worse at defending against tactical threats). I'd already added defensive tactics to the todo list after chesseric brought them up last time.  Unfortunately these don't fit in well to the current generator design so will essentially require a new generator specific to these types of problems (cyanfish's ideas sound like workable options).

I've mentioned in a few threads that the current generator has really reached the end of its life in terms of having had one hack to many added to it , thus reaching a position where new improvements are getting harder and harder to add.  I'm currently trying to avoid making anything but important bug fixes to the current generator, so changes like the above will have to wait for the generator rewrite which will provide a more modular base for both the current generator and generator variations such as a defensive tactic generator.  As there are a number of tasks pushing back the generator rewrite at the moment it will still be a while before defensive tactics will start appearing.

Regards,
Richard.

[argentum]

'Argentum's suggestion is fairly easy to implement within the current generator, in fact I'm not sure why these type of problems are not being seen already (i.e. problems where one side is losing and there is a possiblity to get back to even), I suspect the "winning advantage" checks are leading these to be considered non-interesting positions, but this should be fairly easy to adjust for.' 

I would guess that if the code is looking for certain absolute value that should be exceeded it would discard situations where there is good evaluation jump but the final position is equal (ie. evals near zero).

If the code would be checking evaluation jump which exceeds for example 2-3 and the final position evals for example at least -0.3 (or 0.00 or near zero anyway) you would have gone from losing position to about equal or not clearly losing. 

[richard]

The original code took very little notice of absolute evaluations and almost everything was treated in terms of the deviation from the "pre-tactic" evaluation. This worked well in some situations but it was also the reason why such a bad job was done on "winning alternative" disambiguation in the older versions of the generator.  There are a number of absolute values used in the generator now but I'm still surprised that prior to this there still didn't appear to be these types of "saving" moves in the set, there was probably a filter somewhere that was having an unforeseen impact on these types of problems.  I do filter problems which end up "losing" for the user which will filter all the <0 eval problems , but I'm still surprised there were not many (or even any) -3 to say +0.5 problems.

What this really highlights is how hard the current mess of code is to analyse and that a rewrite is well overdue :-)

Regards,
Richard.