PaperlayerView exact revision on arXiv

Source-linked AI summary

Taylor-Approximation-Based Repair of High Floating-Point Errors

Xin Yi, Liqian Chen, Hengbiao Yu, Shangwen Wang, Tao Tang, Chun Huang, Xiaoguang Mao, Ji Wang

arXiv:2610.14444v1cs.SE

TL;DR

Numerical routines can lose accuracy near localized ill-conditioned inputs, even when most inputs are handled accurately. NPTaylor generates and checks guarded Taylor patches for such regions. Across matched one-input GSL configurations, it repairs all 114 cases with lower geometric-mean repair time and smaller patches than AutoRNP.

  • Problem

    Numerical routines can lose many bits near localized roots, poles, cancellation points, or branch boundaries, returning values far from the high-precision oracle-rounded result.

    Source: §1 · pp. 1–2

  • Method

    NPTaylor searches Taylor-program choices for a localized domain, emits a guarded C patch, and accepts it after checking the emitted code on recorded local inputs.

    Source: §1 · p. 2, §5.1 · p. 8, §8 · p. 16

  • Results

    NPTaylor and AutoRNP repair all 114 one-input GSL configurations; NPTaylor has a 3.33× geometric-mean repair-time advantage and emits 0.162× as many C bytes.

    Source: §1 · p. 2, §8 · p. 16

  • Takeaways & Limitations

    The results support compact localized one-input repairs and bounded multi-input capability analysis, including cases outside AutoRNP’s implemented workflow.

    Source: §8 · p. 16

    The checker validates recorded local inputs rather than proving a full-domain error bound or continuity across adjacent pieces, and experiments check scalar returns rather than all library side channels.

    Source: §4.2 · p. 7, §6.6 · p. 15

Abstract

from arXiv · show

Numerical libraries can still lose many bits of accuracy on localized ill-conditioned inputs, such as roots, poles, cancellation points, and branch boundaries. This paper presents NPTaylor, a Taylor-approximation-based framework for repairing localized high floating-point errors in numerical C routines. Given a high-error input, a localized repair domain, a high-precision oracle, and an error threshold, NPTaylor searches over Taylor degree, expansion center, segmentation, and floating-point evaluation strategy. It emits guarded C patches that use a generated Taylor evaluator inside the repair domain and fall back to the original routine outside it. Candidate patches are accepted only after validating the emitted C code on recorded local samples, guard endpoints, and the pre-repair peak input. The generated evaluator uses coefficient splitting and compensated Horner evaluation to reduce rounding error introduced by the patch itself. We evaluate NPTaylor on GSL benchmark workloads. On 38 one-input functions, both NPTaylor and AutoRNP repair all 114 configurations across three accuracy thresholds. NPTaylor is 3.33x faster by geometric-mean offline repair time and emits 0.162x as many C bytes. In the strictest setting, its median repair time is 3.74s versus 81.97s for AutoRNP. NPTaylor also repairs localized multi-input benchmark cases beyond AutoRNP's implemented one-input workflow. These results show that Taylor-based guarded patches can provide compact, efficient local repairs, while the claims remain validation-relative rather than full-domain proofs.

1 Introduction

Numerical routines can lose many bits near localized features such as roots, poles, cancellation points, and branch boundaries. NPTaylor generates guarded Taylor patches for these regions and validates emitted C code; on GSL workloads it repairs all matched one-input configurations with lower repair cost than AutoRNP.

1 Introduction

  • Localized failures near roots, poles, cancellation points, or branch boundaries can make an otherwise mature numerical routine inaccurate on accepted inputs.The output may be far from the high-precision oracle-rounded result.Source: §1 · pp. 1–2
  • In a strict repair case, NPTaylor repaired gsl_sf_bessel_Y1 in 139.23s with a 2.1KB patch, compared with AutoRNP’s 9788.39s and 403KB patch.The comparison concerns one localized interval.Source: §1 · p. 2
  • NPTaylor takes a high-error record, original C routine, oracle policy, localized domain, and threshold, then generates a guarded Taylor patch.The patch uses the generated evaluator in the repair region and preserves the original path outside it.Source: §1 · p. 2
  • NPTaylor searches Taylor choices suited to local domains, where expansions offer compact expressions and fixed evaluation orders can map to C.The search includes centers, degrees, segmentation, and evaluation strategy; the generated expression approximates the high-precision oracle on the selected domain.Source: §1 · p. 2
  • Successful repairs are validation-relative: checks on recorded local inputs do not establish a full-domain error bound or continuity across piece boundaries.The validation set includes samples, guard endpoints, and the pre-repair peak input.Source: §1 · p. 2
  • 3.33× geometric-mean repair-time advantage and 0.162× as many C bytes accompany repairs of all 114 one-input configurations by both systems.The configurations span 38 functions and three accuracy thresholds; NPTaylor’s strict-setting median repair time is 3.74s versus 81.97s for AutoRNP.Source: §1 · p. 2

