{"id":"b50c1d46-d3d0-4895-baf3-91d1683b364b","arxiv_id":"2412.11437","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"The paper ports a Mathematica form factor reader to C, reporting a 64x speedup and matching decay rate plots, though validation is visual and the code is not versioned.","lead":"This paper presents a C code that reads lattice QCD data for the Lambda_b to Lambda_c decay and computes decay rates over 64 times faster than an older Mathematica program, with a web interface for non-programmers. A particle physicist running scans of new physics scenarios could use it to get the same results in a fraction of the time.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"No numerical equivalence check supports the 'identical results' claim; visual agreement of Figs. 2–3 cannot validate the 64.2x speedup claim.","rationale":"The paper's contribution is a software artifact, so the correctness argument should be the artifact's behavior. The reader's CONDITIONAL verdict is appropriate. My independent reading found the same weakest assumption: validation is by visual comparison only. The appendix describes the C implementation but supplies no regression tests, no expected-value tables, and no numerical comparison against either the prior Mathematica code or the published lattice-QCD results in Ref. [1]. The 64.2x timing ratio in Table 1 is plausible and reproducible in principle, but a timing comparison is only meaningful if the outputs are identical to within floating-point/algorithmic tolerance; otherwise the faster code is solving a different problem. There is no internal inconsistency in the physics formulas, and the speed claim is not contrary to consensus, so the issue is strictly an evidence gap. The concrete test above is cheap and would settle it. Because my concern is exactly the reader's, no verdict adjustment is needed; I recommend UNCHANGED (i.e., keep CONDITIONAL) pending the numerical comparison.","tokens_in":7021,"tokens_out":3185,"duration_ms":30441,"concrete_test":"Obtain the Mathematica code from Ref. [1] and the C code from the stated GitHub repository. Run both on the same covariance and higher-order data files on the same q2 grid used in Figs. 2–3 (and at 10,000 points for the timing test), export raw output columns (q2, dGamma/dq2, error), and compute the maximum and root-mean-square relative differences for the SM case and for the NP case gL=-2.2. Report whether every point agrees within a pre-specified tolerance (e.g., 1e-6 relative, or the round-off expected from double precision with the same algorithm); if the max relative difference in the central rate or error exceeds that tolerance, the 'identical results' claim is falsified and the port must be treated as a new calculation rather than a drop-in replacement.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the C code reproduces the Mathematica results exactly ('identical results', Conclusion) and is 64.2x faster (Section 3, Table 1). The only stated verification is the visual agreement of Figs. 2–3 with the sentence 'These graphs demonstrate that the C-code results align closely with the Mathematica results... confirming the correctness of the C implementation' (Section 4). No numeric tables, tolerances, or per-q2 differences are given. This matters because the code computes decay rates via 'numerical differentiation and error propagation' (Appendix) rather than necessarily reproducing Mathematica's analytic or semi-analytic algorithm; differences in interpolation, covariance handling (nominal vs higher-order fits), floating-point treatment, or ordering of operations can produce small offsets in central values and error bars that a plot at about 25 q2 points cannot resolve. If the outputs differ at the level of the plotted line width, the claim of faithfulness fails and the speedup is irrelevant: users would be getting a different answer faster. The inconsistency between the abstract's GitHub URL and the Section 3 URL is a secondary reproducibility concern, not the main logical gap.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript reports a C-language implementation that reads the lattice QCD form-factor data for Lambda_b -> Lambda_c l nu from Ref. [1] and computes differential decay rates for the tau mode. The code is a port of the Mathematica code used in Ref. [1]. The paper claims that the C code produces identical results to the Mathematica code and that it is about 64.2 times faster per data point (Section 3, Section 4, Table 1). It also describes a prototype Node.js web interface and plans for a generalized expression parser. The physics content is limited to reproducing the existing calculation; the central claims are correctness of the port and computational speed.","tokens_in":7221,"tokens_out":3121,"duration_ms":30771,"significance":"If the claims are substantiated, the code would be a useful practical tool for the heavy-flavor phenomenology community: lattice form-factor analyses of Lambda_b -> Lambda_c tau nu often require repeated evaluations, and a fast, open-source reader would lower the barrier to using the Ref. [1] data files. The paper's strengths are that the code is released on GitHub under GPL, the modular structure is described, and the speed comparison is performed at four different data-set sizes. However, the scientific value of the paper depends entirely on establishing that the C code reproduces the Mathematica results to numerical accuracy and that the speed measurement is meaningful. The current evidence for both is thin, so the significance is conditional on additional validation.","major_comments":[{"comment":"The claim that the C code gives 'identical results' to the Mathematica code is not supported by quantitative evidence. Section 4 says only that the graphs 'align closely' and 'confirm the correctness of the C implementation,' and Section 6 repeats 'identical results.' There is no numerical comparison: no table of q2 values, no maximum absolute difference, no root-mean-square difference, and no tolerance for the decay rates or their error bars. Because the appendix states that errors are computed using numerical differentiation and error propagation, small differences in interpolation or covariance handling could produce offsets that are invisible at the plotted line width. Please provide a quantitative equivalence test, for example a machine-readable diff of the C and Mathematica outputs at all q2 points, together with the maximum and mean absolute differences and a stated tolerance.","section":"Section 4 and Section 6"},{"comment":"The 64.2x speed ratio is derived from slopes of wall-clock-time plots, but the measurement is weakly documented. The text says five trials were averaged, but no variance, standard deviation, or individual trial times are reported, and Figure 4 shows no error bars. No hardware specifications, operating system, compiler version, compiler optimization flags, Mathematica version, or timing methodology are given, so the measurement cannot be reproduced. In addition, it is not stated whether the 10-point measurement includes Mathematica kernel startup, which would affect the slope interpretation. Please report per-trial timings, mean and standard deviation, the exact versions of all software, and a description of how wall-clock time was measured.","section":"Section 4, Table 1, and Figure 4"},{"comment":"The code availability statement is internally inconsistent: the abstract gives the URL as https://github.com/darkfiresmith96/Lattice_QCD while Section 3 gives https://github.com/darkfiresmith96/LatticeQCD (with visible spacing artifacts in the rendered text), and no version or commit hash is provided. Since the paper's central deliverable is a code release, a single working URL with a specific commit identifier, and a note on how to reproduce the benchmark from that version, is necessary. The current discrepancy makes the code effectively unreproducible as published.","section":"Abstract, Section 3, and Conclusion"}],"minor_comments":[{"comment":"The phrase 'Results of of the speed test' appears in both the table caption and the Figure 4 caption; delete the duplicated 'of.'","section":"Table 1 and Figure 4 captions"},{"comment":"The caption says 'Left and right panels are the linear and log plots, consequently,' but 'consequently' should be 'respectively.'","section":"Figure 4 caption"},{"comment":"The panels are described as 'Standard Model results' and 'new physics results,' but the new physics point (g_L = -2.2) is only stated in the figure captions; the ranges of the axes and the number of q2 points plotted would be clearer if stated in the text.","section":"Figures 2 and 3"},{"comment":"The acknowledgments refer to 'B.S.' without identifying this person in the author list, and the grant attribution is not linked to a named author; this should be clarified.","section":"Acknowledgments"},{"comment":"The web application is described as a prototype hosted on a free-tier Heroku instance, but no URL or repository location is given for the web code. Please provide access information or state that the web interface is not part of the released repository.","section":"Section 5"},{"comment":"Reference [6] is a conference talk and does not include a DOI or arXiv identifier; please verify that this citation is complete.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads as a software-release note rather than a new physics analysis. The core idea is modest but useful, and the requested revisions (quantitative validation, benchmark documentation, and a single citable code URL) are all within the scope of a revision. I do not see a fundamental obstruction that would require rejection, but the current version does not meet the evidentiary standard for a published claim of 'identical results' and a 64.2x speedup. The editor may also want to consider whether the journal is the right venue for a code documentation paper of this size."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: this is a software paper, not a physics paper. The authors translated the Mathematica code from Datta et al. (2017) into C, added a Node.js web interface, and measured a ~64x speedup. That is a legitimate engineering contribution, and the speedup is plausible for a lower-level language.\n\nWhat is actually new: the C implementation itself, the web prototype, and the benchmark. The decay-rate formalism and lattice inputs are all from Ref [1]; the paper adds no new physics, no new form factors, and no new observables. That is fine if the paper is positioned as a tool note, which it mostly is.\n\nWhere it softens: the correctness claim is the load-bearing wall, and it is not backed up. The paper says both codes produce 'identical results' but the only evidence is visual overlap in Figures 2 and 3 at about 25 q2 points. There is no numerical table, no maximum difference, no tolerance. For a code that uses numerical differentiation and error propagation, small differences in interpolation or floating-point order are expected; a plot line width can hide them. If the outputs differ by even 1%, the 64x speedup is not the point — users would be getting a different answer faster. The benchmark is also thin: five trials averaged with no standard deviation, no hardware or compiler versions, no Mathematica version, and the ratio is taken from slopes of plots. The GitHub URL in the abstract and Section 3 are inconsistent (one has Lattice_QCD, the other LatticeQCD, with a space in the abstract's typeset version), and there is no versioned archive. These are all fixable.\n\nI agree with the reader's conditional verdict. The paper is honest and straightforward, but the central equivalency claim is unverified. The fix is easy: run both codes on the same 25 or 100 q2 points, report max absolute and relative differences for central values and errors, and add a README with the exact benchmark environment and a DOI or stable repository.\n\nWho it's for: practitioners computing Lambda_b -> Lambda_c decay rates in the SM or NP scenarios who want a fast, redistributable reader for Meinel's lattice form factors. Once validated, it could be genuinely useful. As it stands, I would not trust the 'identical results' claim without running it myself.\n\nRecommendation: worth referee time for a computing-oriented venue or as a short tool paper, but only after the numerical validation is added. If the authors supply that, the speed and usability claims likely hold. I'd take it to review, not desk-reject, but I'd tell the authors the current validation is insufficient.","headline":"A plausible software port with a useful speedup, but the 'identical results' claim rests on visual agreement only and needs numerical validation before the tool can be trusted.","tokens_in":7725,"tokens_out":2687,"would_cite":false,"duration_ms":22700,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A C reimplementation of the lattice QCD form-factor reader for $\\Lambda_b \\to \\Lambda_c \\ell^- \\bar{\\nu}_\\ell$ matches the Mathematica output while running about 64 times faster per data point.","keywords":["C code","lattice QCD form factors","Lambda_b to Lambda_c decay","differential decay rate","Mathematica comparison","new physics couplings","web application","error propagation"],"falsifier":"Run both codes on the same covariance files and compare every printed value of $q^2$, the differential decay rate, and its error using a numerical tolerance such as a relative difference below $10^{-12}$; any point above that tolerance would show that the C code does not reproduce the Mathematica results, making the speed comparison less meaningful.","tokens_in":6831,"feed_emoji":"⚡","tokens_out":7173,"duration_ms":55675,"temperature":0.7,"pith_summary":"This paper claims that a C-language program can read the lattice QCD form factors for the decay $\\Lambda_b \\to \\Lambda_c \\ell^- \\bar{\\nu}_\\ell$ and generate the same differential decay-rate data as a previous Mathematica implementation, but about 64 times faster per data point. The program implements the full set of scalar, vector/axial-vector, and tensor form factors and the effective Hamiltonian with new-physics couplings, including error propagation from the lattice covariance matrices. The reported agreement with the earlier code is based on plotted curves; if the agreement is exact, the practical gain is that new-physics parameter scans and fits become much cheaper and the analysis is easier to embed in other tools.","feed_headline":"C rewrite reproduces Mathematica form-factor results 64x faster","feed_subtitle":"Open-source C code computes Lambda_b to Lambda_c rates in a fraction of the time, with a web interface.","key_machinery":"The carrying object is the C program itself, organized as main.c with supporting modules for constants, calculations, and file manipulation. It maps the data flow of the Mathematica code into custom read-file functions for the lattice covariance matrices, then computes nominal and higher-order form factors and the hadronic helicity amplitudes entering the decay rate. Error propagation is handled by numerical differentiation, and the output is a tabulated file of $q^2$, differential decay rate, and error. A companion web interface runs the same C program on a server through a graphical input page.","core_discovery":"The central claim is that the C implementation is a faithful, much faster replacement for the Mathematica reader used in Ref. [1] for the lattice QCD form factors of $\\Lambda_b \\to \\Lambda_c$. The code reads the nominal and higher-order covariance files, reconstructs the ten form factors $F_0,F_+,F_\\perp,G_0,G_+,G_\\perp,h_+,h_\\perp,\\tilde{h}_+,\\tilde{h}_\\perp$, computes the differential decay rate for the Standard Model and for new-physics scenarios such as $g_L=-2.2$, and propagates uncertainties. The paper reports \"identical results\" at the level of the plotted differential distributions and a wall-clock ratio of 1:64.2 per data point in favor of the C code.","pith_inferences":["An implication the author leaves implicit is that the speedup makes Monte Carlo or profile-likelihood fits to LHCb's $\\Lambda_b$ decay ratios practical, because a single likelihood evaluation drops from seconds to tens of milliseconds.","A testable extension is to add a numerical regression test to the released code that compares its output against a stored reference file from the Mathematica code with a fixed tolerance, converting the visual check into a reproducible assertion.","The architecture is portable to other flavor transitions: replacing the form-factor parametrization and hadron masses would give the same speed advantage, though the Hamiltonian and helicity amplitudes would need to be rewritten."],"forward_implications":["New-physics scans over the couplings $g_L,g_R,g_S,g_P,g_T$ become roughly two orders of magnitude cheaper, allowing thousands of $q^2$ points per parameter choice.","The analysis becomes reproducible without a Mathematica license, since the C code and its data files are distributed openly and the web interface hides the compilation step.","The same structured reader can be adapted to other lattice form-factor data sets that publish covariance matrices, extending the speed gain to related decays.","If the planned LaTeX-expression interface is completed, the tool generalizes from this decay to arbitrary user-provided expressions and data files."],"supporting_citations":[{"why":"Supplies the Mathematica code and reference results that the C implementation is built to reproduce and benchmark against.","marker":"[1]"},{"why":"Provides the 2+1-flavor lattice QCD calculation from which the $\\Lambda_b \\to \\Lambda_c$ form factors are taken.","marker":"[27]"},{"why":"Defines the ratios used to extract the tensor form factors and their uncertainties.","marker":"[28]"},{"why":"Sets the effective Hamiltonian for $b \\to c \\tau \\bar{\\nu}_\\tau$ including scalar and tensor operators used in the code.","marker":"[29]"},{"why":"Gives the lattice-QCD-based operator basis for the effective Hamiltonian at the $m_b$ scale.","marker":"[30]"},{"why":"Supplies an additional parametrization of the effective Hamiltonian with scalar and tensor operators used in the helicity-amplitude decomposition.","marker":"[31]"}],"fun_headline_variants":["C code reads lattice QCD form factors 64x faster than Mathematica","Open-source C reader for Lambda_b decay form factors, 64x speedup","Lattice QCD form factors: C code beats Mathematica 64:1 per point","Lambda_b to Lambda_c: C form-factor reader 64x faster, web UI","C implementation reproduces form-factor results with 64x speed gain"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The verification of \"identical results\" rests on visual agreement between plotted curves, so a discrepancy too small to see in the figures would not be caught, and the central speedup claim is meaningful only if the numerical outputs actually match.","fun_headline_variants_meta":{"raw":{"variants":["C code reads lattice QCD form factors 64x faster than Mathematica","Open-source C reader for Lambda_b decay form factors, 64x speedup","Lattice QCD form factors: C code beats Mathematica 64:1 per point","Lambda_b to Lambda_c: C form-factor reader 64x faster, web UI","C implementation reproduces form-factor results with 64x speed gain"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000198,"raw_usage":{"total_tokens":1298,"prompt_tokens":803,"completion_tokens":495,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":419,"completion_tokens_details":{"reasoning_tokens":390}},"tokens_in":419,"tokens_out":495,"duration_ms":4063,"temperature":1.0,"reasoning_tokens":390,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T14:55:42.277825+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run both codes on the same covariance files and compare every printed value of $q^2$, the differential decay rate, and its error using a numerical tolerance such as a relative difference below $10^{-12}$; any point above that tolerance would show that the C code does not reproduce the Mathematica results, making the speed comparison less meaningful.","supporting_citations":[{"cited_title":"Lepton angular asymmetries in semileptonic charmful B decays","cited_arxiv_id":"hep-ph/0503123","evidence_quote":"Sets the effective Hamiltonian for $b \\to c \\tau \\bar{\\nu}_\\tau$ including scalar and tensor operators used in the code."}],"review_version":1}