BBP Pairing when manually choosing a PAB

[jbfsoftware]

Hello Jeremy,

A Sevilla user created a situation where he preselected a PAB. When the pairing with BBP Pairings was done, some kind of mess existed. The player with the preselected PAB (marked 0000 U) in the .trf was considered the one with a highest score, and another player was rewarded the PAB.

Should this be considered a bug or should I not offer to allow these kind of .trf files? Anyway, the JaVaFo engine paired the same .trf as I desired.

See the attachment, where the intention was that player 17 got the (pre-assigned) PAB.

Best regards, JP.

bbpdut-test.zip

[jbierema]

Hello.

Thanks for letting me know about this use case. I believe at the moment, when BBP Pairings is trying to figure out whether a round has already been played or is the upcoming round, it looks for entries other than 0000 Z and 0000 H and equivalents. If it sees 0000 U, it takes this as an indication that the round has already been played. So what it is doing is pairing the second round.

I can change this behavior in a future version so that it also allows 0000 U in unplayed rounds.

The workaround for the time being would be to use 0000 Z in the TRF given to BBP Pairings (and adjust the player score accordingly). But this is of course not ideal.

[jbierema]

Hello, JP.

I tested JaVaFo's behavior. It looks like JaVaFo essentially ignores the 0000 U entry. That is, it assigns the bye according to the Dutch rules, even if that means giving it to a player other than the one specified.

Is that the behavior you consider correct? Or is the intention for the user to be able to override the selection of the bye?

Thank you again for bringing this to my attention.

[jbfsoftware]

Re: [BieremaBoyzProgramming/bbpPairings] BBP Pairing when manually choosing a PAB (#3)

Hi Jeremy,

Hello, JP. I tested JaVaFo's behavior. It looks like JaVaFo essentially ignores the 0000 U entry. That is, it assigns the bye according to the Dutch rules, even if that means giving it to a player other than the one specified. Is that the behavior you consider correct?

Officially the engine should do all the pairings and should do it correctly. The question probably is if it is allowed to preselect a pairing or assign a pairing or a bye manually. If it is allowed then both JaVaFo and BBP Pairings have an interesting behaviour. JaVaFo ignores the bye, and BBP Pairings counts the point score. Furthermore, JaVaFo 1.4 accepts the manual bye and pairs to my desire. If it is not allowed then I should in the software not give the opportunity to enter it in the first place.

However, I had various discussions with Roberto Ricca about it and he did not really complain about it not being allowed. The test I send you was an unlucky one where JaVaFo accidently chose the pairing I preferred. If I had assigned the bye to any other player (but the last) then I would probably have asked different questions.

Or is the intention for the user to be able to override the selection of the bye?

I would certainly prefer it to be allowed (thus consider a 0000 U as a user defined bye) but of course it are the rules that count. Maybe we should ask Roberto.

Best regards, JP.

Thank you again for bringing this to my attention. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jbfsoftware]

Re: [BieremaBoyzProgramming/bbpPairings] BBP Pairing when manually choosing a PAB (#3)

Forget my JaVaFo1 remark. Sevilla generates a slightly different TRF file for JaVaFo1 (not using 'U' but '+'), as JaVaFo1 didn't know about the 'U'.

Of course I can easily workaround the problem by exporting 'Z' instead of 'U' to BBP Pairings or JaVaFo2.

JP

[jbierema]

https://github.com/BieremaBoyzProgramming/bbpPairings/tree/manual-pab