2 Background

The background defines the oracle-relative floating-point error used for repair, then explains localized guarded patches, compensated evaluation, and Taylor polynomials as generated local code. Evaluation order matters because the same polynomial can produce different target results under different floating-point operation sequences.

2.1 Floating-Point Error for Repair

  • The repair error measures the distance between implementation and oracle-rounded outputs in ordered floating-point value space, and the workload selects inputs with ErrBits(P0,x) > 32.Larger ErrBits values indicate a greater representable-value distance from the reference.Source: §2.1 · p. 3

2.2 Localized Repair

  • A guarded repair uses the generated evaluator inside the localized domain and the original implementation outside, localizing behavioral change to the suspicious region.The background distinguishes detection, localization, and repair; AutoRNP uses PTB to localize intervals, and the systems share localized domains for baseline-aligned comparison.Source: §2.2 · p. 4

2.3 Error-Free Transformations and Compensated Evaluation

  • EFTs expose operation rounding residuals, and EFT–Horner accumulates multiplication and addition residuals alongside the main Horner computation.Coefficients can be stored as high/low pairs so the evaluator uses the high part in the main computation and feeds the low part into compensation; the construction assumes the transformation’s standard conditions.Source: §2.3 · p. 4

2.4 Taylor Approximation as Local Repair Code

  • Taylor polynomials provide local approximations around an expansion center, with multi-indexed coefficients extending the representation from intervals to multi-input boxes.Because operation order affects target results, NPTaylor treats evaluation scheme as part of the candidate and emits the selected center, coefficients, degree, guard, and operation order.Source: §2.4 · pp. 4–5

3 Motivating Example

For the localized gsl_sf_bessel_Y1 error interval, NPTaylor accepts a one-piece degree-7 Taylor repair; its sampled peak error is lower than AutoRNP’s and far below the original routine’s.

3.1 Localized Repair: gsl_sf_bessel_Y1

  • The interval is [30.6047, 30.6318], centered near peak input 30.6183 for the order-one Bessel function of the second kind, Y1(x).The Taylor error is near zero around the expansion center and grows toward the interval ends.Source: §3.1 · pp. 5–6
  • NPTaylor accepts a one-piece degree-7 Taylor polynomial with EFT–Horner after trying degrees before splitting; this repair takes 139.23s.The checker uses 10,000 deterministic samples plus endpoints and the pre-repair peak input.Source: §3.1 · p. 5
  • At the 5.13 ErrBits threshold, NPTaylor peaks at 3.46 ErrBits, below AutoRNP’s 5.00 and the original routine’s 51.31.The comparison uses the same PTB-localized interval and 10,000 fixed-seed samples.Source: Figure 1 · p. 6, §3.1 · p. 6
  • NPTaylor’s patch is 2,131 bytes versus AutoRNP’s 403.3KB, and its repair takes 139.23s versus 9788.39s for AutoRNP.AutoRNP’s patch contains 2,542 tabulated grid points.Source: §3.1 · p. 6
  • Inside the interval, the guarded Taylor patch is 4.93× faster than the original and 1.63× faster on a mixed input stream despite 2.6% guard overhead.AutoRNP reaches 1.15× speedup inside the interval on the same stream.Source: §3.1 · p. 6

4 Problem Formulation

The formulation treats localized repair as generation of guarded C code under an explicit checker contract. Its reported guarantee is limited to the stated validation set and repair conditions, not a proof over the full input domain.

4 Problem Formulation

  • A repair instance is supplied by a detector/localizer front end; NPTaylor does not infer repairs from arbitrary C code alone.The instance includes the original routine, localized domain, oracle policy, threshold, and validation policy.Source: §4 · p. 6

