[us-commits] [ehb54/ultrascan3] c31acc: somo/grpy: ask the solver for its high-precision r...

[emre brookes]

  Branch: refs/heads/somo-dev
  Home:   https://github.com/ehb54/ultrascan3
  Commit: c31acc956f81b382da75a9af2366c7753ab4610b
      https://github.com/ehb54/ultrascan3/commit/c31acc956f81b382da75a9af2366c7753ab4610b
  Author: Emre Brookes <emre.brookes at umontana.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_process.hpp
    M us_somo/develop/grpy/tests/test_process.cpp

  Log Message:
  -----------
  somo/grpy: ask the solver for its high-precision report

The GRPY program's default report is the Fortran's own ES11.3 -- four significant
figures. That is right for a drop-in replacement a human reads, and wrong for a
caller that DIFFERENCES successive results, which is exactly what the shell
reduction does: the error estimate is built from the gap between consecutive rungs
and from the ratio of two such gaps, so a relative quantisation of ~1e-4 in the
parsed values lands directly on the reported bar.

Measured over 266 reduced evaluations, by rounding recorded full-precision rung
values through %11.3E and re-running the estimator on both:

  reported estimate   median 2.5% different, up to 17.6%
  observed order k    shifts by up to 0.26
  floor activation    changes which term governs in 14 cases
  stopping decision   flips in 2 cases

Coverage happened to survive on that corpus -- the minimum margin fell only from
1.131x to 1.119x, and no evaluation lost coverage -- so this is not a correctness
fix. But none of that movement should exist. It is an output format leaking into a
numerical result, and into the delivered value too, which was being truncated to
four significant figures.

The program already supports this: GRPY_HP switches the report to %24.15E. Nothing
changes for anyone running the program directly, since the default is untouched and
the drop-in behaviour is preserved.

The parser finds values by their exponent rather than by column, so it is indifferent
to the field width. Tests assert that rather than leaving it to inspection: a
%24.15E report round-trips a double to better than 1e-12, and the legacy ES11.3
report still parses, since an older binary on PATH would still emit it.

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>


  Commit: 71440862d4921b0f98d8d656e0ac7a5ce7ffff4a
      https://github.com/ehb54/ultrascan3/commit/71440862d4921b0f98d8d656e0ac7a5ce7ffff4a
  Author: emre brookes <ehb54 at users.noreply.github.com>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_process.hpp
    M us_somo/develop/grpy/tests/test_process.cpp

  Log Message:
  -----------
  Merge pull request #522 from ehb54/ehb54-grpy-hp

somo/grpy: ask the solver for its high-precision report


Compare: https://github.com/ehb54/ultrascan3/compare/9bab116da505...71440862d492

To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications