{"id":"7bb690d0-de28-4809-9823-b682903310ab","arxiv_id":"1908.07153","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A Maple package computes Wythoff polytopes, tests their Zometool constructibility, and produces projections and parts lists.","lead":"This paper presents a Maple package that builds Wythoff polytopes, projects them, and checks whether they can be built with Zometool pieces. It provides a computational companion to existing visualization tools, letting users verify constructibility and generate parts lists.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The Section 3 constructibility test appears to check only edge lengths; Zometool's finite hub-direction set makes that insufficient, so positive constructibility verdicts are not established.","rationale":"The reader's weakest-assumption analysis is on target: Section 3's constructibility criterion is stated purely in terms of normalized edge lengths and strut-color counts, with no mention of angular or direction compatibility. This pass strengthens the concern by noting that Zometool is a discrete direction system, not just a discrete length system. A graph whose edge lengths match the strut set can be deformed or rotated into configurations that are physically impossible, so a length-only test can produce false positives. The paper's own positive examples are real builds or models, which give some evidence for those cases, but the advertised general 'compute whether or not' claim needs a direction-level check. The appropriate verdict remains CONDITIONAL: the package appears useful and the Wythoff construction portion is standard, but the constructibility predicate should be either corrected or explicitly scoped to a necessary-condition test before the central claim is fully trusted.","tokens_in":6285,"tokens_out":6437,"duration_ms":73324,"concrete_test":"Take a regular tetrahedron whose six edges all have a valid Zometool strut length and apply the package's constructibility predicate to 100 random rotations of it. Zometool hubs permit only finitely many edge directions, so at most a finite set of rotations is physically buildable. If the predicate returns 'constructible' for every rotation, it is testing only edge lengths and is unsound; if it returns 'constructible' only for rotations whose edge directions lie in the 31-direction Zome zone set, the angular concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the package can 'compute whether or not a given polyhedral structure is Zometool constructible.' As described in Section 3, this decision is made from normalized edge lengths: the vertex-first 120-cell projection is rejected because its 'set of (normalized) edge lengths' is incompatible, and positive examples are presented via strut-color counts. But Zometool constructibility is a rigid geometric condition: every strut must lie along one of the finitely many directions in the Zometool zone set, and the incident directions at each hub must be realizable by an actual Zometool connector. Matching the edge-length multiset is necessary but not sufficient. For example, a graph with all edge lengths in the Zome set can be continuously rotated; only finitely many rotations place its edges along Zome zones, yet a length-only checker would declare every rotation constructible. The paper gives no theorem, code-level argument, or released-code excerpt showing that edge-length compatibility implies the existence of a direction-compatible embedding. The physically built 120-cell and 600-cell examples are reassuring evidence for those specific models, but they do not validate the general decision procedure advertised in the abstract. Without an explicit check of edge directions against Zometool hub directions, a positive constructibility verdict can be wrong.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes a Maple package for working with Wythoff (reflection-generated) polytopes and Zometool models. The package has four advertised purposes: deciding Zometool constructibility, manipulating Zometool objects and planning construction, generating Wythoff polytopes from decorated Coxeter diagrams, and projecting polytopes onto Coxeter planes. The authors illustrate the package on the 120-cell, 600-cell, and omnitruncated 120-cell, including layer-by-layer visual construction plans, filtered submodels, and parts lists. The code is made available through a git repository. The central claims are that the package automates the Wythoff construction for all nonsnub Wythoffian polytopes and that it can decide whether a projected polytope is constructible in Zometool.","tokens_in":6499,"tokens_out":3201,"duration_ms":35584,"significance":"If the constructibility decision is made correct, this is a useful computational and visual tool: it extends KaleidoTile to higher dimensions, supplies a source of Wythoff polytopes, and gives concrete support for large Zometool projects such as the omnitruncated 120-cell. The paper's strengths include the direct, parameter-free computation of vertices and edges from Coxeter data, the availability of source code, and the impressive concrete examples with parts lists. The physical constructions and renderings of the 120-cell and 600-cell are convincing evidence for those specific models. However, the advertised general decision procedure for Zometool constructibility is not justified in the manuscript, and this is the main issue blocking the paper's central claim.","major_comments":[{"comment":"The constructibility test described in Section 3 appears to rely only on the multiset of normalized edge lengths. This is a necessary condition for Zometool constructibility, but not a sufficient one: in Zometool, every strut must lie along one of the finitely many directions in the Zome zone set, and the incident directions at each vertex must be compatible with an actual Zometool hub. A polyhedral graph whose edge lengths all match Zometool strut lengths can be rotated continuously, and only finitely many orientations place all edges along Zome zones; a length-only checker would declare every orientation constructible. The paper gives no theorem, code-level argument, or verification that edge-length compatibility implies the existence of a direction-compatible embedding. The negative example of the vertex-first 120-cell projection is valid as a necessary-condition certificate, and the physically built 120-cell and 600-cell are strong evidence for those particular models, but the abstract and Section 1 advertise a general decision procedure, and that claim is not established by the text.","section":"Section 3"},{"comment":"The introduction states that Maple's symbolic nature allows the program's output to be taken as a formal proof of constructibility or non-constructibility. For the non-constructible direction, a certificate based on a necessary condition (edge-length incompatibility) can indeed be formal. For the constructible direction, no formal certificate is described: showing that edge lengths belong to the Zometool set does not prove that the edges can be simultaneously routed through Zometool hubs with correct directions. The paper should either provide a precise definition of the constructibility criterion used by the code, including the finite set of allowed hub directions, or restrict the claims to a weaker 'edge-length compatible' notion.","section":"Section 1"},{"comment":"The parts-list computation for the omnitruncated 120-cell is presented as a way to 'verify entries in Richter's list,' but no comparison with a specific published list is shown. As written, this claim is not checkable from the paper. A small table comparing the package's counts with Richter's counts for the same projection would make this verification concrete.","section":"Section 3, parts lists"}],"minor_comments":[{"comment":"The text near the Coxeter diagram examples says 'This configuration is illustrated by the Coxeter diagram 5 .' The diagram itself appears to be missing in the extracted text. In the published version, please ensure the diagram is legible and that the associated notation is defined, since the whole Wythoff construction section relies on reading decorated Coxeter diagrams.","section":"Section 2"},{"comment":"The spelling of Wythoff's name is inconsistent: the title and body use 'Wythoff,' while reference [20] is listed as 'Wijthoff.' Please standardize the spelling to the historically conventional 'Wythoff' and correct the reference.","section":"Throughout"},{"comment":"The figure captions use dashed, solid, and alternating dash-dot lines to indicate blue, yellow, and red struts, but the convention is not stated in the main text near Figure 3. A sentence in Section 3 explaining the line-style-to-color mapping would improve readability.","section":"Section 3"},{"comment":"The paper states that the package can be used to 'determine how to best build a given structure,' but the notion of 'best' is not defined. If this means fewest pieces, fewest layers, or some other criterion, that should be stated explicitly.","section":"Section 3"}],"recommendation":"major_revision","confidential_remarks":"The core Wythoff-generation and visualization work appears sound and useful, but the constructibility decision procedure is the central advertised feature and is not currently justified. I would want the authors to either add a rigorous criterion that includes hub-direction compatibility, or substantially weaken the claims about deciding constructibility. The manuscript is otherwise a reasonable software-paper candidate for the venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"My take: this is a genuine software contribution, not a disguised non-result, but the headline constructibility feature is oversold. The Maple package does something new — Wythoff construction in arbitrary dimension with a Zometool-aware workflow, layer breakdown, parts lists, and projections — and the authors put the code online. That alone earns a careful look. The physically built 120-cell and 600-cell examples are credible evidence that the package produces real Zometool models for those cases.\n\nThe soft spot is exactly where the stress test lands. Section 3 describes the constructibility check as comparing normalized edge lengths against the Zometool strut set. That is a necessary condition, not a sufficient one. Zometool hubs have a finite set of allowed directions, and a graph can have all edges in the length set while its edges point along non-Zome directions; a length-only check would certify every rotation of such a graph. The paper provides no argument, code excerpt, or theorem showing the edge-length test implies a direction-compatible embedding. The authors' examples with physically built models are reassuring for those specific projections, but they don't validate the general decision procedure advertised in the abstract. This needs to be fixed — either by adding an explicit direction/hub-compatibility check or by reframing the claim from 'computes constructibility' to 'checks the necessary edge-length condition and reports Zometool models for known cases.' The phrase about Maple output serving as a formal proof is also an overstatement; symbolic computation output is not a proof certificate.\n\nMinor: the Richter list is cited as [14] in the intro and [15] in Section 3; those look like different references. The paper would also benefit from saying which version of the package the examples use and from including a short excerpt of the constructibility code so reviewers can see exactly what the test does.\n\nWho this is for: anyone working with Zometool, polytope projections, or teaching geometry with physical models. It is not a theoretical advance, but it is a functional tool with honest limitations reported in the text (the authors do note the missing snubs). I'd send this to a referee — the software is real and the flaw is fixable — but with a clear request that the constructibility claim be scoped down or the test strengthened. My vote: accept after major revision, not desk reject.","headline":"Genuine software contribution with an incomplete constructibility test: edge-length matching alone doesn't certify Zometool constructibility.","tokens_in":6994,"tokens_out":2479,"would_cite":false,"duration_ms":23800,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["52B11","20F55","51F15"],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a Maple package can generate Wythoff polytopes in any dimension and certify Zometool constructibility by comparing edge lengths to the Zometool strut set.","keywords":["Wythoff construction","Zometool","Coxeter plane","120-cell","uniform polytopes","Maple","constructibility","golden ratio"],"falsifier":"Find any polyhedron whose edge lengths all lie in the Zometool strut set but whose vertex figures require an angle that appears in no Zometool node; if the package certifies it constructible and no assembly of real Zometool pieces can realize it, then edge-length compatibility alone is not sufficient for constructibility.","tokens_in":6091,"feed_emoji":"📐","tokens_out":9913,"duration_ms":80057,"temperature":0.7,"pith_summary":"This paper claims to provide a Maple package that automatically generates the convex uniform polytopes obtainable by the Wythoff construction in any dimension, and that decides whether a given polyhedral structure can be built with Zometool pieces. The constructibility test normalizes every edge length in a projected model and checks whether all lengths belong to the Zometool strut set; if they do, the structure is declared constructible, otherwise the offending lengths serve as a certificate of non-constructibility. The package also produces layer-by-layer breakdowns of large models and computes parts lists, making it possible to plan physical builds such as the omnitruncated 120-cell, which requires 21,360 pieces. If the claims are right, the package gives mathematicians and builders a computer-checkable route from a Coxeter diagram to a buildable Zometool model or to a proof that no such model exists.","feed_headline":"Maple package generates Wythoff polytopes and tests Zometool fit","feed_subtitle":"Certifies when a projection cannot be built and plans layer-by-layer builds of 21,360-piece models.","key_machinery":"The working machinery is the Wythoff construction read off decorated Coxeter diagrams: a finite reflection group acting on $\\mathbb{R}^n$ is drawn as a graph whose nodes are mirrors, and marking which mirrors fix the seed point determines a uniform polytope as the convex hull of that point's orbit. The package recursively computes vertices, edges, and cells from the diagram data. For Zometool constructibility, the load-bearing object is the Zometool strut-length set: all strut lengths are normalized and compared to this set, and matching edge lengths are taken as proof of constructibility. Around this, Maple's computational geometry routines convert skeletons to cell lists, and projection routines (orthogonal, stereographic, Coxeter-plane) feed the constructibility test.","core_discovery":"The central discovery is that the classical Wythoff construction, encoded by decorated Coxeter diagrams, can be implemented in Maple for arbitrary dimension, and that Zometool constructibility of a projected polytope can be settled by comparing normalized edge lengths to the finite set of Zometool strut lengths. The implementation covers all Wythoffian polytopes except snubs, yielding 11 of the 13 Archimedean solids and 45 of the 47 non-prismatic convex uniform 4-polytopes. On the Zometool side, the package certifies, for instance, that cell-first projections of the 120-cell and 600-cell are constructible, while the vertex-first projection of the 120-cell is not, and it computes exact parts lists such as 7200 balls, 2880 red struts of two lengths, 3600 blue struts, and 4800 yellow struts for the omnitruncated 120-cell.","pith_inferences":["The paper's criterion checks only edge lengths; a stricter test would also verify that every angle between struts at a vertex belongs to the finite set of angles realized by Zometool nodes, which would make a constructibility certificate more convincing.","Because snub polytopes arise from omnitruncated ones by vertex alternation, the package's Wythoff machinery could likely be extended to cover the four missing cases: snub cube, snub dodecahedron, snub 24-cell, and grand antiprism.","If the non-constructibility certificate (the unmatched edge-length set) were emitted in a machine-checkable format, package verdicts could double as formal proofs, a property toward which Maple's symbolic output already gestures."],"forward_implications":["For every non-snub Wythoffian polytope in the covered Coxeter families, the package produces vertex, edge, and cell data, then tests Zometool constructibility in the same run, so the full catalog of constructible projections can be generated mechanically.","Layer-by-layer decomposition turns the 21,360-piece omnitruncated 120-cell model into a sequence of subassemblies, each small enough to be built and inspected on its own.","Exact parts lists (7200 balls and 14,160 struts in prescribed color counts) allow the package's output to be checked against published Zometool construction lists.","Coxeter-plane projections provide views of the 4-dimensional structure that are unavailable in the 3D projections used for Zometool building."],"supporting_citations":[{"why":"KaleidoTile, the 3D kaleidoscope software whose visual Wythoff construction the package extends to higher dimensions.","marker":"[19]"},{"why":"Supplies the recursive decorated-Coxeter-diagram algorithm used to compute vertices and sub-objects.","marker":"[2]"},{"why":"The original 1918 paper introducing the Wythoff construction of uniform polytopes as reflection-group orbits.","marker":"[20]"},{"why":"Coxeter's 1935 treatment of the Wythoff construction, the basis for the package's polytope generation.","marker":"[6]"},{"why":"The theorem that every finite reflection group has a Coxeter presentation, justifying the diagram encoding.","marker":"[4]"},{"why":"The enumeration of 4-dimensional Archimedean polytopes used to count the 45 of 47 covered by the package.","marker":"[8]"},{"why":"vZome, the existing Zometool modelling software that the package complements and contrasts with.","marker":"[18]"},{"why":"Published list of H4 Zome constructions against which the package's parts lists are verified.","marker":"[15]"}],"fun_headline_variants":["Maple computes Wythoff polytopes, checks Zometool builds","Wythoff construction in Maple: certify Zometool feasibility","Maple tool: Wythoff polytopes and Zometool constructibility","Certify Zometool builds with Maple Wythoff package","Maple solves Wythoff-Zometool constructibility puzzles"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The constructibility test treats a structure as Zometool constructible whenever its normalized edge lengths all belong to the Zometool strut set, without checking that the angles between struts at each vertex can be realized by an actual Zometool connector.","fun_headline_variants_meta":{"raw":{"variants":["Maple computes Wythoff polytopes, checks Zometool builds","Wythoff construction in Maple: certify Zometool feasibility","Maple tool: Wythoff polytopes and Zometool constructibility","Certify Zometool builds with Maple Wythoff package","Maple solves Wythoff-Zometool constructibility puzzles"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000552,"raw_usage":{"total_tokens":2570,"prompt_tokens":823,"completion_tokens":1747,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":439,"completion_tokens_details":{"reasoning_tokens":1654}},"tokens_in":439,"tokens_out":1747,"duration_ms":11493,"temperature":1.0,"reasoning_tokens":1654,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T12:58:56.929481+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find any polyhedron whose edge lengths all lie in the Zometool strut set but whose vertex figures require an angle that appears in no Zometool node; if the package certifies it constructible and no assembly of real Zometool pieces can realize it, then edge-length compatibility alone is not sufficient for constructibility.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"KaleidoTile, the 3D kaleidoscope software whose visual Wythoff construction the package extends to higher dimensions."},{"cited_title":"Canadian J","cited_arxiv_id":null,"evidence_quote":"Supplies the recursive decorated-Coxeter-diagram algorithm used to compute vertices and sub-objects."},{"cited_title":"Koninklijke Nederlandse Akademie van Wetenschappen Proceedings Series B Physical Sciences 20, 966–970 (1918)","cited_arxiv_id":null,"evidence_quote":"The original 1918 paper introducing the Wythoff construction of uniform polytopes as reflection-group orbits."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Coxeter's 1935 treatment of the Wythoff construction, the basis for the package's polytope generation."},{"cited_title":"Annals of Mathematics 35(3), 588–621 (1934), http://www.jstor.org/stable/1968753","cited_arxiv_id":null,"evidence_quote":"The theorem that every finite reflection group has a Coxeter presentation, justifying the diagram encoding."},{"cited_title":"In: Proceed- ings of the Colloquium on Convexity, Copenhagen, 1965","cited_arxiv_id":null,"evidence_quote":"The enumeration of 4-dimensional Archimedean polytopes used to count the 45 of 47 covered by the package."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"vZome, the existing Zometool modelling software that the package complements and contrasts with."},{"cited_title":"In: Sarhangi, R., Moody, R.V","cited_arxiv_id":null,"evidence_quote":"Published list of H4 Zome constructions against which the package's parts lists are verified."}],"review_version":1}