4.1 Domain-Conditioned Repair Interface

  • Each instance specifies the original implementation, high-precision oracle, target format, localized construction domains, checked validation set, C semantics, and error threshold.The construction domain guides generation, while the finite validation set is where the emitted patch is checked.Source: §4.1 · p. 6
  • NPTaylor composes local evaluators with ordered guards and the original fallback, and checks the generated C program rather than only its Taylor polynomial.The guard selects the evaluator on the localized domain and preserves the original path outside it.Source: §4.1 · pp. 6–7

4.2 Repair Acceptance Condition

  • The ErrBits repair predicate is applied to a finite recorded validation set, including deterministic domain samples, guard endpoints, and the pre-repair peak input.A repair is reported only when the final emitted patch, including guards and fallback paths, meets the threshold on that set.Source: §4.2 · p. 7
  • Construction domain Dloc guides Taylor construction and subdivision, whereas Dval supplies evidence for the validation-relative claim under the stated oracle, threshold, and C semantics.Success means the emitted patch passed the checker contract for the specified localized domain and validation set.Source: §4.2 · p. 7

4.3 Claim Boundary

  • The local repair claim proves neither an error bound for every representable input nor continuity between polynomial pieces, and checks only the wrapper’s scalar return value.It does not claim preservation of status codes, errno, or floating-point exception flags.Source: §4.3 · p. 7

5 NPTaylor Design

NPTaylor searches for Taylor-program repairs through a checker-in-the-loop pipeline, refining local pieces and validating the emitted guarded C patch. Its design separates construction from validation and rechecks the composed patch in the stated floating-point environment.

5.1 Overview

  • NPTaylor’s five-stage pipeline localizes the region, builds a Taylor candidate, fixes its floating-point evaluator, emits guarded C, and checks the emitted program.Source: §5.1 · p. 7
  • The repair policy, builder, and checker use a compact descriptor as their interface, with the checker deciding acceptance after each refinement is lowered to complete C.A failed check returns difficult inputs that guide refinement.Source: §5.1 · p. 8

5.2 Repair Policy

  • The policy keeps the localized construction region separate from the finite validation set, tries degrees before splitting failed regions, and validates the merged patch at the end.One-input regions are trisected; multi-input repair supports strip and thirds-based box splitting.Source: §5.2 · pp. 8–9

5.3 Taylor Candidate Construction

  • For each Taylor descriptor, NPTaylor derives high-precision coefficients near an anchor, then uses coefficient splitting and EFT–Horner to give the floating-point evaluator numerical headroom.The initial anchor is the detector-reported peak; after subdivision, difficult inputs or subdomain centers can provide new anchors.Source: §5.3 · p. 9

5.4 C Emission and Validation

  • NPTaylor composes accepted pieces with ordered guards, falls back to the original routine outside them, and rechecks the merged patch in the stated checking environment.The acceptance decision is tied to the emitted source because compiler flags, target ISA, floating-point environment, or validation policy can change behavior.Source: §5.4 · p. 10

6 Implementation and Evaluation

NPTaylor is evaluated as a guarded C-patch generator on GSL workloads, with local validation of emitted code. It repairs all shared one-input configurations, with its strongest repair-cost advantage at strict thresholds, while multi-input synthesis and sampled checking impose limits.

6.1 Implementation

  • The prototype localizes high-error inputs, builds Taylor approximations, and emits guarded C patches; validation and benchmarking use the emitted C source.The workflow uses FPCC inputs and AutoRNP’s PTB localization, then selects centers, degrees, segmentation, and evaluation order before checking the compiled wrapper.Source: §6.1 · p. 10

6.2 Evaluation Overview; 6.3 Experimental Setup

  • The evaluation pairs one-input repairs with AutoRNP on shared PTB domains, while multi-input repair is a NPTaylor-only capability study.FPCC screened 167 GSL special-functions and retained 38 one-input and 23 multi-input records with ErrBits > 32.Source: §6.2 · p. 10, §6.3 · p. 10

6.4 RQ1: Repair Effectiveness; 6.5 RQ2: Repair Quality and Runtime Impact

  • Across 114 shared one-input configurations, NPTaylor is 3.33× faster by geometric-mean repair time and emits 0.162× as many C bytes as AutoRNP.At the strict Hε threshold, NPTaylor is 21.9× faster and emits 84.5× smaller patches; its repaired code has a 1.16× overall geometric-mean runtime advantage on the matched workload.Source: §6.4 · pp. 12, 14, §6.5 · p. 14

