You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The special functions have no compiled form, and neither do x!, gamma and phi under Compile<TIn, TOut> #1607
What you ran: "erf(x) = x/2 + 1/7".ToEntity().Solve("x"), and "erf(x)".ToEntity().Compile("x") or Compile<double, double>("x").
What it did: Compile throws UncompilableNodeException for erf, erfc, erfi, Ei, li, Si, Ci, Shi and Chi. So Solve's numerical search cannot run on such an equation: it threw in 2.5.0 (#1603), and with #1605 it leaves the equation unsolved. Under Compile<TIn, TOut> there is no form for x!, gamma(x) or phi(x) either, though Compile has one.
What it should have done: Compile them, as suggested on #1605, in agreement with the interpreter, branch cuts included. The library's own kernels are too slow to call from compiled code. At 20 digits they take 0.7 to 5.5 ms a call on Newton's starting grid (erf 1.6 ms, erfc 5.5 ms, Si 0.7 ms). Newton evaluates 30 steps from each of 100 starting points, so one equation would take seconds. Each function needs a double-precision routine of its own.
double precision routine... sounds similar to the new numerical architecture of v3 that we piloted for the integrator... for fast evaluations there seems to be code sharing opportunities
Agreed. The interval evaluation, the fast tier the integrator's checks run on (#1497), reads no special function today, so a check with erf or Ei in it falls back to the decimal evaluation. #1613 now puts the routines in AngouriMath.Numerics, beside it, so the compilers and the evaluator can share one copy. For the interval tier they need an enclosure. On a monotone stretch of the real line, such as erf, erfi and Shi everywhere and Ei on either side of 0, where it is singular, that is the image of the interval's ends, widened. Their error against the kernels is measured, at most 3e-13 of the value, not proved, so the widening has to be wider than that. I'll take that up after #1607's second half: x!, gamma and phi under Compile<TIn, TOut>.
Activity
The floors, the rounding and the extremes compile, and Solve's numeri…
erfc on the imaginary axis keeps its real part of 1 past the series' …
erfc far out on the right returns at once, and keeps its real part on…
Happypig375 commentedon Sep 30, 2026
double precision routine... sounds similar to the new numerical architecture of v3 that we piloted for the integrator... for fast evaluations there seems to be code sharing opportunities
Rafael-SOWNet commentedon Sep 30, 2026
Agreed. The interval evaluation, the fast tier the integrator's checks run on (#1497), reads no special function today, so a check with
erforEiin it falls back to the decimal evaluation. #1613 now puts the routines inAngouriMath.Numerics, beside it, so the compilers and the evaluator can share one copy. For the interval tier they need an enclosure. On a monotone stretch of the real line, such aserf,erfiandShieverywhere andEion either side of 0, where it is singular, that is the image of the interval's ends, widened. Their error against the kernels is measured, at most3e-13of the value, not proved, so the widening has to be wider than that. I'll take that up after #1607's second half:x!,gammaandphiunderCompile<TIn, TOut>.SpecialFunctions moves to Numerics, beside the interval evaluation
SpecialFunctions moves to Numerics, beside the interval evaluation
The special functions compile, in double precision (#1613)
The interval evaluation reads the special functions (#1621)
The factorial, gamma and the totient compile under Compile<TIn, TOut> (…