[lycier]

---

[virgosrock]

lycier, on 2017-November-17, 23:34, said:

---

No surprise. GIBBO VERY often will do strange things when it knows contract is making.
It does not distinguish between MP/IMP/MB. Could not care less.
Poor design despite being a magnificent effort by the creator(s).

vrock

[The_Badger]

If you had a dollar for every time GIB did something silly....

[Stephen Tu]

virgosrock, on 2017-November-18, 04:28, said:

It does not distinguish between MP/IMP/MB. Could not care less.
Poor design despite being a magnificent effort by the creator(s).

This is not true. GIB absolutely plays differently at IMP/MP/total points. It will take safety plays at IMP/total pts that it would not at MP, it knows the difference and rates actions accordingly. Will also bid differently in some cases depending on scoring.

There are differences between bugs and "poor design", "design flaws", "inherent design limitations". You shouldn't sloppily conflate everything and blame weird, probably hard to reproduce runtime errors on poor design. That falls more into unforeseen implementation problem.

[johnu]

Stephen Tu, on 2017-November-18, 13:13, said:

GIB absolutely plays differently at IMP/MP/total points.

Maybe so, but differently doesn't necessarily mean correctly

[johnu]

Stephen Tu, on 2017-November-18, 13:13, said:

There are differences between bugs and "poor design", "design flaws", "inherent design limitations". You shouldn't sloppily conflate everything and blame weird, probably hard to reproduce runtime errors on poor design. That falls more into unforeseen implementation problem.

Like most software, GIB has all of your listed problems. You can quibble about how to classify them, or how much overlap there is between the different definitions. Poor design/design flaws/design limitations all contribute to implementation problems because the design problems make the implementation degree of difficulty astronomically higher to the point where BBO doesn't have the resources to getting close to everything right.

The comical failure to win a trick that should never be lost points to a clear design failure in the play engine IMHO.

[Stephen Tu]

PC GIB of many years ago doesn't exhibit such weird refusal to win trick. I don't agree that this weird behavior suggests fundamental design failure.

[virgosrock]

Stephen Tu, on 2017-November-18, 19:22, said:

PC GIB of many years ago doesn't exhibit such weird refusal to win trick. I don't agree that this weird behavior suggests fundamental design failure.

This sounds like software-ite balderdash. like lawyers for example, software-ites created their own confusing language. I really don't - like johnu - care what it is called. Something is badly broken and in my experience is unfixable by anyone who is not Ginsberg. No offense intended and hopefully none taken.
Maybe it does distinguish between MP/IMP/total(MB) but I don't see it in MB for sure.

vrock

[Stephen Tu]

Why bother with all your bug reports then? If you think it's fundamental design flaws and unfixable, then you were just wasting everyone's time. Quit playing against bots or stop complaining if you think it can't be fixed.

A lot of these things are fixable. Bidding definitions are fixable, just time consuming and feels never ending because there are so many auctions, and it's not easy to construct general rules to cover all the cases. Bidding is basically like a language, and languages are hard for computers. Especially one where it's all the same words, but drastically different meanings depending on the preceding sequence, and meaning has to be derived from context. Could completely new, ground up design do better with the bidding? Sure, but that would take a long time to build too, and do we really want them to stop fixing what they have for years maybe while they make a whole new bidding engine? Maybe open source tack could work.

The things that are really hard, and need design overhaul, are things like implementing defensive signaling. Or defending catering to single dummy declarers who can guess wrong. That kind of thing is probably beyond their current resources.

I don't know why some of you with no software background who have never seen the source code and probably wouldn't be able to make head or tails of it if you saw it feel comfortable making such grand pronouncements about the design. Do you second guess your doctors on medical expertise questions also?

[johnu]

Stephen Tu, on 2017-November-18, 21:54, said:

I don't know why some of you with no software background who have never seen the source code and probably wouldn't be able to make head or tails of it if you saw it feel comfortable making such grand pronouncements about the design. Do you second guess your doctors on medical expertise questions also?

I don't know about your programming background, but I've been programming since college and have made a nice living programming since then. That being said, you don't have to be a programmer to figure out that there is something inherently wrong in the design of the program when basic play and bid blunders are made that should have been straightened out in the first couple years after the program was released are still not working (or were working previously and have now been broken for a long time).

Maybe you can argue that the design is perfectly fine and the problem is that the program is so complex that the current programmers are breaking the program. IMHO, having a program that is so complex that changes that should be simple break the program is itself a design problem.

[Stephen Tu]

My comment was mostly directed at the non-programmers out there who like to take pot shots at the GIB programmers, saying things like they must not know how to play bridge and saying how easy it ought to be to fix things so why they don't do it already etc.

