[hrothgar]

Sigi, on Mar 23 2006, 03:28 PM, said:

Easier but eventually not powerful enough.

Well, in theory it will be as powerful as a completely dynamic approach but your bidding trees will grow huge given a sufficiently complex system.

Add in conditional logic:  now you will possibly have many of these already complex sequences several times.  As a simple example take a defense to 1NT, where the sequences might be generated by a script but ultimately differ in (possibly only a few) spots depending on the strength of the opening which is defended.

There is already a fuss being made about slow login times and that the profile shouldn't become larger because that will make it even slower yada yada.  I don't want to know what people will think if half of BBO starts transfering 500kB convention cards (these will eventually having to be received by every opposing pair in a tournament).  Compression might help a lot here, however.

Probably Fred indeed should spend his developing time with other issues than this one.  I would, however, like to see an API to Full Disclosure so one could maybe write a plugin that will allow scripting -- let's call it the dynamic convention card API.

NB the file format for Full Disclosure is documented already (it's fairly trivial for that matter).

--Sigi

I took the liberty of hijacking this thread in the (vain) hope that it might be possible to preserve a discussion regaridng partnership agreement in the parent...

I don't disagree with anything that you're saying... I'd love to see scripting support inside of Full Disclosure to simplify my efforts coding MOSCITO BSS files. However, it would be insane to prioritize this type of work ahead of any number of other possible projects. Do you really think that scripting is remotely as important as improving the messaging system or enhancing mechanism for creating team games?

Even if we limit our discussions to the FD application itself, I can thing of several feature set enhancements that I consider MUCH more useful then scripting support.

1. Conditional logic: I consider this a fundamental building block for a number of other functions. In an ideal world, we'll be able to create a library populated with good defenses to unusual methods (transfer openings, multi 2♦ etc)

2. A Graphical User Interface. Imagine if the primary User Interface for Full Disclosure was a graphical convention card that looked something like http://web2.acbl.org...y/newss1131.pdf Players using standard systems like BWS or SAYC could simply click on a checkbox to enable a Lebensohl or a Capelletti module. (Its possible that different bidding system families would require different front ends)

3. An alert system. As I noted in the past, Full Disclosure is a system for announcements. However, the system could be used to create an alert structure as well. It would be very easy to use FD to automatically create an alert any time a pair made a conventional bid. For that matter, you could generate alerts any time that a pairs bid didn't correspond to the definition contain in the SAYC FD file. The possibilities are endless.

[Sigi_BC84]

Quote

I took the liberty of hijacking this thread in the (vain) hope that it might be possible to preserve a discussion regaridng partnership agreement in the parent...

Certainly the right move :-).

Quote

I don't disagree with anything that you're saying...    I'd love to see scripting support inside of Full Disclosure to simplify my efforts coding MOSCITO BSS files.  However, it would be insane to prioritize this type of work ahead of any number of other possible projects.  Do you really think that scripting is remotely as important as improving the messaging system or enhancing mechanism for creating team games?

I fully agree when you say that the inclusion of certain other features is a lot more important than improving FD (at this moment). Actually the two examples you have given (messaging and team games) occupy the two top slots on my BBO wishlist. This does not keep me from posting ideas on how FD should be improved (since I have already posted that I want more team features and a different chat GUI).

Now that we have that out of the way let me say this: In my eyes, the current incarnation of FD is not much more than a proof of concept (both technically and also -- to a lesser extent -- functionality-wise). The GUI can be seen as a bad joke (sorry, Fred) and many ambitious users interested in making FD cards fail due to that. Consequently I think that based on the idea presently embodied by what we have with FD, something much bigger, better and mightier needs to be developed, possibly outside of BBO for the priority reasons already mentioned. To do that, one needs a published and documented API.

Now please nobody start the Open Source discussion once again. All I'm saying is that unless there is an API into the appropriate parts of BBO, not much will happen on this front according to my evaluation of the situation. Now Fred might answer "forget it, pal", which is fine, but I think in that case we won't see a disclosure revolution happen too soon in the future.

