CORE-MATH is the project that made correctly rounded math functions look practical instead of academic. It is also the reason metallic-rs exists: I wanted a correctly rounded math library in Rust, and I wanted it to be faster than the reference. Rust has no floating-point environment and only the default rounding mode, so I have one trade-off CORE-MATH does not: I skip the other three rounding modes and spend the savings on speed. CORE-MATH was the rival, and the oracle, and the source of worst cases. It was not supposed to become my job.

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.