6.4 RQ1: Repair Effectiveness

  • Both systems repair all 38 shared one-input functions at all three thresholds, but NPTaylor’s median repair time rises from 2.78s at Lε to 3.74s at Hε as one-piece coverage falls from 38/38 to 31/38.Repairs are checked on emitted code using deterministic local samples, guard endpoints, and the pre-repair peak input; reported post-repair errors use 10,000 samples per domain.Source: §6.4 · pp. 11–12, §6.3 · p. 11

6.5 RQ2: Repair Quality and Runtime Impact

  • NPTaylor patches speed up inputs inside the guard by 2.90× geometrically and remain near parity outside it at 0.98×, while larger multi-input boxes can exhaust the fixed synthesis budget.Successful direct multi-input repairs have median 12.73–20.10s repair times and 22.4KB patches; the reported outside-box speedup is 0.99×.Source: §6.4 · p. 13, §6.5 · pp. 14–15

6.6 Limitations and Threats to Validity

  • The checker validates recorded local samples, endpoints, and the pre-repair peak, but does not prove full-domain error bounds or continuity across pieces.The experiments check scalar return values, not all library side channels such as status codes, errno, or floating-point exception flags; the pole case also requires factoring its dominant singular term before polynomial repair works.Source: §6.6 · p. 15

7 Related Work

Related work spans floating-point repair, polynomial approximation, and numerical analysis; NPTaylor combines standard approximation and evaluation ingredients in a checked local-repair loop rather than offering a general verifier.

7.1 Automated Floating-Point Repair and Accuracy Improvement

  • NPTaylor supports ill-conditioned cases excluded by ACESO and OFP-Repair, using high-precision coefficients and EFT-based transformations.Other systems detect high-error inputs, improve expression accuracy, or repair numerical-library errors; AutoRNP is the matched repair baseline.Source: §7.1 · p. 15

7.2 Polynomial Approximation and Library Implementation

  • Taylor polynomials, Horner schemes, and compensated arithmetic are established tools; NPTaylor's contribution is the checked repair loop around emitted, guarded C fragments.That loop is evaluated on localized library errors against a matched baseline.Source: §7.2 · p. 16

7.3 Floating-Point Analysis and Verification

  • Unlike FPTaylor, NPTaylor does not emit proof certificates or act as a general-purpose verifier; it validates local thresholds on recorded repair-domain inputs.Floating-point analysis and verification work instead addresses bounding roundoff error or checking numerical properties.Source: §7.3 · p. 16

8 Conclusion

NPTaylor synthesizes guarded Taylor patches for localized high-error domains and validates the emitted C code. On the one-input GSL workload, it matches AutoRNP's repair coverage at lower repair cost, while also handling bounded multi-input cases.

8 Conclusion

  • NPTaylor uses localized high-error domains to synthesize guarded Taylor patches, lowers candidates to fixed-order C, and accepts them after validation on recorded repair-domain inputs.The patch preserves the original routine outside its guard.Source: §8 · p. 16
  • Both systems repaired all 114 one-input GSL configurations; NPTaylor had a 3.33× geometric-mean repair-time advantage, emitted 0.162× as many C bytes, and repaired bounded multi-input cases.Its strict-setting maximum paired repair-time speedup was 157.1×.Source: §8 · p. 16
  • The supported scope excludes full-domain proofs, arbitrary multi-input repair, and automatic selection of singular representations.The conclusion frames the results as localized one-input repair and bounded multi-input capability analysis.Source: §8 · p. 16

Data Availability

The accompanying artifact includes NPTaylor and materials for reproducing the GSL benchmark experiments.

Data Availability

  • The artifact includes NPTaylor source code, GSL experiment scripts, Docker build files, benchmark harnesses, and cached result tables used in Section 6.Source: Data Availability · pp. 16–17
  • Fresh reproduction runs write to separate output directories and do not overwrite the bundled paper data.Source: Data Availability · p. 17
  • The authors state that the artifact will be made publicly available upon publication.Source: Data Availability · p. 17
Loading 2610.14444v1…