How I ended up in CORE-MATH
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.
