{"id":"7ec4633b-3b5e-454d-9a4b-4d4471305d84","arxiv_id":"2411.13259","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A multi-institution group proposes a hardware-portable C++ API standard for basic sparse linear algebra operations, with single-stage and multi-stage interfaces.","lead":"The paper proposes a community-driven C++ interface standard for sparse linear algebra operations, covering matrix-vector multiply, sparse matrix-matrix multiply, triangular solve, and format conversion. If widely adopted, it could make sparse linear algebra libraries interoperable across CPUs and accelerators, much as the dense BLAS standard did.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The multi-stage API examples require allocating output arrays after compute, but the non-owning csr_view has no specified way to install those arrays before fill, so the documented workflow is unimplementable as written.","rationale":"The reader identifies the user-driven allocation model as potentially burdensome and therefore an adoption risk. I agree that the allocation model is a weak point, but the more immediate problem is under-specification rather than burden: the examples in Section 5.6 show an empty non-owning view being created before allocation and then passed to fill after \"putting\" allocated arrays into it, without any documented operation to do so. This is an internal consistency gap in the central design, not merely a question of user preference. It directly affects the paper's claim to provide flexible and extensible interfaces, because a user cannot follow the documented workflow as written. The concern is concrete and testable by attempting to compile a minimal reference implementation. I do not think this changes the overall verdict: CONDITIONAL remains appropriate because the gap is fixable with a specification revision and a reference implementation, but it strengthens the case that the current draft has not yet demonstrated that the API is usable as described.","tokens_in":25646,"tokens_out":11148,"duration_ms":124099,"concrete_test":"Write a minimal C++ implementation of csr_view exactly as described in Sections 4 and 5.1: a constructor from pointers and no setters, mirroring std::mdspan. Then implement Listing 11 (add_compute and add_fill) with the published signatures. If the example cannot be compiled unless the user replaces C with a newly constructed view or the view is given an undocumented mutator, the published API is incomplete. The check is whether the paper, by itself, contains enough information to write a conforming multi-stage workflow.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the API is high-performance, flexible, extensible, and portable across vendors. The most load-bearing technical gap is in the multi-stage API of Section 5.6. For operations with unknown output sparsity, the user is told to call compute, read state.get_result_nnz(), \"allocate the C arrays and put in C\", and then call fill (Listings 9, 10, 11, 12). But C is declared as a non-owning csr_view before allocation, e.g. `csr_view<float> C(m, n);` in Listing 11. Section 5.1 defines views as lightweight wrappers over user-owned pointer arrays, analogous to std::mdspan, which is immutable after construction. The paper nowhere specifies a mechanism (setter, rebind, or assignment) by which the user attaches newly allocated arrays to the existing C object. If views are immutable, the fill(policy, state, A, B, C) call cannot see the allocated buffers, and the example is uncompilable as written. If views are intended to be mutable, the API must define mutators and their aliasing and ownership semantics, which is absent. Thus the multi-stage workflow, the core mechanism for SpGEMM, addition, conversion, and filtering, is incompletely specified, undermining both \"flexible and extensible interfaces\" and \"serves the user needs\" before broader adoption or performance questions are reached.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a C++ interface for sparse linear algebra operations, presented as a candidate standard in the spirit of the dense BLAS and std::linalg. The design centers on non-owning view types (csr_view, csc_view, coo_view) over user-owned arrays, an optional inspect phase for optimization, single-stage APIs for operations whose output sparsity is known a priori, and multi-stage compute/allocate/fill APIs for operations whose output sparsity is unknown. The manuscript also discusses execution policies, numerical exception handling, error bounds, reproducibility, and test-suite plans. The central claim is that this design enables portability across vendors while providing high-performance, flexible, and extensible interfaces for sparse linear algebra.","tokens_in":25904,"tokens_out":6395,"duration_ms":64166,"significance":"If completed and validated, this proposal addresses a genuine community need for a vendor-neutral sparse BLAS interface that works on CPUs and accelerators. The paper's strengths include a thorough review of prior and concurrent efforts (dense BLAS, GraphBLAS, and vendor APIs), a coherent separation of single- and multi-stage workflows, and a useful discussion of numerical considerations such as error bounds, exception handling, and conditional numerical reproducibility. The multi-institutional author list gives the proposal practical weight. However, the manuscript currently lacks a reference implementation and conformance tests, and the multi-stage workflow has an underspecified step that is central to the API's usability. These gaps prevent the paper, in its current form, from substantiating the full central claim.","major_comments":[{"comment":"The multi-stage workflow instructs the user to read state.get_result_nnz(), then 'allocate C arrays and put in C' before calling the fill routine. However, the paper never specifies how a preexisting csr_view object, such as `csr_view<float> C(m, n);` in Listing 11, is rebound to newly allocated arrays. Section 5.1 describes views as lightweight wrappers over user-owned pointer arrays analogous to std::mdspan, and no setter, assignment operator, or rebind operation is defined anywhere in the paper. As written, the examples are not expressible in the API, because the fill routine cannot see buffers that were never attached to C. Please specify the mutability and rebinding semantics of the view classes (including ownership and aliasing rules), or restructure the workflow so that the user constructs a fresh view after allocation.","section":"Section 5.6, Listings 9-12"},{"comment":"The paper claims that the API 'enable[s] portability across vendors, and provide[s] high-performance, flexible and extensible interfaces' and that the design 'serves the user needs'. These claims are not backed by an implementation, conformance tests, benchmarks, or user studies. The test suite described in Section 7.5 is presented as a plan ('we will deploy a unit test framework'), not as delivered evidence. For a design proposal, such statements should be framed as goals or evaluation criteria rather than demonstrated properties; otherwise the central claims are unverifiable from the manuscript.","section":"Section 1 and Section 7.5"},{"comment":"The API is presented only through usage examples, with no complete set of function signatures, constraints, or semantics for the state, policy, and scaled/view wrapper objects. This makes the proposal difficult to implement or evaluate. For example, the symbolic/numeric split uses multiply_inspect, multiply_symbolic_compute, multiply_symbolic_fill, multiply_numeric_compute, and multiply_numeric_fill, whereas the preceding single-stage variant uses sparse_multiply_inspect/sparse_multiply_compute/sparse_multiply_fill; the paper does not state which names are canonical or how overloads are disambiguated. The authors should provide at least a compact formal specification of the core functions and types, or explicitly reframe the paper as a design rationale for a future specification.","section":"Section 5.6 and overall API presentation"}],"minor_comments":[{"comment":"Listing 12 declares `auto pred` twice with two different predicates, so the listing does not compile and it is unclear which predicate is intended for the filter operation.","section":"Listing 12"},{"comment":"In Listing 12, the output view `B` is constructed with the same values, rowptr, colind, shape, and nnz arguments as the input view `A_view`; this would make the output share the input's storage, which contradicts the multi-stage output pattern shown in Listings 10 and 11.","section":"Listing 12"},{"comment":"The sentence 'In Section 5.1 we give an example how a CSR matrix structure is passed as a light-weight view' should refer to Listing 1, not Section 5.1.","section":"Section 5.1"},{"comment":"The phrase 'when integrating the functionality into the C++-26 standard library' appears twice in the first paragraph; one occurrence should be removed.","section":"Section 2.1"},{"comment":"The notation in the error-bound derivation is confusing: `z`, `\\hat{z}`, and `\\hat{\\hat{z}}` are not defined consistently, and the inequality chains mix three and four terms without clear labels for the conversion, dot-product, and output-conversion errors.","section":"Section 7.2"},{"comment":"The `cnrProperty` enum gives the same value 0 to both `default` and `none`; if this is intentional, state so explicitly, otherwise remove one of the aliases.","section":"Listing 13"},{"comment":"The `scaled` wrapper used in Listing 6 is never defined or referenced to an external specification; please clarify whether it is part of this proposal or adopted from std::linalg.","section":"Listings 5-6"}],"recommendation":"major_revision","confidential_remarks":"The paper is best read as a design proposal rather than a finalized standard. If the journal is willing to accept such papers, the missing rebinding semantics and the unsupported performance claims can be addressed in a revision. If the journal expects validated software contributions, the absence of any implementation or conformance test is a more fundamental concern; I leave that editorial judgment to you."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a serious standards proposal, not a research paper. If you work on HPC numerical software or library interfaces, read it; if you are looking for empirical validation, there is none yet. The genuinely new piece is the multi-stage API—inspect, compute, allocate, fill—plus user-provided allocators and optional symbolic/numeric splitting, which directly addresses the output-sparsity problem that stalled earlier sparse BLAS efforts. The survey of vendor SpMV interfaces in Section 5.3 is useful, and the design choices are justified from it. The numerical chapter is thoughtful, especially the treatment of implicit zeros, explicit masked zeros, and NaN/Inf propagation.\n\nThe soft spots are real but proportionate. The stress test is on target: Section 5.6 tells the user to allocate the C arrays and put them in C, but never specifies how a non-owning csr_view acquires those arrays. If csr_view is meant to be rebindable via assignment (like std::mdspan), one sentence would fix it; as written, the examples are not implementable. This is a genuine gap in the core workflow. Second, the abstract claims the API serves user needs and is hardware-portable, but there is no implementation, no conformance suite, and no benchmark. For a proposal that may be acceptable, but read the claims as design goals, not results. Minor issues: Listing 12 declares the predicate twice, and there are a few typos.\n\nThe citation pattern is fine. The authors build on Duff et al., GraphBLAS, and std::linalg, and several are contributors to those efforts, but that is expected and properly acknowledged. The design is internally coherent, and the deliberate scoping to CSR/CSC/COO plus a basic operation set is the right way to start a standard.\n\nWho it is for: library developers, standards people, anyone designing sparse linear algebra interfaces. It deserves a serious referee; desk rejection would be wrong. My recommendation is conditional acceptance: require the authors to specify view rebinding semantics and, ideally, point to a reference implementation.","headline":"A serious standards proposal with a genuinely useful multi-stage API design, but the output-allocation workflow is underspecified and the portability claims are unvalidated.","tokens_in":26573,"tokens_out":5296,"would_cite":true,"duration_ms":52249,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["65F50"],"pacs":[],"model":"deepseek-v4-flash","headline":"Proposed C++ Sparse BLAS interface targets portability across vendors and accelerators.","keywords":["sparse linear algebra","Sparse BLAS","C++ API","hardware portability","CSR/CSC/COO storage","SpGEMM","multi-stage execution","numerical reproducibility"],"falsifier":"Run the proposed API against a corpus of large sparse matrices from real applications on a GPU, comparing default calls without the inspect phase, inspect-then-call sequences, and each vendor's native sparse kernels; if the API's default path falls far behind native performance, or if the inspect phase rarely recovers its cost, the high-performance portability claim fails.","tokens_in":25435,"feed_emoji":"🧮","tokens_out":6488,"duration_ms":62955,"temperature":0.7,"pith_summary":"The paper argues that the lack of an agreed interface for sparse linear algebra is fixable: it presents a C++ API, designed over two years by a cross-institutional group, that standardizes access to sparse matrix operations the way the dense BLAS standard did for dense linear algebra. The proposal's central idea is to separate operations whose output sparsity is known in advance (single-stage calls such as sparse matrix-vector multiplication, triangular solve, and sampled dense-dense multiplication) from operations whose output sparsity is unknown (multi-stage calls such as sparse-sparse multiplication, addition, conversion, and filtering). Around that split it builds non-owning view objects over CSR, CSC, and COO data, an opaque matrix handle that can hold vendor optimization data, an optional inspect phase, and a state object that reports the result size so the user can allocate the output. If the proposal is adopted, applications could become portable across vendor libraries and accelerator architectures, lowering integration and maintenance costs for scientific computing and AI frameworks.","feed_headline":"New C++ Sparse BLAS API targets portability across vendors","feed_subtitle":"If adopted, applications could swap vendor math libraries without rewriting kernels, as dense BLAS did decades ago.","key_machinery":"The load-bearing mechanism is the distinction between single-stage and multi-stage APIs, implemented through a small set of C++ objects: csr_view (and CSC and COO views) plus mdspan for dense operands; matrix_handle, an opaque wrapper holding the view plus library-owned optimization data; policy and state objects that carry execution and per-operation information; and the multi-stage sequence compute, state.get_result_nnz(), user allocation, and fill. The state object is the piece that makes the unknown-output problem tractable: it carries the computed result size and any reusable internal buffers, so a developer can repack work between stages without breaking the interface.","core_discovery":"On the paper's own terms, the central claim is that a hardware-portable, high-performance, flexible, and extensible Sparse BLAS interface is achievable in C++ by combining four design commitments: non-owning views for transparency and zero-copy access; optional opaque matrix handles for vendor-specific optimization; a single-stage API for operations with known output sparsity and a multi-stage API for operations with unknown output sparsity; and user-side allocation of sparse outputs after a stage that reports the required size. The multi-stage API follows the classic inspect-compute-allocate-fill pattern, with the paper deliberately leaving implementers free to decide how much work happens in each stage. This is an extension of earlier sparse BLAS proposals rather than a new mathematical discovery, and its success is measured by adoption, not by a theorem.","pith_inferences":["I infer the multi-stage compute-allocate-fill structure could generalize naturally to sparse tensor contractions such as MTTKRP, whose output sparsity is also unknown; the paper lists sparse tensors as future work but does not draw this connection.","I infer that the proposal's success hinges on whether the user-driven allocation model survives contact with real applications; a testable alternative would be an optional library-managed allocation mode that keeps the same compute-fill split.","I infer that the inspect phase creates a measurable trade-off: benchmark users could quantify, per kernel and matrix, how many repeated calls are needed before the inspect cost is recovered, and such numbers would guide default-policy decisions.","I infer that the acceptance of both plain views and handles means semantic differences in exception handling (implicit versus explicit zeros) must be pinned down per operation; the paper allows implementations freedom here, so two conforming libraries could produce different NaN and Inf behavior."],"forward_implications":["If adopted as a standard, a single application code using the API could run on CPU, GPU, and accelerator libraries from different vendors without source-level rewrites.","Vendor libraries could continue to choose their best internal matrix formats and algorithms behind the handle, with the optional inspect phase amortizing setup cost in repeated iterative-solver loops.","Sparse-sparse matrix multiplication, addition, format conversion, and predicate filtering would get a common multi-stage interface, replacing today's divergent vendor-specific SpGEMM workflows.","The numerical section's framework for error bounds and consistent exception handling gives implementers a shared target for mixed- and low-precision formats, which matters for AI workloads.","C and Fortran bindings to a subset of the functionality would let legacy scientific codes interoperate without a full rewrite."],"supporting_citations":[{"why":"The 2002 Sparse BLAS standard proposal this work extends; it supplies the handle-based abstraction and the motivation for a sparse standard.","marker":"[25]"},{"why":"The level-3 sparse interface that introduced the compute-allocate-fill execution pattern reused by the multi-stage API.","marker":"[26]"},{"why":"The std::linalg C++26 interface whose free-function style, view-based operands, and execution policies shape this API.","marker":"[34]"},{"why":"The original dense BLAS, whose adoption success is the portability outcome this proposal aims to reproduce.","marker":"[41]"},{"why":"The GraphBLAS C API; its opaque-object copy overhead motivates the non-owning view choice, and its semiring and mask features set the extension context.","marker":"[6]"},{"why":"The GraphBLAS C++ specification, which shows how concepts and views simplify a native C++ linear-algebra interface and leaves accelerator execution as a gap.","marker":"[7]"},{"why":"The consistent-exception-handling proposal the numerical section builds on for Inf and NaN propagation across sparse zero classes.","marker":"[15]"}],"fun_headline_variants":["Sparse BLAS C++ API targets vendor portability","Hardware-portable sparse BLAS interface in C++","New sparse BLAS API aims for cross-vendor swap","C++ sparse BLAS: Multi-stage API for unknown sparsity","Portable sparse BLAS design: Views, handles, stages"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The proposal requires the library user to allocate the output sparse structure after querying its size from the state object; if application developers reject this user-driven allocation as too burdensome, the API is unlikely to be adopted even though the technical design is coherent.","fun_headline_variants_meta":{"raw":{"variants":["Sparse BLAS C++ API targets vendor portability","Hardware-portable sparse BLAS interface in C++","New sparse BLAS API aims for cross-vendor swap","C++ sparse BLAS: Multi-stage API for unknown sparsity","Portable sparse BLAS design: Views, handles, stages"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000173,"raw_usage":{"total_tokens":1297,"prompt_tokens":984,"completion_tokens":313,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":600,"completion_tokens_details":{"reasoning_tokens":229}},"tokens_in":600,"tokens_out":313,"duration_ms":3763,"temperature":1.0,"reasoning_tokens":229,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T16:38:02.720531+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the proposed API against a corpus of large sparse matrices from real applications on a GPU, comparing default calls without the inspect phase, inspect-then-call sequences, and each vendor's native sparse kernels; if the API's default path falls far behind native performance, or if the inspect phase rarely recovers its cost, the high-performance portability claim fails.","supporting_citations":[{"cited_title":"Duff, Michael A","cited_arxiv_id":null,"evidence_quote":"The 2002 Sparse BLAS standard proposal this work extends; it supplies the handle-based abstraction and the motivation for a sparse standard."},{"cited_title":"Duff, Michele Marrone, Giuseppe Radicati, and Carlo Vittoli","cited_arxiv_id":null,"evidence_quote":"The level-3 sparse interface that introduced the compute-allocate-fill execution pattern reused by the multi-stage API."},{"cited_title":"P1673R13: A free function linear algebra interface based on the BL AS","cited_arxiv_id":null,"evidence_quote":"The std::linalg C++26 interface whose free-function style, view-based operands, and execution policies shape this API."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The original dense BLAS, whose adoption success is the portability outcome this proposal aims to reproduce."},{"cited_title":"The GraphBLAS C API specification, version 2.0.0","cited_arxiv_id":null,"evidence_quote":"The GraphBLAS C API; its opaque-object copy overhead motivates the non-owning view choice, and its semiring and mask features set the extension context."},{"cited_title":"Mattson, Scott McMillan , and Jos´ e E","cited_arxiv_id":null,"evidence_quote":"The GraphBLAS C++ specification, which shows how concepts and views simplify a native C++ linear-algebra interface and leaves accelerator execution as a gap."},{"cited_title":"Proposed consistent exception handling for the blas an d lapack, 2022","cited_arxiv_id":null,"evidence_quote":"The consistent-exception-handling proposal the numerical section builds on for Inf and NaN propagation across sparse zero classes."}],"review_version":1}