[tannevaled]

vm: Math.log1p and Math.expm1, the two functions Ruby 4.0 added to Math

Found by asking the interpreter, rather than by reading a changelog: of 31 Ruby
4.0 surfaces that ruby/spec gates behind ruby_version_is "4.0", rbgo already
answers 28. The three it does not are Array#rfind, Math.log1p and
Math.expm1. These are the two pure ones.

Measured, with the control

core/math/log1p_spec.rb and core/math/expm1_spec.rb, run on a private corpus
at the pinned SPEC_SHA with the shim's CUR_VERSION set to 4.0.9 (the whole
of both files sits behind a 4.0 guard, so at 3.4.1 they yield nothing at all):

spec	main (3a3fb81)	this branch
core/math/log1p_spec.rb	pass=0 fail=5 error=5	pass=10 fail=0 error=0
core/math/expm1_spec.rb	pass=0 fail=2 error=5	pass=7 fail=0 error=0

All 17 examples, and the control row is what makes the right column mean
something: every one of them failed or errored before.

Those 17 remain invisible to CI until CUR_VERSION moves (#845, #799) — the
same ordering as #844: capability first, so that when the version moves, a file
that shifts because a method was missing is not noise in the ratchet's reading.

Why these two functions exist at all

log1p(x) is log(1+x) and expm1(x) is exp(x)-1, computed so the result
keeps its precision for |x| far below 1. Written the naive way they both return
0.0 for 1e-16, because the leading 1 swallows every significant digit:

Math.log(1 + 1e-16)   # => 0.0
Math.exp(1e-16) - 1    # => 0.0

Both specs assert exactly that this must not happen (log1p_spec.rb:10,
expm1_spec.rb:10: close to 1e-16 and != 0.0). So an implementation that
spells out the identity passes the first example of each file and fails the
second. Go's math.Log1p/math.Expm1 are the same primitives C hands MRI; the
tests carry the naive forms beside the real ones as the control.

Domain: log1p is real for x >= -1 — log1p(-1) is -Infinity, which is a value
and not an error — so Math::DomainError belongs to x < -1, which is what the
spec exercises with -1 - 1e-15.

⛔ A pre-existing divergence these two do NOT inherit

core/math/log1p_spec.rb:27 asserts Math.log1p(9, 3) raises ArgumentError
"wrong number of arguments (given 2, expected 1)". rbgo does not check arity on
Math functions at all — measured on main:

$ rbgo -e 'p Math.cbrt(9, 3)'
2.080083823051904            # MRI: ArgumentError

The extra argument is silently dropped, for every function the unary helper
installs. That is not fixed here, and the asymmetry is deliberate rather than
an oversight: the arities are not uniform (Math.log legitimately takes one OR
two arguments, atan2/hypot/ldexp take two), so a blanket check is wrong and
a per-function sweep of ~20 functions moves what the gate measures and needs its
own measurement. It is filed separately.

What must not happen is a new method inheriting the old leniency because its
neighbours have it. unaryStrict carries the check, the older helpers are left
as they are, and the comment at the site says why so the next reader does not
read the asymmetry as sloppiness.

No regression

The whole internal/vm suite passes (230s, -count=1). The only spec in
language/+core/ that touches Math's method list is
core/math/shared/atanh.rb:32, and it asserts inclusion, not a count — two
more private instance methods cannot move it.

gofmt clean, go vet clean. No new input is parsed; both functions are pure
and allocate one Float.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

🤖 Generated with Claude Code