kdblocher / bridge Goto Github PK

There are less than 256 possible scores. We can create a precalculated score table (just like the idea in #48) and index them.
Even better it seems that some scores are not possible as par scores (see http://www.rpbridge.net/7a23.htm), but I could see wanting to have all scores available so we can use it to do system statistical analysis down the line.

See https://github.com/kdblocher/bridge/blob/master/src/model/score.testdata.ts for all possible scores.

Allow ability for users to write shorthand macros.

Might generalize things like #6 and #4

Upgrade Math.random to Crypto.getRandomValues
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues

On the section where it show how many hands were generated, it would be great to see the frequency. For example,, if I run 10000 hands, and get 17 matches, it would be great to see (1 in 588.2). Not that I can estimate the math in my head, but we have computers to do that more quickly.

This was something I could whip up pretty quick. Somewhere in our master table, we will store a small int referencing a hand shape. That smallint will point to the ID of a shape_table. Creating that table can be done with the following SQL code.

IF OBJECT_ID('tempdb..#nums','U') IS NOT NULL
DROP TABLE #nums
IF OBJECT_ID('shape_table','U') IS NOT NULL
DROP TABLE shape_table

CREATE TABLE #nums (suit_count tinyint)

CREATE TABLE shape_table (
	id smallint PRIMARY KEY CLUSTERED IDENTITY(1,1),
	spade_length tinyint,
	heart_length tinyint,
	diamond_length tinyint,
	club_length tinyint
	)

INSERT INTO #nums (suit_count)
VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11),(12),(13)

INSERT INTO shape_table
SELECT	
	d.suit_count as spade_length,
	c.suit_count as heart_length,
	b.suit_count as diamond_length,
	a.suit_count as club_length
FROM #nums d
CROSS JOIN #nums a
CROSS JOIN #nums b
CROSS JOIN #nums c
WHERE a.suit_count + b.suit_count + c.suit_count + d.suit_count = 13

SELECT *
FROM shape_table

Currently, the parser can get very slow and bogged down if you are running many thousands of hands, and then try to adjust the bidding system. It seems to regenerated all of the hands every time you adjust a single character.

Stub issue to buy @TysonMN's contribution.

I was trying to enter 1N: 12-14 bal and couldn't figure out why it wasn't working. Perhaps this should be case insensitive?

Can we specify 1C opening like 16+ notFit(1N) notFit(2N)? If we choose to change 2N point range we don't need to modify 1C

We at least need the server built and tested via CI (but not necessarily deployed).

So just for a quick test, I entered the following: 1H: 15-17 BAL H1

I ran a few thousand hands, and got 22 results, and then found the DDS averages. But when I went to generate more hands, it seemed to add the new number of hands to the number of hands I already had rather than giving a new results set. That's fine if it's supposed to be cumulative, but the results matrix never updates. The values are left as they were after my first "generate deals" run.

In the sample SAYC that somebody created, they defined a 1 of a minor opening as 11-21 3+D 4-M. That's a great shortcut for saying no four card major. Unfortunately, it's either not implemented, or implemented bug doesn't work right.

We want to have not(14-15 BAL) for 1D 1H opening

Whenever a client generates a hand, write it to the API (if available).

Since we don't have DDS or hand metadata done yet we can't really write anything more yet.

Currently, if I want to enter a transfer auction, I must write

1N: 12-14 BAL
2D: 5+h
2H: 0+

But I really shouldn't even need to put anything after the 2H: if it is an auto-bid. Again, nothing major, just an oddity of the current parser.

Current definition: https://docs.google.com/document/d/11FHkl4DuEVK62bg_gxOUoa-KE0PxTEga8fMW8nfr77s/edit

Need to save tricks as an integer between 0-13 for each of direction x strain

When I define a system, I often want to roll a hand that exactly matches one of the items in the list. Alternatively, I may want to roll a hand that does NOT match anything. (i.e. it exposes a hole in the system) I also may want to see hands that have two different paths down a tree in order to better decide on how to discriminate between two completely different but

Deal/Hand generation is done concurrently, but computed stats are not (yet)

If I have multiple cases, and I want to see the hand patterns, sometimes I will want to see them by order of frequency. But other times, I will want to see them by the order of the bid. For example. if I put it responses to 2S, I may want to see the results as
2S-> 2N
2S-> 3C
2S-> 3D

etc, regardless of frequency.

There are multiple types of questions, and different types of questions need different types of engineering solution. We need to categorize questions and prioritize them based on engineering resources.

Related to #24.

• Ability to specify a suit as "sound", "light", "very light", etc.
• Ability to handle things like the following

* 1N:
  * 3m: 6+m KQ+
* 3N: 8+m AKQ+
* 2H: 6+H sound

A hand that is Axx, Axx, Qxxx, Jxx is an awful 11. But I want AT9, Axx, QTxx, JT9 to be worth more than 11. For example, I tend to count AJT as 6 HCP. Allow someone to define such combinations.

Need to support something like firstSuit()

firstSuit(H) should expand to 5+H S<H H>=D H>=C

Per discussion with @sievers2501

Top (2,3) is KQ+
Top (3,6) would be JT9 or better
2H bust would be not(top(1,2))
(3,6) top (2,3) would be KQ9 or better

Need to extract code from optimization branch

Moved to #73 .

Need ability for contextual reference to implement more advanced constraints, such as #6 and forcing bids.

At some point, we want to be to define an auction of an opening, overcall, and response. There will need to be some method of entering that information without destroying the simplicity of the current capacity to assume all quiet by the opponents.

Ability to specify stop count and/or quality, as described by this article: https://bridge.fandom.com/wiki/Stopper
Should include partial and full stoppers

@sievers2501 Did you mean for these to be NOT NULL? If so please create a new PR (draft) and mark this issue as a bug

For testing purposes, I set up the following simple stayman response.

1N: 0-17 BAL
2C: 9+ (4H or 4S or 5+S 4H or 4S 5+H)
2D: 5+H

The 2C should be true whenever there is 9+ HCP and either one of the 4 following conditions are true. 4 hearts, 4 spades, 5 spades and 4 hearts, or 4 spades and 5 hearts. The following hand as responder doesn't match the 2C bid, but it does the 2D bid. (The opener does, so no worries there)
AQT6.AJ862.K2.T8

Is this a bug, or am I entering the syntax wrongly?

Allow for hands to be saved and retrieved. Any extras optional

Currently, if we would want to enter a hand that is 4441 with the singleton in any of the four suits, we would have to say shape 4441 or shape 4414 or shape 4144 or shape 1444. There should be an "any" 4441 hand. Or an "any" 4333 to denote such hands more succinctly.

Automatically generate hands that fit and don't the selected path and show them in the selection pane

Per @eieioAce

Per player, pre-calculate 35 contract score
If it doesn't make, add a double to it
And also add pass = 0, so each player has 36 options (to bid, or pass)
Each player sort the options based on the score, descendent
Dealer simply put the first option, which is the best contract from that direction
Next player do a linear scan to see if there's a higher bid and benefits
And so forth
So the dealer decides how you start the algorithm

I'm working on a system, and went to save my work over to Google docs. When I did so, all of the indentations flattened out to one level. It appear you can copy the other way just fine, from Google docs to the bridge app. But going TO google docs the tabs are not carried over.

In once since this isn't urgent, but it does slow me down until we have a better editing method.

Go to https://bridgeteaching.com/borel/ and download the .zip file and play around with the program. There may be ideas on for feature requests or interesting ways of handling hands and deals. This program is woefully out of date, and they have lost the source code, but that doesn't mean there might be a nugget in there somewhere for us to snag.

Allow for passing as a bid option. Either explicit or implicit. In forcing scenarios pass would be disallowed.

Everything in https://github.com/kdblocher/bridge/tree/master/src/model, by convention, is core types, abstractions, and functions. Adding property-based testing to these functions will help prevent lots of (runtime) regression errors.

See here for examples:

• https://github.com/kdblocher/bridge/blob/master/src/model/deck.spec.ts
• https://github.com/kdblocher/bridge/blob/master/src/model/score.spec.ts

fast-check site: https://github.com/dubzzz/fast-check