smerriman

It looks like what's happening is that on desktop, it's embedding all the stylesheets stored in the css_15 folder, while on mobile, it ignores all of these and embeds all the stylesheets from the css_2 folder instead. So copying bbo_handviewer.css into the css_2 folder instead should work (but the float + padding aren't needed in the copy as they need to be in separate columns anyway). My original message about seeing hv_iframe was me looking at the source on desktop; I didn't realise at that point it was different on mobile (where no hv_iframe is showing at all).

Still not seeing any relevant CSS output to mobile user-agents. But it looks like mobile-specific CSS is in https://www.bridgebase.com/forums/public/style_css/css_2/ipb_styles.css, so editing that file should work.

Hm, looks like it's only being output on desktop. I guess the forum must be using a different theme for mobile and so CSS has to be added to a different place to get it to show up there.

You have to upload it to another website and then copy the link to it here. Try imgur.com or similar.

Ooops, my mistake - I see you actually implemented the code already (thanks, super quick :)) but I had a typo - it's just: .hv_frame {max-width:100%;} since that's the iframe itself.

My smartphone has a 412x892 resolution. Due to some margins and padding, this means standard 400x300 handviewer iframes inside forum posts don't fit on the screen; South's bidding is always offscreen and inaccessible. There is some inline CSS on the forum pages: /* CSS: bbo_handviewer*/ .hv_frame { border: 0; float: left; padding-right: 0.2em; /* Separate diagram from text */ padding-top: 0.4em; /* Separate one diagram from another */ } Any chance you can add: .hv_frame iframe {max-width:100%;} Then on my screen it'll scale down to fit (it'll add whitespace underneath since it has a fixed height rather than scaling responsively, but at least it'll be readable).

When you know there's no downside in doing so, because your partner has 5 and declarer will overruff the next one, and you need to be on lead to send a heart through.

Which is why opener would have bid game had East made any attempt at a game try.

Still rather baffling how 9 people managed to not take 13 tricks in diamonds.

The former. If you have 12-14, you pass. Partner can find out about the club stopper later.

The same URL with https instead? Accessing an http:// PDF isn't dangerous in any way though, unless you're concerned that someone may be able to find out you wanted to read the PDF, which you've already let slip by posting in this thread :)

East comes down to that *after* the club is played. The reason you can make double dummy is that you can lead the jack of hearts, then finesse the 9 on the way back.

I'm not sure what you mean. GIB doesn't have a problem computing equivalence. We're talking about *distinguishing* equivalent cards - ie figuring out that playing a low card from equals here will make it easier for East to find the correct defense than playing high from equals. The only way to do that would be recursively - rather than just simulating deals from West's perspective, for every such deal, you have to move into another player's seat and then run a second simulation to see what ideas they might come up with if they had that hand. This recursion results in an exponential increase in the number of simulations run, and the time it takes to perform the calculations would immediately skyrocket.

Robot-related questions should go in the GIB forum, but this isn't actually related to robots so ignore that :) A Michaels cuebid occurs when the opponents open the bidding with 1 of a suit, and you bid 2 of the same suit: [hv=handviewer.html?a=1s2s!(Michaels)&d=e]200|200[/hv] If the opening bid was a minor, it shows both majors; otherwise it shows the missing major and one of the minors. But when your *partner* opens the bidding, and the opponents overcall, it is a completely different situation: [hv=handviewer.html?a=1h1s2s&d=n]200|200[/hv] Cuebidding here shows a good (invitational or better) hand with support for your partner. This is because it is standard to play that after the opponents overcall, jumping to 3♥ or 4♥ shows weak hands, making it harder for the opponents to work their way into the auction.

Oh that's right, I forgot the forum post where we concluded it always played the higher card. But yeah, distinguishing equals would require recursing into partner's hand which adds a significant amount of computation time. Far too much for GIB at least.

Sure. More commonly done with length in the opened suit though.

While aspects may have changed, 10 years ago, GIB had this rule about overcalling 1X with 1NT: - no singleton (or void) - no 5 card major (but can have 5 card minor) If 16-18 HCP, stoppers in X must be at least category 2 If 15 HCP, stoppers in X must be category 4: So with an extra point it would overcall 1NT, but with just 15, it requires a better club suit. Having decided not to overcall 1NT (agree or disagree), 1♠ seems OK.

0% - it'll always continue with the Q; I believe when choosing amongst equals it follows strict rules based on leading conventions etc. Sometimes that rule is to randomise (when following to a restricted choice situation), but in this case is high from equals.

Well, they are 100% equals after the J has been played.. sure, if West were human, you would play the 9 so that East would have choice but to overtake with the Ace, but that's not something that double dummy analysis could ever tell a robot.

If you're playing in a tournament, it will play the same card. But if it's just a main bridge club table, it doesn't use the same random numbers when making decisions, so might come up with different plays.

GIB doesn't make any assumptions that the lead is from a strong suit or that West must have the ten of hearts. Under that assumption, why GIB plays as it does is pretty straightforward. On the first round, it plays the J because that is guaranteed to be at least as good as the Ace double dummy; it assumes it'll know when to overtake on the second round (standard double dummy flaw). On the second round, it plays low because there are too many occasions when overtaking costs a trick at MPs (eg every time declarer has Txx). It comfortably finds the overtake at IMPs, where there's nothing to lose.

I would start: 1♥ - 1NT 3♦ - 3♠ which surely has to show the great diamond support and spade control. Whatever version of minor keycard you play after that, you're stopping in 6♦ due to the missing queen.

While they may be downsides of eg choosing to show your controls over blasting slam, they're not downsides compared to [cue always shows first round control] though. That approach really has very little going for it.

Heh, yes, I've read that paper a number of times :) I would have said that was a possibility, if it weren't for the question marks in the debugging output. If it were that type of bug, it would be unexpected / unpredictable - potentially appearing anywhere throughout the system. Given they're annotated with question marks, it implies the program *knows* they're not 100% valid results. I suspect it's more likely to be related to this part of the paper: This would make more sense - if it hits some time constraint, it marks searches that haven't finished with a ? as potentially not 100% correct. That's what I assumed they would be - some sort of bounds on the actual double dummy analysis - just not that they'd be so far off it's not funny. GIB also appears to not be programmed to have a fixed time limit per *decision* - but a total time limit per *hand* - which could be why it's still not able to run in time even for trivial end positions. But if that were the case, there's definitely improvements that can be made. (I do think some of GIBs flaws are down to users simply wanting a fast robot.) I have actually had a couple of emails with uday in the past, but it hasn't gone anywhere (yet?). I have a job which adequately pays me already; playing with GIB is far too much fun to be considered work!

I made a BW poll. Early days, but it looks like the robot made the right choice here.