I still think you are doing a lot of speculation. Some of these weird defense ducking things were/are reportedly some sort of weird thing when GIB ran out of time or whatever and defaulted to playing low card. This seems to be a case of GIB originally not really being designed to run on a shared server farm with limited resources, and being adapted to that use. You can argue the programmers who adapted it didn't do a good job since these things are happening, but that's a different thing from sayiing the play logic designed was fundamentally borked from the beginning and has to be redone from scratch.

If it's so easy, why don't you write a better bot and sell it to BBO, I'm sure they'd love to have a better one?

[johnu]

Stephen Tu, on 2017-November-19, 04:38, said:

I still think you are doing a lot of speculation. Some of these weird defense ducking things were/are reportedly some sort of weird thing when GIB ran out of time or whatever and defaulted to playing low card. This seems to be a case of GIB originally not really being designed to run on a shared server farm with limited resources, and being adapted to that use. You can argue the programmers who adapted it didn't do a good job since these things are happening, but that's a different thing from sayiing the play logic designed was fundamentally borked from the beginning and has to be redone from scratch.

I will agree that a standalone program and a program designed to be played on a network are very different programs in many ways. So much that you could call them different programs. I never played with a standalone GIB and I don't really care if it played much better since I don't plan to play with a standalone GIB in the future. The fact is that GIB on BBO is not a standalone program and BBO has been using their version of GIB for a very long time.

Stephen Tu, on 2017-November-19, 04:38, said:

If it's so easy, why don't you write a better bot and sell it to BBO, I'm sure they'd love to have a better one?

Who said writing a bridge program was easy? It certainly wasn't me. Assuming you have the skills (I think I do), you would have to spend years programming pretty much full time (I don't and will never have the time or the desire) to get a solid program running. That being said, several other people have already done that.

Does BBO want to acquire another bridge program? BBO presumably spent a large amount of money acquiring the code to GIB years ago, and since then, has probably spent well into the 6 figures (maybe into the 7 figures) to upgrade and fix GIB for their robot games. There are other programs out there (ie Jack, WBridge, etc that are recent world computer bridge champions) with active developers that could be adopted for BBO but what would their owners want for compensation? I believe if BBO were starting out today and adding bridge bots that GIB would be towards the bottom of the list, but as of today, it's more of an economic question since BBO has so much invested in GIB.

[nige1]

I agree with Stephen Tu that Gib's problems are unlikely to be fundamental. Past versions had flaws but they seem to have been different. I think the basic design is good. It might be hard, however, for a maintenance programmer to envisage all the side-effects, when charged with an ad hoc fix. When hurriedly designing a heuristic fix for a specific bug, it might be easy to introduce a new bug. Regression testing of complex interactive behaviour can be difficult

[virgosrock]

Stephen Tu, on 2017-November-19, 04:38, said:

My comment was mostly directed at the non-programmers out there who like to take pot shots at the GIB programmers, saying things like they must not know how to play bridge and saying how easy it ought to be to fix things so why they don't do it already etc.

I still think you are doing a lot of speculation. Some of these weird defense ducking things were/are reportedly some sort of weird thing when GIB ran out of time or whatever and defaulted to playing low card. This seems to be a case of GIB originally not really being designed to run on a shared server farm with limited resources, and being adapted to that use. You can argue the programmers who adapted it didn't do a good job since these things are happening, but that's a different thing from sayiing the play logic designed was fundamentally borked from the beginning and has to be redone from scratch.

If it's so easy, why don't you write a better bot and sell it to BBO, I'm sure they'd love to have a better one?

I have pretty consistently maintained GIBBO is out of resources and this was pooh-poohed by the cognoscenti. It is the difference between vertical applications and horizontal applications where vertical is one instance of the app running while horizontal is several instances of the app running. The former requires expensive hardware.

vrock

[virgosrock]

nige1, on 2017-November-19, 16:42, said:

I agree with Stephen Tu that Gib's problems are unlikely to be fundamental. Past versions had flaws but they seem to have been different. I think the basic design is good. It might be hard, however, for a maintenance programmer to envisage all the side-effects, when charged with an ad hoc fix. When hurriedly designing a heuristic fix for a specific bug, it might be easy to introduce a new bug. Regression testing of complex interactive behaviour can be difficult

well said nige1. The fundamental effort was quite phenomenal. The buyer of the fundamental effort should have negotiated post-sales support with the creator. Or the buyer should have done it themselves or realized based on some level of beta-testing that this would be expensive to fix. I had hot arguments with the buyer 10 years ago when GIBBO started MoneyBridge. Buyer was arrogant and unhelpful.

As far as I am concerned all they had to do was provide recourse. They did not.

vrock