{"id":"000fef79-a6bc-44bb-a691-02c3068bd821","arxiv_id":"1909.01656","paper_version":3,"verdict":"ACCEPT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"low","formal_verification":"none","parameter_count":3,"one_line_summary":"A Fortran implementation of the Vollinga-Weinzierl algorithm evaluates generalised polylogarithms up to weight five quickly enough for Monte Carlo integration.","lead":"handyG is a new Fortran 90 library that rapidly computes generalised polylogarithms, special functions that appear in high-precision particle physics calculations. It is about twenty times faster than the standard GiNaC tool on typical physics examples, making it practical to call these functions inside Monte Carlo integrators.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Correctness rests on an external termination proof and GiNaC-only validation, so a shared algorithmic bug would go undetected; independent numerical cross-checks are needed.","rationale":"The central claim has two parts: (i) handyG correctly evaluates GPLs, and (ii) it does so fast enough for Monte Carlo integration. The speed part is supported by the benchmark and the 20× speed-up over GiNaC is plausible; the main risk there is benchmark methodology, but it is not the weakest link. The correctness part is the true load-bearing assumption: the paper's Section 4.4 explicitly outsources the termination proof of the Hölder-convolution recursion to reference [9], and the validation against GiNaC cannot detect a bug shared by both implementations because both use the same algorithm. The paper does provide strong evidence: public code, a large number of random tests, and agreement with GiNaC on physics-motivated sets, and I am not claiming the algorithm is wrong. But the central claim would fail if that external proof had a hidden gap or if both implementations made the same systematic error. This is precisely the reader's weakest assumption, and it is testable. I also note a concrete documentation inconsistency between the Fortran example (Listing 3) and the Mathematica example (Listing 4) for the same GPLs; while this is probably a typo, it shows the outputs need careful independent checking. Therefore I would not reject the paper, but I would make acceptance conditional on an independent numerical cross-check of a representative sample, plus correction of the example inconsistency. If the cross-check passes, the ACCEPT verdict is fully justified.","tokens_in":22398,"tokens_out":18923,"duration_ms":179154,"concrete_test":"Select 100–200 GPLs from the paper's test sets, deliberately including weight-4 and weight-5 functions with parameters satisfying 1 ≤ |w_i| < 1.1 (the Hölder-transformation region) and with i0± prescriptions. Evaluate the same functions with an independent arbitrary-precision method that does not use the Vollinga–Weinzierl recursion, e.g., direct high-precision numerical integration of the nested integral (1) via mpmath or SageMath, or summation of the converged series (6) after verifying convergence. Compare to handyG to 10–12 significant digits. If every value agrees, the shared-algorithm concern is resolved; any mismatch or non-termination would refute the correctness claim.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The correctness and termination of every evaluation depend on the Vollinga–Weinzierl recursion used in Section 4, especially the Hölder convolution step (Eq. 31) and the claim in Section 4.4 that this recursion always terminates. The paper explicitly does not prove this, writing that '[9] proved that this method indeed works'; it is an external, unverified assumption. The only numerical validation in Section 5 is agreement with GiNaC, which implements the same algorithm, so a systematic error in the algorithm or in a common interpretation of it would be invisible to the tests. In addition, the paper's own example is internally inconsistent: Listing 3 evaluates G(1±,0,5;1/x) and reports −0.961279±0.662888i, while Listing 4, written as G[1±,5,1/x], reports −1.12732±0.701026i; this is a different function unless the Mathematica syntax silently inserts a zero, so at least one documented output is wrong. This documented inconsistency reinforces that the validation chain needs an independent check.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents handyG, a Fortran 90 library for the numerical evaluation of generalised polylogarithms (GPLs) appearing in higher-order QFT calculations. The library implements the algorithm of Vollinga and Weinzierl, as previously used in GiNaC, and provides a Fortran module, a Mathematica interface, and a simple command-line tool. The paper defines the relevant notation, reviews the algorithm (removal of trailing zeros, reduction to convergent series via pending integrals, and Hölder convolution to accelerate convergence), gives installation and usage instructions, and reports benchmark results: on 3329 GPLs taken from published two-loop calculations, handyG is on average about twenty times faster than GiNaC (1100 versus 60 GPLs per second), with claimed complete agreement with GiNaC on all test sets. The source code is publicly available under GPLv3.","tokens_in":22593,"tokens_out":7359,"duration_ms":74986,"significance":"If the implementation is correct, handyG fills a practical need: existing GPL evaluation in GiNaC is symbolic and too slow for direct Monte Carlo integration, whereas handyG is a compiled Fortran library suitable for that purpose. The paper's strengths are that the implementation is based on a published algorithm, the code is publicly available, the benchmark set includes a large number of functions from realistic physics calculations as well as millions of random tests, and there are no fitted parameters or circular self-validations. The main weakness is that all numerical validation is against GiNaC, which implements the same algorithm, so a shared systematic error would not be detected; this limitation is acknowledged only indirectly. In addition, the paper contains a concrete internal inconsistency in its own usage example, which must be resolved before the correctness claims can be accepted as documented.","major_comments":[{"comment":"The two listings give contradictory outputs for functions that Eq. (14) defines as G(1±,0,5;1/x). In Listing 3, the Fortran call G([inum(1.,+1),inum(0,+1),inum(5,+1)], inum(1/x,di0)) returns −0.961279−0.662888i for the + prescription, while Listing 4, written as G[1+,5,1/x] in Mathematica, returns −1.12732−0.701026i. Since both listings claim to evaluate the functions of Eq. (14), the manuscript as written reports two different values for the same mathematical function. Either the Mathematica syntax omits a zero and therefore evaluates a different GPL, or one of the two outputs is incorrect. This is a load-bearing correctness issue: please correct the Mathematica example (for instance G[1+,0,5,1/x] if flat notation is intended) or explicitly state that the line evaluates a different function, and verify which numerical result is correct.","section":"Sections 3.2 and 3.3, Eq. (14), Listings 3 and 4"},{"comment":"The claim of 'complete agreement with GiNaC' is not quantified: no tolerance, no definition of agreement, and no statement of how many digits were compared. More importantly, all validation is against GiNaC, a library that implements the same underlying Vollinga–Weinzierl algorithm, so a systematic error in the algorithm or in a shared implementation detail would be invisible to these tests. I request at least one independent cross-check, for example comparison with high-precision direct numerical integration for a modest subset of functions, evaluation of known special values, or comparison with an independent implementation or series representation. This would also help resolve which of the two outputs in Listings 3 and 4 is correct.","section":"Section 5, validation and performance"}],"minor_comments":[{"comment":"The text says 'In all four test cases we find complete agreement with GiNaC', but the list that immediately precedes it contains six test sets (items 0 through 5). Please correct the count or reword to 'all test cases'.","section":"Section 5, first paragraph"},{"comment":"The timing histograms are described as averages over five successive calls, but no run-to-run variation, error bars, or compiler optimisation flags are given. A brief statement of the timing methodology (for example, median versus mean, and number of repetitions) would make the performance claims easier to interpret.","section":"Figures 5–7"},{"comment":"There is a typographical garble in the displayed integrand of Eq. (17), with a repeated or misplaced 'd w_{r+1}/w' fragment. Please correct the formula so that the integration measure and denominator are unambiguous.","section":"Equation (17)"},{"comment":"The proof that the Hölder convolution terminates is cited to [9] with only a short intuitive explanation. Since this termination property is essential for the algorithm, a more specific pointer to the relevant statement in [9] would help the reader verify the claim without reproducing the entire proof.","section":"Section 4.4"},{"comment":"There are several minor typographical issues, such as 'poly logarithms' and 't he' in the abstract and program summary, and an inconsistent number of items in the enumerated list in Section 5. A careful proofread is recommended.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"This is a useful and potentially widely used software paper, and I do not see a fundamental flaw in the underlying approach. My recommendation of major_revision is driven primarily by the unresolved contradiction between Listings 3 and 4 for the same mathematical function, which directly affects the paper's correctness claims, and by the absence of any independent numerical validation. If the authors fix the example and add at least one independent cross-check with a clear agreement criterion, I would be happy to reconsider."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Take this one as a solid software paper, not a conceptual advance. The genuinely new thing is a maintained Fortran 90 library that evaluates generalised polylogarithms fast enough for Monte Carlo integration, with a public repository, a working i0+ prescription, a cache, and a Mathematica interface. The authors are explicit that the underlying algorithm is Vollinga and Weinzierl (2005), and they do not oversell the mathematics.\n\nWhat the paper does well is validation and packaging. The benchmark covers 3329 functions from published two-loop calculations plus random weight-5 inputs, and the reported factor of roughly twenty over GiNaC (1100 vs 60 GPL/s) supports the central claim for weights up to five. The test sets are physics-motivated, the source is public, and the build/test path is standard. The limitation note about practical weights above seven is honest.\n\nSoft spots: correctness and termination are assumed from the Vollinga–Weinzierl proof, which is cited rather than reproduced, and the numerical validation is only against GiNaC, which implements the same algorithm, so a shared algorithmic bug would be invisible. That is a real caveat but a common and acceptable one for a port; one independent high-precision check would make it nearly bulletproof. The timing numbers are averages of five calls without error bars; minor. More visible is an inconsistency in the usage example: Listing 3 evaluates G(1±,0,5;1/x) and reports -0.961279 ± 0.662888i, while Listing 4, advertised as the same function in Mathematica, reports -1.12732 ± 0.701026i. At least one of those documented outputs is wrong or the syntax is not doing what the text claims. That is the first thing a user tries, so it should be fixed.\n\nWho this is for: anyone doing NNLO or N3LO phase-space integration in Fortran who needs GPL values inline. It deserves a serious referee. I would send it to review and ask for the example discrepancy to be fixed and an independent numerical cross-check added; with those, accept.","headline":"A clean, honest software port that is genuinely useful for Fortran Monte Carlo work; fix the example mismatch and add one independent check.","tokens_in":23121,"tokens_out":3545,"would_cite":true,"duration_ms":34432,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A Fortran 90 library evaluates generalised polylogarithms of current NNLO/N3LO weights at roughly 1100 per second — about twenty times faster than GiNaC — making Monte Carlo integration practical.","keywords":["generalised polylogarithms","Goncharov polylogarithms","numerical evaluation","Monte Carlo integration","Feynman integrals","Fortran 90","Vollinga-Weinzierl algorithm"],"falsifier":"Take a battery of GPLs whose parameters lie on or just inside the unit circle, for instance $G(1,1,1;1)$ or cases with two parameters of equal modulus, and compare handyG's output with an independent high-precision method that does not use the Vollinga–Weinzierl reduction, such as numerical quadrature of the defining nested integral at high precision. Any mismatch beyond the stated tolerance, or any input on which the recursion fails to terminate, would falsify the paper's claim of reliable fast evaluation.","tokens_in":22198,"feed_emoji":"⚛️","tokens_out":13131,"duration_ms":108342,"temperature":0.7,"pith_summary":"This paper presents handyG, a Fortran 90 library that numerically evaluates generalised polylogarithms — the nested-integral functions that appear naturally in higher-order quantum field theory calculations. The central claim is that, by implementing the Vollinga–Weinzierl algorithm in compiled Fortran rather than as a symbolic routine, the library is fast enough to be called many times inside a Monte Carlo phase-space integration. On 3329 representative GPLs drawn from current two-loop calculations, handyG evaluates about 1100 functions per second versus about 60 per second for the C++ algebra system GiNaC, and it agrees with GiNaC on all physics test sets considered. The paper's point, taken in good faith, is that the numerical bottleneck for fully differential NNLO and N3LO calculations with several scales is now removed.","feed_headline":"Fortran library evaluates generalised polylogarithms 20× faster","feed_subtitle":"HandyG runs the Vollinga-Weinzierl algorithm directly in compiled code, making NNLO Monte Carlo integrations practical.","key_machinery":"The load-bearing mechanism is the Vollinga–Weinzierl reduction algorithm, which rewrites any generalised polylogarithm $G(a_1,\\ldots,a_n;x)$ into a sum of convergent multiple polylogarithms. Three recursive steps do the work: the shuffle algebra removes trailing zeros, which would otherwise violate the convergence criterion $|x|<|a_i|$ for all $i$; the parameter with the smallest absolute value is eliminated through the fundamental theorem of calculus, producing 'pending integrals' of lower depth that are then collapsed back into ordinary GPLs; and the Hölder convolution equation (Eq. 31), $G(\\vec a;1)=\\sum_{j=0}^n(-1)^j\\,G(1-a_j,\\ldots,1-a_1;1-1/z)\\,G(a_{j+1},\\ldots,a_n;1/z)$, specialised to $z=2$, maps parameters near the unit circle to parameters twice as large so the series converges faster. The paper relies on the literature's proof that this recursion always terminates and yields convergent series for arbitrary complex parameters.","core_discovery":"The paper's discovery is that a compiled, dependency-free Fortran implementation of the Vollinga–Weinzierl reduction algorithm can evaluate the generalised polylogarithms that appear in current NNLO and N3LO calculations quickly enough for Monte Carlo integration. Concretely, handyG reaches average rates of about 1100 GPLs per second — functions of weight up to five evaluate in the millisecond range — on a benchmark of 3329 GPLs collected from heavy-to-light form factors, muon–electron scattering, and Bhabha scattering, with complete agreement with GiNaC on these physics test sets. The library supplies the $i0^+$ prescriptions needed in physical kinematic regions, a cache of classical polylogarithms, and direct interfaces for Fortran and Mathematica.","pith_inferences":["Caching entire evaluated GPLs rather than just classical polylogarithms — an extension the paper does not implement — would likely speed up Monte Carlo sweeps that repeatedly hit the same weight list.","The twenty-fold speedup is an average over the benchmark distribution; for GPLs with many parameters crowding the unit circle, more Hölder recursion is triggered and the margin over GiNaC should narrow, a prediction consistent with the paper's weight-dependence plot.","Parallelising the independent lower-weight pieces generated by the Hölder convolution could push the practical weight range beyond seven, since the recursion fans out into many independent GPLs.","A sharpened version of the cited termination proof, giving explicit bounds on recursion depth, would turn the paper's heuristic 'usually terminates' into guaranteed per-call cost estimates for event generators."],"forward_implications":["Physicists can integrate over generalised polylogarithms directly inside Fortran Monte Carlo codes at NNLO and N3LO, rather than stopping at analytic or symbolic evaluation.","The compiled implementation removes the need to link a C++ computer algebra system into a Fortran event generator to obtain numerical values for these functions.","Because handyG and GiNaC agree on the physics test sets, handyG can serve as a fast cross-check companion for results produced by GiNaC or the Maple implementation of the same algorithm.","Weights up to five evaluate in the millisecond range with default settings, so realistic phase-space integrations over GPLs become practical; the paper identifies runtime, not an algorithmic ceiling, as the limit for weights above about seven."],"supporting_citations":[{"why":"Defines the Vollinga–Weinzierl algorithm that handyG implements, including the convergence criterion and the termination proof for the recursion.","marker":"[9]"},{"why":"Supplies the Hölder convolution equation used to accelerate convergence for GPLs whose parameters lie near the unit circle.","marker":"[15]"},{"why":"Provides the 540 GPLs entering the heavy-to-light form factor with full mass dependence, the first physics test set.","marker":"[16]"},{"why":"Provides the 1399 master-integral GPLs of the heavy-to-light form factor used in the validation benchmark.","marker":"[17]"},{"why":"Provides the 198 planar muon–electron scattering GPLs in the unphysical region used as a test set.","marker":"[18]"},{"why":"Provides the 1732 non-planar muon–electron scattering GPLs that form the largest physics benchmark set.","marker":"[19]"},{"why":"Supplies the GPL expression of the two-loop Bhabha scattering master integrals used as a further validation set.","marker":"[21]"},{"why":"Defines GiNaC, the symbolic C++ algebra system whose evaluation speed is the baseline for the twenty-fold speedup comparison.","marker":"[22]"}],"fun_headline_variants":["HandyG: 1100 GPLs per second for fast Monte Carlo","HandyG: weight-5 polylogarithms in milliseconds","HandyG: Vollinga-Weinzierl algorithm in Fortran for GPLs","HandyG: 1100 GPLs/sec for Monte Carlo integration","HandyG: fast GPL evaluation for NNLO computations"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole evaluation rests on a published proof, cited but not reproduced in this paper, that the algorithm's recursion always terminates and produces convergent series for any complex parameters; agreement with GiNaC cannot expose a mistake both programs share, because GiNaC uses the same algorithm.","fun_headline_variants_meta":{"raw":{"variants":["HandyG: 1100 GPLs per second for fast Monte Carlo","HandyG: weight-5 polylogarithms in milliseconds","HandyG: Vollinga-Weinzierl algorithm in Fortran for GPLs","HandyG: 1100 GPLs/sec for Monte Carlo integration","HandyG: fast GPL evaluation for NNLO computations"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001266,"raw_usage":{"total_tokens":5087,"prompt_tokens":755,"completion_tokens":4332,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":371,"completion_tokens_details":{"reasoning_tokens":4232}},"tokens_in":371,"tokens_out":4332,"duration_ms":28805,"temperature":1.0,"reasoning_tokens":4232,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T05:10:51.493248+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a battery of GPLs whose parameters lie on or just inside the unit circle, for instance $G(1,1,1;1)$ or cases with two parameters of equal modulus, and compare handyG's output with an independent high-precision method that does not use the Vollinga–Weinzierl reduction, such as numerical quadrature of the defining nested integral at high precision. Any mismatch beyond the stated tolerance, or any input on which the recursion fails to terminate, would falsify the paper's claim of reliable fast evaluation.","supporting_citations":[{"cited_title":"Master integrals for the NNLO virtual corrections to $\\mu e$ scattering in QED: the non-planar graphs","cited_arxiv_id":"1806.08241","evidence_quote":"Provides the 1732 non-planar muon–electron scattering GPLs that form the largest physics benchmark set."},{"cited_title":"Bauer, C","cited_arxiv_id":null,"evidence_quote":"Defines GiNaC, the symbolic C++ algebra system whose evaluation speed is the baseline for the twenty-fold speedup comparison."}],"review_version":1}