Quote

Even if we limit our discussions to the FD application itself, I can thing of several feature set enhancements that I consider MUCH more useful then scripting support.

You make it sound as if scripting support was an "add-on" to the static datafile functionality we have at the moment. Actually my ideas stretch a lot further, in that I'd like to replace static files completely by some kind of specification language, of which static trees would be a subset.

Quote

1.  Conditional logic:  I consider this a fundamental building block for a number of other functions.  In an ideal world, we'll be able to create a library populated with good defenses to unusual methods (transfer openings, multi 2♦ etc)

A very good idea that you (rightly) have proposed several times already. I think this would naturally be a part of the specification language I have in mind.

Quote

2.  A Graphical User Interface.  Imagine if the primary User Interface for Full Disclosure was a graphical convention card that looked something like http://web2.acbl.org...y/newss1131.pdf

I understand what you have in mind. In my eyes, the FD GUI needs to change radically anyway (into the direction of Bridge2Symmetric's), and what you are suggesting would probably be provided by System Construction Wizards or special purpose plugins for the system editor.

Quote

3.  An alert system

This would also be part of a well designed system specification language. Maybe one would have a special property for "standard bids" or some kind of reference system (to be defined by the table) against which the systems that are actually played are compared.

The challenge is to come up with a flexible language to specify bridge bidding systems. This would be a special purpose computer language with some computational abilities and what else you'd need. I am not an expert in this area but given the time (i.e. not at the moment ;-) I would be interested in tackling this, and also implement a system.

--Sigi

[hrothgar]

Sigi_BC84, on Mar 24 2006, 01:05 AM, said:

In my eyes, the current incarnation of FD is not much more than a proof of concept (both technically and also -- to a lesser extent -- functionality-wise).

In a previous life I spent a LOT of time doing product and project management for a wide variety of different software projects. I very much approve of the tact that Fred took (this and $3.45 will buy you a small soy latte)

The existing FD application serves a couple key purposes:

1. The FD app is a test bed that players can experiment with. Hopefully we'll see a series of incremental improvements over the course of several years.

2. The FD app is a great mechanism to show people how a more complete system will (eventually) work. I've been speculating about applications like FD for well over a decade. However, I'm not sure whether some people really understood what could be done until Fred and got the code working.

Personally, I think that it would be a mistake to launch into a significant effort to enhance the application at this point in time. I think that we need to make a LOT more mistakes before anyone has a good idea what the final application should look like.

I'm still not sure whether it would be worth the time/effort required to develop a complete language to specify bridge biddig systems. I doubt that there is sufficient demand to justify the development effort. The beauty of the FD system is that Fred was able to get something up and running. I also prefer something thats functional - however inelegant it might be - to a gorgeous architecture that only exists on paper. I think that we'll get a LOT more traction making sustained incremental improvements to an existing base rather than trying to re-invent the wheel.

As for the whole Open Source issue. I agree that it would be a big mistake to open this whole can of worms. With this said and done, I do think that there are ways in which you (or some other independent programmers) might be able to make a contribution.

1. Fred has stated that he isn't planning on doing any more work on FD in the near future.
2. You've said that you have a good understanding of the FD file format.

Write a wizard that players could use to customize FD files. As I noted earlier, the ACBL convention card would probably be a reasonable place to start for "standard" systems based on 5 card majors, natural NT opening, and a strong artificial and forcing 2♣. Ideally, players should be able to start with one of a few standard bases and add features on top of this and create anything from SAYC to KS to BWS. If you wanted to get fancy, you might even permit 4 card major systems like Acol...

[Tcyk]

I love reading this and recognize the problems of trying to create a Full Disclosure file. As I recall from the Encyclopedia of Bridge, there are about 10 to the 50th possible contested auctions. My memory may have failed me but regardless of the number, it is hugh. Some really bright person might come up with a program that automatically builds sequences based upon past bids and I hope they do. Bridge playing programs will make a giant leap forward.

I have been using OKScript for many years. It is a scripting file originally created for OKBridge but it can be used on BBO which I have been doing for some time. I even started one for Moscito a few years ago

I originally wrote individual modules for various conventions. I create a startup file and a base file for a system. The startup file oens and close the approriate folders. The base file defines the conventions used within the system with a series of "USE statements"; USE 1NTForcing, USE Lebensohl, USE xyz, etc. It's fairly easy to built a complex system.

The bad news is, the author of OKScript changed it so that I can not use it in the same way I did with the old version. Using the new version involves copying and pasting the conventions into a single file. This is not an easy task. The version of Precision Club I play with Stephen Pickett had grown to about 250 KB. Fortunately, I still have the old version. I have about 2.5 MB in the conventions folder.

If someone would like the files, I would be happy to send them to them. However, it would be unethical of me to give anyone the original OKScript program. You can download the new version. Just search on OKScript. Maybe you can figure out how to use the subroutines in the new version or you can do like me with copy and paste.

A bunch of my files are on the OKScript web site. I will warn you in advance that they will not work with the new program. However, you can download and look at them. The big drawback in using them is that you must enable keyboard input. When you do this, you must be careful not to start chatting when it is your turn to bid.

[Lovera]

Sigi_BC84, on 2006-March-23, 16:05, said:

Certainly the right move :-).


