[neild292]

When I review hands the double dummy does not always seem to appear (although sometimes it works fine). Is anybody else having a problem?

[smerriman]

Yes, it's not just you; the server that handles double dummy calculations has been very slow to respond recently and often times out.

[pescetom]

There are some contexts in which the mysteriously named 'GiB' button is not present, if that is what you mean.

I've not seen it fail to work since it was speeded up in the web client: but that relies upon some slick client side processing, so I wouldn't be surprised if it had problems on some platform other than my bog standard Chrome/Windows/PC.

[Edit] Just seen smerriman note about slow server. Yes I too have encountered that recently, but as I recall it hung and timed out, rather than merely being slow. Maybe I just hit an extreme.

[barmar]

The performance of double dummy analysis depends on how many constraints there are. Early in the hand, asking for analysis at the beginning of a trick can be slow because any lead is possible and there are many paths to analyze. In the middle of the trick there are fewer options because you have to follow suit, and later in the hand there are fewer paths, so things go faster.

So it's not too uncommon to time out when you ask for DD analysis on the opening lead.

[pescetom]

barmar, on 2024-May-15, 11:56, said:

So it's not too uncommon to time out when you ask for DD analysis on the opening lead.

Really, in 2024 with partition analysis?
I just tried it on opening lead using the bridgesolver add-on to Chrome, was unable to distinguish any delay between clicking and reply.
I imagine that is server side on a not particularly distinguished PC (thanks John), you are paying for quite different resources.

[smerriman]

It is true that the earlier in the play, the more time it takes to calculate double dummy. But that has absolutely nothing to do with what's going on here. Testing right now, about half of the requests I've made complete in 0.5 seconds; the others complete in 5.5 seconds. This is both early on in the play, as well as right near the end with only a few cards left - it's another server issue, rather than the time to compute the results.

This is in handviewer, of course, since when the one built into BBO was switched to JS that has had no problems.. might as well just update handviewer to the same system and save the server load entirely.

[barmar]

pescetom, on 2024-May-15, 12:56, said:

Really, in 2024 with partition analysis?

We're still using the same GIB double dummy solver we've been using since we added this feature. It's good enough, there's little reason to replace it.

[barmar]

smerriman, on 2024-May-15, 13:59, said:

This is in handviewer, of course, since when the one built into BBO was switched to JS that has had no problems.. might as well just update handviewer to the same system and save the server load entirely.

I think when we added this to the main client, we also put this on our "it would be nice to do someday" list for HV, but it's not high priority.

You've peeked at the HV code, so you know what kind of spaghetti it is.

[smerriman]

Oh, challenge accepted..

[pescetom]

pescetom, on 2024-May-15, 12:56, said:

Really, in 2024 with partition analysis?
I just tried it on opening lead using the bridgesolver add-on to Chrome, was unable to distinguish any delay between clicking and reply.
I imagine that is server side on a not particularly distinguished PC (thanks John), you are paying for quite different resources.

barmar, on 2024-May-16, 16:53, said:

We're still using the same GIB double dummy solver we've been using since we added this feature. It's good enough, there's little reason to replace it.

I wasn't suggesting there was anyting wrong with the GiB double dummy solver which I imagine is a clone of Bo Haglund's solver or similar, in any case at times it works in fractions of a second.
I was suggesting instead that having moved from in-house servers to hosting by IBM (as I understand from previous posts, at any rate) performance should improve rather than degrade and at least be consistent. I think smerriman was suggesting much the same when he said another server issue, unrelated to actual calculation.

[smerriman]

smerriman, on 2024-May-16, 17:20, said:

Oh, challenge accepted..

Well, that was remarkably simple. Just a few minor tweaks to the code and I've already got it working perfectly with the libdds JS wrapper without any calls to the server, making it way faster than now (and in fact it's much simpler code than it was using before since libdds returns all of the equal cards as part of the results).

Shouldn't be hard to tweak slightly further to have the GIB scores stay up as you click prev/next too rather than have to click it repeatedly, like it does in BBO, which I'm looking at next..

[smerriman]

Et voila.. a better handviewer.

[pescetom]

smerriman, on 2024-May-18, 15:05, said:

Et voila.. a better handviewer.

It works flawlessly and with barely perceptible delay, no need to reclick.

Maybe BBO could just hire smerriman ?

[barmar]

I never should have stopped obfuscating this code

[smerriman]

It must really be a nightmare knowing so many aspects of BBO are so easy to improve (GIB, forum bug, handviewer, ... ), yet Upper Management are so insistent on not allowing you to no matter what that you'd rather they were unfixable in the first place

[pescetom]

 smerriman, on 2024-May-21, 21:39, said:

It must really be a nightmare knowing so many aspects of BBO are so easy to improve (GIB, forum bug, handviewer, ...

... restore 'tricks' function in Dealergib, ...