[tobato]

I use a couple of softwares such as Wbridge, Bridge Captain, etc., to do DDS analysis.
I find that the par calculating is always very fast. The par result will almost immediately show up after I push the "Calculate Par" menu button.
But for the same deal, sometimes it takes quite a long time to calculate which card is the best one to play for the current position.

For now, I think that par calculating and solve-hand ("best card to play") calculating should both use Alpha-Beta search method, and the former should take longer time than the latter, because the former takes the best cards to play for all positions into consideration and the latter only considers one(the current) best card to play. But I am not sure.

So, I have got this question.

This post has been edited by tobato: 2024-June-13, 01:04

[smerriman]

It can't be faster. In fact Bridge Captain (like most bridge software) uses Bo Haglund's DDS library, and the par function there directly invokes the DDS functions.

I could see it *appearing* to be faster, because par can be calculated as soon as the deal is entered (and could therefore be precomputed), while a double dummy score may need to be computed on the fly depending on what the position is when you ask. (Additionally, that might be a position that was pruned in the original par calculation).

[P_Marlowe]

Hi,

There are equal (touching) cards.
if you compute the par result, you may only calculate for one card per group,
while if you look for result depend on the card lead, you may calculate per card.

Sometimes you only want to get the result for one specific lead, and not for all.

Just a guess.

This could be tested, if you have hands, that, do not contain touching cards.

With kind regards
Marlowe

[DavidKok]

When I run dealer on my own PC the par calculation is indeed very fast - it has been optimised quite well, and can be effectively be calculated in parallel on up to 9 threads. The branch-and-bound also seems very efficient. This makes it faster than calculating the number of tricks for all 20 positions (4 dealers x 5 strains) individually, but not faster than calculating from a single position. I think invoking the par function this way is about as quick as asking for 6-10 different configurations of 'numbers of tricks' (which can also be parallellized, just not as well), but it's been a while since I looked into this.

Unfortunately the exact version I'm using does not communicate the best card to play nor the par contract, only the par score. As far as I know this is an interface problem, but if a higher level language has to reconstruct which card or contract is correct from just the scores it might well be much slower (and indeed this is something I've struggled with - finding the par contract rather than the par score is really slow, simply because the DDS is opaque to the dealer scripting language).

[P_Marlowe]

DavidKok, on 2024-June-13, 00:22, said:

<snip>
The branch-and-bound also seems very efficient. This makes it faster than calculating the number of tricks for all 20 positions ...
<snip>

This is certainly another possible reason, you can stop the calculation earlier, you dont need to finish, if you are only looking for par.

[tobato]

Thanks!

I feel that you are right, my friends.

So far, my understanding of your answers:
The Alpha-Beta search algorithm skips some useless branches due to pruning and branch-and-bound while calculating par. (I think this is related to "touching cards" which was put forward by Marlowe.) Therefore, a specific position's corresponding branch may not have been computed yet when the position is reached. Of course, precomputing, optimization and multithreading in addition.

I can not understand some of your words and I will work on understanding them.