Skip to content

lpspec holds a queue of language questions for this repository, and they arrive in families #231

Closed

Description

@FBumann

Prompt: File exactly one math-spec issue: an index linking fluxopt/lpspec/issues?q=label:upstream:math-spec

Note

The following content was generated by AI.

lpspec has a backlog of questions that are this repository's to answer. They are held there rather than filed here, so this list stays readable. A question is filed here only as this repository next touches its area; until then this issue is the whole of them.

The queue: fluxopt/lpspec · label:upstream:math-spec — 19 issues, held by lpspec's The language questions live upstream milestone.

What arrives here is the question, a few sentences under design: open. The evidence — corpus audits, probes, counts, the PyPSA rung each was taken against — stays in the lpspec body and is linked, not copied. They come in families, as this repository next touches each area:

family lpspec issues possible home here
the where: grammar #849 (parent), #851 → #255, #982, #469, #1014, #218 #14, #15, #254, #255
regimes and case-splitting #711, #1219, #1129 #2, #16
the declaration surface #1220, #31, #383, #1113, #220, #261, #125, #1222 new
operators and analysis #384, #229 new

Closes when the label is empty.

Already resolved without filing here, for the record: nine lpspec issues closed as duplicates of #161, #73, #75, #49, #77, #82, #83, #157 and #225/#226; #1030 as a duplicate of #8; and two decided no upstream at all (a solve dimension, and highspy as a hard dependency).

Activity

  1. added
    metaAbout the project rather than the language — trackers, naming, process
    on Aug 31, 2026
  2. FBumann commented on Aug 31, 2026

    @FBumann
    ContributorAuthor

    Prompt: Maybe we should transfer all of them from lpspec to mathspec and close them in lpspec? Lets go through one by one.

    Note

    The following content was generated by AI.

    The label is empty, so this closes. Triaged one by one; twelve language questions now live here, seven were answered or declined without one, and two stayed upstream as lpspec work.

    Moved here — each closed upstream, its body left readable as the evidence these link to rather than copy:

    lpspec here
    #851 #255 a where-comparison may name a co-located column — decided yes upstream
    #982 #258 may a where: carry operators — relocation, reduction
    #218 #259 a reduction cannot filter the terms it sums
    #1219 #260 N declarations that are one requirement — the residue #168 does not reach
    #31 #261 a bound cannot be an expression
    #1220 #262 bounds: has no where: (language half only)
    #383 #263 domain: semi_continuous (language half only)
    #384 #264 cumsum over a variable-free expression (language half only)
    #220 #265 an indicator constraint has no spelling
    #1113 #266 a binary times a bounded variable
    #261 #267 a declared McCormick relaxation (language half only)
    #1222 #268 a data combination that cannot be built has no load-time refusal

    Answered or declined, with no issue here:

    Stayed upstream, delabelled: #1220 rescoped to the port that decides whether its language half is worth anything, and #229, whose remaining variant is a post-bind check in lpspec's build path.

    The policy the sweep settled, for the constructs with a two-sided implementation: the language question is filed here and the lpspec issue closes now, with an adoption issue refiled there when the construct ships. One issue, one PR, on both sides — a combined adoption tracker was rejected for bundling separable work behind one number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    metaAbout the project rather than the language — trackers, naming, process

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions