Replace MVV/LVA by MVV

[Stefano80]

Passed STC

LLR: 3.71 (-2.94,2.94) [-3.00,1.00]
Total: 64363 W: 12299 L: 12214 D: 39850

and LTC

LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 69976 W: 11056 L: 11011 D: 47909

Reasons to commit the patch:

1. In the MVV/LVA paradigm the LVA part does add very little ELO
2. Removing LVA reduces both code line count and code complexity

Regarding 1)

• Simplification test passed with positive score, both in at STC and LTC. Comparing with results with different sprt simulators it should be something between -1 and -0.5 ELO.
• Tabled and tuned MVV/LVA failed STC with identical run length, tuned MVV/LVA being practically identical to MVV/LVA + some random walk of parameters
• LVA alone failed STC miserably
• Nevertheless, there must be some part of LVA which is useful (or which correlates with something useful), since MVV/MVA failed more clearly than tabled or tuned MVV/LVA.

[zamar]

So this patch is all about replacing MVV/LVA with MVV/Pseudo-Random.

I'm willing to hear arguments - both Pro and Against...

[jhellis3]

Well, we don't commit patches that add code for 0 Elo gain....

[mcostalba]

The patch is commitable for me. It removes a lot of code and especially it debunks the LVA myth....I am not fully sure that LVA is useless because it is a decades old well established concept, but SF development has a dynamic nature, things always evolve and what now we put out, maybe will reappear in the future, maybe under a different form.

[mcostalba]

@Stefano80 please update also the comments of the scoring function.

[glinscott]

Very interesting! The MVV/LVA idea is so logical it seems crazy that it doesn't help. But the proof is in the results.

I'm on the fence on this one, as it's not a huge simplification, and it's a sensitive area of the code. I'd be okay with merging though.

[Stefano80]

@marco: I updated the comments, I hope this is fine.

@joona: > So this patch is all about replacing MVV/LVA with MVV/Pseudo-Random.

More precisely MVV/LVA/Pseudo-Random with MVV/Pseudo-Random. Before you anyway had to made a pseudo-random decision if you had 2 different X:Y captures. Now you make it already for anything:Y

@gary: > The MVV/LVA idea is so logical

Is it? In MVV you first check whether you can capture the queen: if you can it does not really matter whether you capture with a rook or a minor piece or a pawn. You will probably get a cut-off. Then you check for rook captures: again, it does not really matter wheter you capture with a minor or a pawn. I think the point is that LVA part of MVV/LVA comes into play at the end of the move list, where you hopefully already have stopped searching.

[lucasart]

@glinscott: I don't understand how this is a "sensitive area of code". I think it's a completely trivial piece of code, that can easily be modified later. As Marco says, a replacement for this LVA may come back in a different form.

@zamar: I don't understand how being dependent on the move generation order, is a problem. SF already depends on it far more than we imagine, and it's never bothered anyone. If we wanted to "fix" that non-problem, we should start by getting rid of piece lists, using lsb() in movegen etc. But it would be a waste of time (would take some work, add code, and provide no elo gain).

[vdbergh]

The reason why the LVA part does not help is that most captures yielding a cutoff are captures of a hanging piece. So it is does not matter what the attacker is.

@zamar: randomness is not necessarily bad. There many important algorithms which depend on randomness to work correctly or to have predictable performance.

[zamar]

OK. It seems that people are strongly in favour of the patch and there is nothing badly wrong with the new approach.

Patch approved.

[Stefano80]

Thanks for the constructive discussion!

Is there anything I must do?