Taipei Forcing Club

The gap

After f32 and f64 were done, I started on f128. That is where the plan broke. CORE-MATH has 41 binary64 functions and 15 binary128 ones. Square root, cube root, exponentials, one logarithm, and the inverse trigonometric functions were there. Sine and cosine were not: the binary128/sin directory had held a hard-to-round corpus since February, with no C file next to it. No tangent, no log2q, log10q, log1pq, or powq either.

Testing a correctly rounded function without an oracle is a different activity from testing one with an oracle. I ended up generating my own corpora with MPFR and a few Diophantine tricks, such as continued fractions of 2/π per binade for sine and cosine, and checking against them in CI. By the end of August every q function in metallic-rs that CORE-MATH also had was within a few percent of it, and the rest had nothing to be compared with except libquadmath, which is faithful rather than correctly rounded.

At that point the lazy conclusion was obvious. If the reference is missing the function, contribute the function to the reference.

The drama

On 3 September I mailed the CORE-MATH list a work-in-progress sinq and cosq, ported from metallic-rs to C and extended to all four rounding modes. The list bounced it: posting is for subscribers only, and I had never subscribed. I resent it the next day with the usual disclosure that I had used Claude Code while porting and testing.

Paul Zimmermann’s reply opened with the sentence I had been half expecting:

this is interesting. However we have not decided yet if we include AI-generated contributions.

followed by a question I could not dodge:

how much of the code was generated by you and not by AI?

Honestly, about all of it since April 2026. The methods are mine. I wrote them up in How to program mathematical functions back in 2021, turned that post into an agent skill this year, and have been doing what I can only call vibe optimization since. Everything else in the same reply was ordinary review: Taylor series where a minimax polynomial would do, a bound of π/512 < 2^−7.35 that was wrong in the second decimal, and timings on an i7-8700 showing my sine at about 250 cycles while expq took 60.

So I did what one does. Version 2 swapped in a degree-four minimax from rminimax and fixed the bound to 2^−7.34. Version 3 evaluated the accurate path in tiers of 128, 256, and 384 bits and halved its cost. Then came the least flattering exchange of the thread: “I don’t see the v3 in your core-math-c repo.” It was sitting unpushed on my development machine.

Paul also asked whether I would maintain the code if it were merged and problems turned up later. That question is the actual entrance exam. I said yes, and I added that I had a bigger plan: to close the gap between binary128 and binary64, one or two functions at a time. He opened an account for me on gitlab.inria.fr with the maintainer role, and sinq and cosq landed on master on 19 September. The announcement quotes 154.5 cycles per call for sinq against 872 for libquadmath, and 156 against 995.5 for cosq.

Where it stands

That was one function pair out of the two dozen or so still missing in binary128. I am now working on sincosq, tanq, the other logarithms, and whatever comes next, one or two at a time. Most of them already run in metallic-rs, so porting them is mostly a matter of adding three rounding modes and surviving review.

Pair the bot with a web server

This sounds like a blasphemy against the single-responsibility principle. There are practical reasons to do this.

1. Hosting providers may put idle bots to sleep. Some providers are so web-centric that they require serving a web page to keep the bot alive.
2. HTTP(S) serves as a simple and reliable endpoint. Everyone online can ping it.

Below is how I pair Natsuki with an Axum server. The Axum server only serves 204 No Content at root.

#[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
    }
}

Monitor the web server

The other part of the plan is a watchdog that periodically pings the web server. The watchdog informs me through a Discord channel whenever a ping fails. Since the web server is available worldwide, the watchdog can live anywhere such as GitHub Actions. Given the importance of GitHub, it is much more reliable than self-hosting.

My watchdog is open-source like Natsuki. It takes a Discord webhook to send messages. I make it an environment variable because the webhook contains sensitive data. If the webhook is leaked, other people can send arbitrary messages to the channel.

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(())
}

Basic structure

• TOR = transfer or extra
  • (R) = NF negative, accepts the transfer
• TOR + 1 = transfer back to the suit of TOR

Examples

Birthright (Kokish Relay)

A classical problem with the strong 2♣ opening is whether the auction is game-forcing. One solution is the Kokish Relay, where opener bids 2♥ to show hearts or a unilaterally game-forcing hand. This treatment potentially wastes space because opener hardly passes 2♥-2♠.

The rebids after 2♣-2♦ I propose are:

2♥

5+ spades or FG

2♠

NF, 5+ hearts

2NT to 3♦

NAT NF

After 2♥, the default 2♠ fits any hand that responder would pass natural 2♠. Other responses are game-forcing.

After 2♠, responder passes with weak long spades. The 3♥ response is to play. Whether 2NT is game-forcing is up to partnership agreement.

Polish Club with swapped minor suits

1♣

Polish Club with diamonds instead of clubs:

1. Balanced 12–14 HCP
2. 11–17 HCP, 5+ diamonds or 4441
3. 18+ HCP, any

1♦

11–17 HCP, 5+ clubs or (441)4

It took me almost one year to accept this idea until I realized that 1♣-1X-2♣ should retransfer to diamonds. The strength difference between natural diamonds (11+ HCP) and clubs (18+ HCP) is so large that opener should transfer twice. The odwrotka sequence of 1♣-1X-2♦ remains a power reverse.

Drawbacks

Responding to TOR + 1 is more complicated than TOR. You can no longer park at the negative relay (TOR + 1). Accepting the transfer (TOR + 5) becomes default and often meets a pass. Take 1♦ (showing clubs) for example:

• Pass: weak long diamonds
• 1NT: constructive natural, effectively 4+ diamonds
• 2♣: almost a signoff with 3–4 clubs
• 2♥♠: game try with 3+ clubs
• 2NT: preemptive raise with 4+ clubs
• 3♣: mixed raise with 4+ clubs