runtime: math_log is base-10, not natural log #134

Merged
will.anderson merged 1 commits from fix/math-log-base10 into dev 2026-08-16 02:34:11 +00:00
Owner
el_val_t math_log(el_val_t f) { return el_from_float(log(el_to_float(f))); }
el_val_t math_ln(el_val_t f)  { return el_from_float(log(el_to_float(f))); }

Both were natural log — math_log and math_ln were the same function. log10(100) returned 4.605 instead of 2.

Three sources already said base-10 and were being contradicted by this one line:

  • runtime/math.el:55"// math_log — base-10 logarithm."
  • el_seed.c:1278__log_f -> log10() (the path math.el actually calls)
  • tests/native/test_math.el:133 — asserts log10(100) == 2

Found by the new test framework on its first run (#133). The assertion had been in the suite all along; nothing could report it. The old harness printed N passed, M failed with no per-test detail, and half the suites weren't compiling at all — so a failing assertion in a suite nobody could run was indistinguishable from no failure.

That's the framework's whole argument, demonstrated on day one: not a bug it introduced, a bug it made visible.

Verified: test_math.el goes 12/13 → 13/13.

```c el_val_t math_log(el_val_t f) { return el_from_float(log(el_to_float(f))); } el_val_t math_ln(el_val_t f) { return el_from_float(log(el_to_float(f))); } ``` Both were natural log — `math_log` and `math_ln` were the same function. `log10(100)` returned **4.605 instead of 2**. Three sources already said base-10 and were being contradicted by this one line: - `runtime/math.el:55` — *"// math_log — base-10 logarithm."* - `el_seed.c:1278` — `__log_f -> log10()` (the path `math.el` actually calls) - `tests/native/test_math.el:133` — asserts `log10(100) == 2` **Found by the new test framework on its first run (#133).** The assertion had been in the suite all along; nothing could report it. The old harness printed `N passed, M failed` with no per-test detail, and half the suites weren't compiling at all — so a failing assertion in a suite nobody could run was indistinguishable from no failure. That's the framework's whole argument, demonstrated on day one: **not a bug it introduced, a bug it made visible.** Verified: `test_math.el` goes 12/13 → **13/13**.
will.anderson added 1 commit 2026-08-16 02:33:47 +00:00
runtime: math_log is base-10, not natural log
El SDK CI - dev / build-and-test (pull_request) Failing after 10m8s
edafd8cce8
el_val_t math_log(el_val_t f) { return el_from_float(log(el_to_float(f))); }
    el_val_t math_ln(el_val_t f)  { return el_from_float(log(el_to_float(f))); }

Both were natural log, so math_log and math_ln were the same function.
log10(100) returned 4.605 instead of 2.

Three sources already agreed it should be base-10 and were being contradicted
by this one line:
  - runtime/math.el:55  "// math_log — base-10 logarithm."
  - el_seed.c:1278      __log_f -> log10()  (the path math.el actually calls)
  - tests/native/test_math.el:133  asserts log10(100) == 2

FOUND BY THE NEW TEST FRAMEWORK ON ITS FIRST RUN (el #133). The assertion had
been sitting in the suite the whole time; nothing could report it. The old
harness printed "N passed, M failed" with no per-test detail, and half the
suites were not compiling at all — so a failing assertion in a suite nobody
could run was indistinguishable from no failure.

That is the entire argument for the framework, demonstrated on day one: this is
not a bug the framework introduced, it is a bug the framework made VISIBLE.

Verified: tests/native/test_math.el goes 12/13 -> 13/13, math-log passing.
will.anderson merged commit a69a4a5894 into dev 2026-08-16 02:34:11 +00:00
Sign in to join this conversation.