{"id":"5f9b4d39-8de7-4309-8d30-8bb60f481d40","arxiv_id":"2509.10934","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Posit arithmetic offers better accuracy and lower hardware cost than log-space arithmetic for statistical computations that produce extremely small probabilities.","lead":"This paper compares three ways to store tiny probabilities: IEEE double-precision, log-space, and the posit format. It finds that posits can be both more accurate and cheaper to implement than log-space for statistical workloads like genomics, on FPGA accelerators.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Application accuracy is measured only as linear-space relative error; the paper never tests whether the two-orders-of-magnitude advantage changes any downstream variant call or parameter estimate.","rationale":"I focused on the accuracy metric because the paper's novelty claim is that posit is inherently better than log-space for small-probability statistics. The arithmetic-level analysis is internally consistent and the choice of posit configs is honestly discussed; the hardware baseline (MArTo vs LogiCORE) could inflate resource/perf gains, but that is a secondary concern already noted by the reader. The unvalidated link between relative-error improvements and application outcomes is the weakest load-bearing step: the paper's own data show posit underflows on a few p-values, yet the paper does not quantify the effect on the actual decision boundary. The proposed test is directly implementable with the existing datasets and would settle whether the accuracy advantage changes any statistical conclusion. Until that test is run, conditional acceptance is appropriate. My read agrees with the reader's weakest_assumption.","tokens_in":20332,"tokens_out":19556,"duration_ms":246590,"concrete_test":"Using the eight SARS-CoV-2 datasets, rerun LoFreq variant calling with the log-space baseline, the posit(64,12) accelerator, and an MPFR ground-truth reference; compare the exact set of columns called variant (p < 2^-200) and the p-value ordering. If the call sets are identical, the accuracy advantage does not translate into better statistical decisions. Complement with a VICAR run: execute the full variational inference with both formats on the HCG data and compare the final evolutionary parameter estimates; if they agree within the convergence tolerance, the headline accuracy gain has no downstream consequence.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that posit is a better strategy for statistical computations rests on three metrics: accuracy, resources, and speed. The accuracy leg is the most load-bearing because it is presented as a fundamental advantage of the encoding, not an implementation detail. Section VI-A defines application accuracy as relative error of final likelihoods/p-values against 256-bit MPFR, and Section VI-D reports two-orders-of-magnitude improvements. But LoFreq is a decision rule (p < 2^-200) and VICAR's downstream variational inference depends on log-likelihood values and differences. Relative error in linear probability is approximately absolute error in log-likelihood, so it is not automatically the wrong measure; however, the paper never shows that the accuracy gap changes any decision. In fact, posit(64,12) underflows on 2 of 222,131 p-values and has relative errors up to 10^2129 on 2 others (Section VI-D), while the log-space baseline never underflows. Whether these errors alter the called variant set or the estimated evolutionary parameters is unreported. If the call sets are identical, the two-orders-of-magnitude accuracy advantage is real but practically irrelevant, and the claim that posit is a better strategy for statistical computations is overreach.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that the standard log-space approach to statistical computations on extremely small probabilities is suboptimal in numerical accuracy, performance, and hardware cost, and that the posit format is a better strategy. It compares binary64, log-space arithmetic, and three posit configurations at the level of individual arithmetic operations, then builds FPGA accelerators for two bioinformatics applications (VICAR's HMM forward algorithm and LoFreq's Poisson-binomial p-value computation). The reported results claim up to two orders of magnitude higher accuracy, up to 60% lower resource use, up to 33% higher performance, and about 2x performance per resource unit versus log-space accelerators. The central accuracy claim is based on relative error of final likelihoods/p-values against 256-bit MPFR results.","tokens_in":20594,"tokens_out":5973,"duration_ms":77938,"significance":"If fully substantiated, the paper would be a useful contribution to numerical analysis and FPGA acceleration for underflow-prone statistical workloads. It provides a quantitative comparison of three number representations, builds optimized accelerators for two real applications, and shows a plausible mechanism by which posit's dynamic exponent/fraction allocation could improve accuracy over log-space. The paper also gives credit to careful use of real datasets (SARS-CoV-2, HCG) and an MPFR ground truth, which strengthens the empirical component. However, the practical significance of the accuracy advantage is not yet demonstrated: the evaluation stops at relative error in linear probability space and never checks whether downstream variant calls or evolutionary parameter estimates change. The resource comparison is also partially confounded by different implementation flows. These gaps are fixable within the manuscript's scope, but they are load-bearing for the broad claim that posit is a 'better strategy' for statistical computations.","major_comments":[{"comment":"The accuracy evaluation is entirely in terms of relative error of final likelihoods/p-values against 256-bit MPFR. LoFreq's output is a binary decision (variant if p < 2^-200), and VICAR's output is evolutionary parameter estimates from variational inference; neither downstream output is examined. Relative error in linear probability is approximately absolute error in log-likelihood, so the metric is not unreasonable, but it does not establish that the reported two-orders-of-magnitude accuracy advantage changes any call or parameter estimate. Please add a call-level comparison for LoFreq (e.g., true/false positives/negatives relative to MPFR) and a comparison of estimated evolutionary parameters for VICAR, for both log-space and posit accelerators. Without this, the conclusion in Section VIII that posit 'leads to improvements in all metrics' overstates what is actually measured.","section":"VI-A and VI-D"},{"comment":"The text discloses that posit(64,12) underflows on 2 of 222,131 p-values and has relative errors up to 10^2129 on 2 others, and posit(64,9) underflows on 132 p-values. Since LoFreq's decision rule is a threshold, these outlier cases could change variant calls. The manuscript does not report whether these p-values lie in the critical set (p < 2^-200) or whether the resulting calls agree with the MPFR baseline. For example, if underflow forces p = 0, the call is always 'variant'; if the true p-value is also below the threshold this is harmless, but if not it is a false positive. A call-level analysis of these extreme cases is necessary to bound the practical impact of the reported accuracy advantage.","section":"VI-D, para. 'However, posits do not always...'"},{"comment":"The resource comparison between log-space and posit arithmetic units is confounded by implementation style: the log-space LSE unit uses Xilinx LogiCORE IP (optimized RTL), while the posit units use the MArTo HLS library. The paper acknowledges this difference, but the application-level resource claims in Tables III and IV inherit the same confound, since the log-based accelerators use the Xilinx IP and the posit-based accelerators use MArTo. Because lower resource use is a central part of the claimed advantage, please provide at least one point of comparison with a common design flow (e.g., both in HLS, or a hand-optimized RTL posit implementation), or a sensitivity analysis showing the resource conclusions persist.","section":"IV-B, Table II"}],"minor_comments":[{"comment":"The section heading contains a typo: 'Numercial Accuracy' should be 'Numerical Accuracy'.","section":"IV-A"},{"comment":"The y-axis starts at 10^8, so relative errors below 10^-8 are not visible in the box plots. Consider indicating the plot range or adding a zoomed panel, since many application-level errors are in this range.","section":"Figure 3"},{"comment":"The label 'less important' for p-values >= 2^-200 is vague. Since these are non-critical columns, the relevant question is whether any are incorrectly called as variants; please define the label in the caption or text.","section":"Figure 11(b)"},{"comment":"The definition of l (the number of repeated regime bits) is given verbally but not formally. A compact definition, e.g., in terms of the run-length of the leading regime bit, would improve precision.","section":"Equation (4)"},{"comment":"The authors state that 40% and 5% of critical columns have p-value < 2^-1074 and 2^-10000, respectively, but no distribution is given for p-values close to the decision threshold 2^-200. Such information would help interpret the outlier analysis requested in the major comments.","section":"V-A"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope for a numerical analysis or FPGA systems venue, and the core empirical comparison is potentially valuable. The main obstacle is the missing downstream statistical validation: the accuracy claim is measured only as linear-relative error of final probabilities, not as effect on variant calls or parameter estimates. This is fixable with additional experiments, so I do not recommend rejection. The resource comparison confound is also fixable, though it may require additional implementation work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a serious, well-executed empirical study of posit arithmetic for underflow-prone statistical workloads, and the novel angle is comparing posits against log-space rather than just IEEE float. The two-orders-of-magnitude accuracy claim holds on the metric they choose, but the paper never tests whether that accuracy changes any actual statistical decision. That is the one load-bearing gap.\n\nWhat it does well: it quantifies at the arithmetic level why log-space loses relative precision in linear space while binary64 underflows, and shows that certain posit configurations avoid that trade-off. The FPGA work is substantial: accelerators for the HMM forward algorithm and for LoFreq's Poisson binomial computation, with resource, latency, and accuracy data across three posit configurations and log-space baselines. The trade-offs among posit(64,9/12/18) are reported honestly, including underflow and large relative errors near representable limits. That transparency earns credit.\n\nSoft spots, in order. First, the accuracy metric. Relative error in linear probability space is the wrong measure if the goal is to claim \"better strategy for statistical computations.\" LoFreq decides based on p < 2^-200; VICAR's parameters depend on log-likelihoods. The paper shows 99% of posit(64,12) p-values have relative error < 10^-10 vs 60% for log-space, but never shows whether any of the 222,131 columns change call status or whether VICAR's estimates move. It even reports posit(64,12) underflows on 2 p-values with relative errors up to 10^2129, and log-space never underflows. If those few cases don't alter the call set, the accuracy advantage is real but practically inert. Second, the hardware comparison uses a research-grade HLS posit library (MArTo) against Xilinx's optimized LogiCORE IP. The paper acknowledges it, but it could inflate the performance and resource gaps. The performance/resource conclusions are independent of the accuracy metric and look plausible, though. Third, no code or data are released, which limits reproducibility.\n\nWho this is for: people in numerical formats, FPGA acceleration of statistical bioinformatics, and anyone assuming log-space is strictly better for small probabilities. It deserves a serious referee. The referee should request end-to-end validation: report variant-call F1 or VICAR parameter accuracy against MPFR, not just linear relative error. If the call sets are identical, the accuracy claims need rephrasing, but the hardware story survives.","headline":"Serious empirical look at posit vs log-space for statistical computation; accuracy claim is real on the paper's metric but downstream decisions are never tested.","tokens_in":21066,"tokens_out":3439,"would_cite":true,"duration_ms":37243,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["65G50","65Y04"],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper establishes that posit arithmetic dominates log-space for statistical computations on extremely small probabilities, improving accuracy, resource use, and speed on two bioinformatics accelerators.","keywords":["posit arithmetic","log-space computation","numerical underflow","statistical computing","hidden Markov model","Poisson binomial distribution","FPGA accelerator","floating-point accuracy"],"falsifier":"Re-run the two application accelerators on the same genomic data using both posit and log-space arithmetic and compare the actual variant calls or evolutionary parameter estimates produced by each; if the calls and estimates agree on essentially all inputs, then the claimed two-orders-of-magnitude accuracy improvement has no observable effect on the applications' outputs. A weaker falsifier: compute the maximum absolute error of the log-likelihood/p-value in log space; if it is comparable or better for log-space, the linear relative-error metric was the source of the apparent advantage.","tokens_in":20215,"feed_emoji":"🧮","tokens_out":6559,"duration_ms":74212,"temperature":0.7,"pith_summary":"Statistical computations often multiply probabilities until they become far smaller than ordinary double precision can represent, so software shifts to log-space, trading away arithmetic simplicity. This paper argues that posit, a number format whose exponent and fraction fields expand and contract on demand, avoids that trade-off: it represents the same tiny probabilities directly while keeping more bits for precision. The authors build FPGA accelerators for two bioinformatics workloads of this kind and report that the posit versions are up to two orders of magnitude more accurate, use up to 60% fewer hardware resources, and run up to 33% faster than log-space versions. The central claim is that future hardware for statistical computing should use posits rather than log-space.","feed_headline":"Posit numbers beat log-space 100x on tiny-probability stats","feed_subtitle":"On two bioinformatics workloads, posit hardware is up to 60% smaller, 33% faster, and doubles throughput per resource.","key_machinery":"The mechanism is the posit encoding. A posit(N,ES) number reserves one sign bit and then allocates the remaining bits among a run-length-encoded regime, an exponent of ES bits, and a fraction field, so that tiny values automatically receive more regime/exponent bits and values near one receive more fraction bits. Its value is (-1)^sign * (2^(2^ES))^k * 2^e * (1+f). This dynamic allocation is what lets a single 64-bit format cover exponents down to roughly -2,000,000 or beyond while preserving up to 52 fraction bits in the normal range. In the paper's designs, replacing log-sum-exp additions with plain posit multiply-add operations removes the expensive logarithm/exponential units and shorten","core_discovery":"Using logarithms in statistical code is so standard that its numerical cost goes unnoticed: inside the range where binary64 works, log-space is less accurate than binary64 itself, because the exponent field of a log value is mostly zeros while the fraction field has to encode the original exponent. The paper's substantive claim is that this cost is avoidable. Posit—a 64-bit format with run-length-coded scale bits—covers probabilities as small as about 2^-2,000,000 without underflow and still keeps up to 52 fraction bits for ordinary values. On FPGA accelerators for two iterative probability computations, replacing log-space with posit gives final relative errors about 100x smaller, uses roug","pith_inferences":["A testable extension the paper leaves implicit: evaluate whether the linear-space accuracy gain changes actual variant calls or parameter estimates, since those decisions depend on log-space thresholds.","The arithmetic-level analysis is application-independent, so the same design argument likely carries over to other underflow-prone domains such as financial option pricing or probabilistic machine learning; that is an extrapolation, not a claim in the paper.","The hardware comparison is on FPGAs at 64-bit width; extending to 32/16-bit formats or ASIC implementations could change the relative resource and latency numbers."],"forward_implications":["Applications that currently compute hidden Markov model likelihoods or Poisson-binomial p-values in log-space can be reimplemented directly in posit arithmetic without losing the tiny values.","A posit-based accelerator for these workloads fits roughly 2.5x more processing units on the same FPGA die, because it uses about 40% of the LUTs of a log-space unit.","At the same 300 MHz clock, posit units are 15-33% faster, so the throughput per unit of hardware resource about doubles.","Final likelihoods and p-values come out with about two orders of magnitude smaller relative error, for example nearly all VICAR-style likelihoods under 1e-8 relative error versus a few percent for log-space.","The exponent-size parameter ES can be tuned: larger ES extends range for extremely small values but reduces precision for values near one, so configuration is a real design knob."],"fun_headline_variants":["Posit vs log-space: 100x accuracy, 60% smaller, 33% faster","Tiny probabilities? Posit gets 100x more accurate than log-space","Log-space loses: posit doubles throughput per FPGA resource","Posit chips cut error 100x and shrink 60% against log-space","For rare events, posit beats log-space on accuracy and cost"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The whole comparison rests on measuring accuracy as relative error in the original probability space; if the applications' real outputs—likelihood ratios, p-value thresholds, or parameter estimates—should instead be judged in log space or by the decisions they drive, the reported posit accuracy advantage may not carry through.","fun_headline_variants_meta":{"raw":{"variants":["Posit vs log-space: 100x accuracy, 60% smaller, 33% faster","Tiny probabilities? Posit gets 100x more accurate than log-space","Log-space loses: posit doubles throughput per FPGA resource","Posit chips cut error 100x and shrink 60% against log-space","For rare events, posit beats log-space on accuracy and cost"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000327,"raw_usage":{"total_tokens":1642,"prompt_tokens":698,"completion_tokens":944,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":442,"completion_tokens_details":{"reasoning_tokens":845}},"tokens_in":442,"tokens_out":944,"duration_ms":10251,"temperature":1.0,"reasoning_tokens":845,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T17:20:38.175421+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the two application accelerators on the same genomic data using both posit and log-space arithmetic and compare the actual variant calls or evolutionary parameter estimates produced by each; if the calls and estimates agree on essentially all inputs, then the claimed two-orders-of-magnitude accuracy improvement has no observable effect on the applications' outputs. A weaker falsifier: compute the maximum absolute error of the log-likelihood/p-value in log space; if it is comparable or better for log-space, the linear relative-error metric was the source of the apparent advantage.","supporting_citations":[],"review_version":1}