I fully agree when you say that the inclusion of certain other features is a lot more important than improving FD (at this moment). Actually the two examples you have given (messaging and team games) occupy the two top slots on my BBO wishlist. This does not keep me from posting ideas on how FD should be improved (since I have already posted that I want more team features and a different chat GUI).

Now that we have that out of the way let me say this: In my eyes, the current incarnation of FD is not much more than a proof of concept (both technically and also -- to a lesser extent -- functionality-wise). The GUI can be seen as a bad joke (sorry, Fred) and many ambitious users interested in making FD cards fail due to that. Consequently I think that based on the idea presently embodied by what we have with FD, something much bigger, better and mightier needs to be developed, possibly outside of BBO for the priority reasons already mentioned. To do that, one needs a published and documented API.

Now please nobody start the Open Source discussion once again. All I'm saying is that unless there is an API into the appropriate parts of BBO, not much will happen on this front according to my evaluation of the situation. Now Fred might answer "forget it, pal", which is fine, but I think in that case we won't see a disclosure revolution happen too soon in the future.



You make it sound as if scripting support was an "add-on" to the static datafile functionality we have at the moment. Actually my ideas stretch a lot further, in that I'd like to replace static files completely by some kind of specification language, of which static trees would be a subset.


A very good idea that you (rightly) have proposed several times already. I think this would naturally be a part of the specification language I have in mind.


I understand what you have in mind. In my eyes, the FD GUI needs to change radically anyway (into the direction of Bridge2Symmetric's), and what you are suggesting would probably be provided by System Construction Wizards or special purpose plugins for the system editor.


This would also be part of a well designed system specification language. Maybe one would have a special property for "standard bids" or some kind of reference system (to be defined by the table) against which the systems that are actually played are compared.

The challenge is to come up with a flexible language to specify bridge bidding systems. This would be a special purpose computer language with some computational abilities and what else you'd need. I am not an expert in this area but given the time (i.e. not at the moment ;-) I would be interested in tackling this, and also implement a system.

--Sigi

Hi by Lovera. As i've already told to Bbradley62 i don't know informatic (then..consider it).Let me tell a my thinking: it should simple (!) to unite a system and a convention agree for this one so. Let's suppose that this system S is already operative; apart we have a convention C in the same way studied and operative too (having an "url" or "#" to find it (i.e. 4♣ Gerber). When pair want to use it in their system S in the appropriate way they use (i.e. after a sequence ending in 3NT) the 4♣ # C.Do you think is it possibile ? Bye and let me know, i'll try to help you if i can.