Taipei Forcing Club

I want Natsuki to notify me when she goes down. This task is harder than I have thought. How can I count on a failing bot to send a message? I cannot trust the hosting provider, either. They may be the reason why the bot goes down. I have to rely on a third party.

#[shuttle_runtime::async_trait]
impl Service for Natsuki {
    async fn bind(mut self, addr: std::net::SocketAddr) -> Result<(), Error> {
        use axum::{response::NoContent, routing::get, Router};
        let router = Router::new().route("/", get(|| async { NoContent }));

        let (axum, serenity) = futures::join!(
            shuttle_axum::AxumService(router).bind(addr),
            self.0.start_autosharded(),
        );
        serenity.map_err(CustomError::new)?;
        axum
    }
}

use dotenv::var;
use serde_json::json;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let client = reqwest::Client::new();
    let ping = || async {
        const ENDPOINT: &str = "https://natsuki-oehk.shuttle.app/";
        anyhow::ensure!(client.head(ENDPOINT).send().await?.status().is_success());
        Ok(())
    };
    if let Err(error) = ping().await {
        client
            .post(var("WEBHOOK")?)
            .json(&json!({ "content": error.to_string() }))
            .send()
            .await?;
    }
    Ok(())
}

An o’ish relay is a forcing bid that is natural or has extra strength. Famous examples are Birthright (Kokish Relay, 2♣-2♦-2♥) and Polish Club (1♣), after which I name this treatment. I advocate playing a transfer o’ish relay instead, the relay that either transfers to the next suit or has extra strength. This method renders the negative response nonforcing and allows more descriptive rebids.

I’ve been with my girlfriend for 2+ months and finally found the red and blue mascots for my bridge bidding systems.

• Litten for Litten Polish Club
• Oshawott for Mijumaru Blue Club

Oshawott is my girlfriend’s favorite pokémon. She thinks that Litten is my pokémon since my fursona is an orange cat. These two pokémons fit the color stickers from WBF systems policy and also the Red Oni, Blue Oni trope.

By the way, recently I reached 1800+ Elo on Cuebids. I took a screenshot because I not only was proud of it but also thought it cannot last long.

I’m rewriting Natsuki (3.0) in Rust for several reasons. You can track my progress at this branch.

1. Hosting: Free hosting tend to assume that node.js projects are websites. They put the app to sleep when idle, which effectively takes down a Discord bot. I’m now self-hosting Natsuki, but I’m not a fan of that. Rewriting in another language solves this issue.
2. Economy commands: Shuttle provides free hosting even with 500 MB of database. This means we can make stateful features in the future, such as economy and games.
3. Also please note that I’m considering remove NSFW functions. Discord has been more and more hostile to NSFW features. Making Natsuki SFW can spread her further.

I made a new icon for the Taipei Forcing Club and this site. This icon honors both my hobbies: contract bridge and Japanese mahjong.

I used Inkscape to create the icon. I’m not a graphic designer, but I’m happy with the result. This icon combines lietxia’s 🀙 (1p) mahjong tile and ♣ in Noto Sans TC.

I tested my bidding systems on Cuebids, a web app for pairs to practice bidding. All three accounts using my bidding systems made it to the top 10 this week. The following is the screenshot of the top 10 list when Mijumaru Blue Club (known as Bluepill (Canapé) Club then) just entered the list. My own account and Irene playing only Litten Polish Club were the top two.

We are still on top 5 as of this writing. We will try to stay on top 10 but not to be top 3 at the same time to keep the environment competitive.

My collection of bidding systems is available on GitHub. It contains aforementioned systems and a defensive system. Litten Polish Club is almost complete. Mijumaru Blue Club is still evolving. The defensive system is still in its infancy.

This collection is free software. You can use it for any purpose, including commercial purposes, at your own risk. I would appreciate it if you could share your experience with me.

Inspired by Thomas Andrews’ article on single hand evaluators, I want to check out how good such an evaluator NLTC is. Since LTCs need an established trump fit, we only consider suit offense tricks, i.e. the most tricks a partnership can take in any suit contract.

Thomas built his data with Matt Ginsberg’s (GIB) double dummy library containing 700K+ deals. However, available sources of that library are long gone. To achieve similar statistical power, I would have to solve about 1M deals. Thanks to DDS, the well known double dummy solver in C++, along with modern computer architecture, we can solve 1M deals within one day.

I generated all data in this article with my bridge utility. It took 8 hours to solve 1M deals for only suit contracts. The following is the correlation coefficient matrix of various evaluations.

The plus sign stands for short-suit points in GIB bid descriptions. As BUM-RAP gives fractional points, I made such an adjustment more rigorous.

• S = (void = 3, singleton = 2, doubleton = 1)
• X+ = max(X, S, X + S − 1) for each suit

As for how this adjustment is slightly better than max(X, S) and X + S, there will be a separate article.

ALTC is what Jeff Rubens suggested. Adjust −0.5 losers for each held ace and +0.5 for each guarded queen. NLTC bears this in mind but adjusts for missing aces and queens instead.

Things are different when we add up evaluations in each partnership. LTCs are less additive than HCP+. I think this phenomenon arises from counting values twice. A classic example is that a long suit in one hand and the corresponding doubleton in another are both counted as values a priori.