modeling: `floor` and `ceil` have no symbolic node, so a GAMS model that uses them cannot be imported

[jkitchin]

Summary

floor and ceil are absent from the expression IR entirely. They are not in
the Rust MathFunc enum (crates/discopt-core/src/expr.rs:50), not in
modeling/core.py, and not exported anywhere:

discopt.floor -> AttributeError: module 'discopt' has no attribute 'floor'
dm.floor      -> AttributeError: module 'discopt.modeling' has no attribute 'floor'
dm.ceil       -> AttributeError

The only occurrences in the tree are constant folding in the GAMS parser
(python/discopt/modeling/gams_parser.py:1527-1530), which evaluates
ceil(2.3) when the argument is already a literal. There is no path that
produces a symbolic node over a variable.

Spun out of #1233 (CHECKS_EXECUTED 10; the three probes above plus the
min/max set that became the sibling issue).

Why this is worth its own issue

#1233's comparison paragraph names them:

For comparison, Pyomo exports its full intrinsic set (sqrt, log, log10,
exp, the trig and hyperbolic families, ceil, floor) from
pyomo.environ.

but its Suggested fix listed only the 13 names that already existed in
core.py, so the PR closing it (branch claude/awesome-goodall-kjoq0d) did not
add these — every other name in that comparison is now exported, these two are
not, because there is nothing to export.

The concrete consequence is an import gap, not just an ergonomics gap. GAMS
is the only route to a full-license BARON (the bundled /Applications/AMPL/baron
is demo-limited to 10 variables — see CLAUDE.md's three-way head-to-head
section), and minlplib.org/gms/ instances that use floor/ceil over a
variable have no import path today. Worth measuring how many corpus instances
that is before deciding priority — that is the entry experiment below.

Why it is not a small change

floor/ceil are discontinuous, which puts them in a different class from
every intrinsic currently in the IR. Each of these needs a decision, and getting
any of them wrong is a false-certificate risk rather than a slowdown
(CLAUDE.md §1):

1. Relaxation. floor(x) over a box [l, u] has a valid convex
   envelope, but it is not the interval-arithmetic result the existing
   elementwise machinery would produce. The standard treatment is a MILP
   reformulation (floor(x) = z, z integer, z <= x <= z + 1 - eps), which
   changes the variable set, not just the DAG.
2. Derivatives. The AD tape has no meaningful gradient here. The NLP
   relaxation would need the reformulated integer variable rather than the
   function node.
3. FBBT. crates/discopt-core/src/presolve/fbbt.rs would need forward and
   backward propagation rules for a step function.
4. .nl / GAMS / LP writers. .nl has opcodes for both; the writers would
   need to emit them, and the round-trip test corpus would need instances that
   exercise them.

Entry experiment (run before implementing, per CLAUDE.md §4)

Hypothesis: floor/ceil over a variable appear in enough of the MINLPLib
corpus to justify the reformulation work.

Measurement: grep ~/Dropbox/projects/discopt-minlp-benchmark/minlplib/ for
.gms instances containing floor(/ceil( with a non-literal argument, and
count how many currently fail to import. Report the count and the instance names.

Kill criterion: if the count is ~0, close this as "not reachable from the
corpus" and instead make the refusal explicit — today dm.floor is an
AttributeError from a missing name, which reads as an oversight rather than a
deliberate exclusion. A named NotImplementedError explaining that
discontinuous intrinsics need a MILP reformulation would be the whole fix, and
is worth doing either way.

Scope note

If implemented, sign is worth reviewing at the same time: it is in the IR
(MathFunc::Sign) and is equally discontinuous, so whatever treatment
floor/ceil get should either match it or explain why it differs.

[jkitchin]

Entry experiment result, and one correction to the framing

Measurement (scripts/i1237_floor_ceil_corpus_probe.py, added in #1252):
0 endogenous floor/ceil, over 105,680 comparisons — 153 .nl files scanned for opcodes o13/o14 (AMPL/GAMS emit those only for a non-literal argument) and 6 .gms files for floor(/ceil( with a non-literal argument. No instance names to report: the list is empty.

Caveat, stated plainly: that is the in-repo corpora only. The full ~4,800-instance MINLPLib snapshot at ~/Dropbox/projects/discopt-minlp-benchmark/ was not reachable from the environment this ran in — the directory is not mounted, and www.minlplib.org is denied by the network policy (proxy returned 403 to CONNECT). So the corpus count the issue actually asks for is unmeasured, not zero. The probe reports each absent root rather than skipping it silently, so re-running it on a machine with the snapshot needs no changes and will report the real number.

The kill criterion fired on every corpus that could be measured, so #1252 ships what the issue says is worth doing either way: the explicit refusal. It does not ship a relaxation, and the tests are written so they pin "this is refused and explains itself", not "floor is unimplementable" — if the full-corpus count comes back non-zero, the implementation replaces the refusals and those tests change with it.

One correction to the issue's framing

The concrete consequence is an import gap, not just an ergonomics gap.

It is worse than a gap. gams_parser._map_func fell through to FunctionCall(fn, *args) for every _GAMS_FUNCS name it had no mapping for — ceil, floor, round, mod, uniform, normal. Measured before the change:

from_gams("c1.. ceil(x) =L= 2;")   -> IMPORTED SUCCESSFULLY
  .solve()                         -> INCUMBENT-VERIFICATION SNAPSHOT FAILED:
                                      ValueError: Unknown function: 'ceil'.
                                      The false-primal guard cannot run on this solve.
                                   -> ValueError: Unknown function: 'ceil'

So the import succeeded, and the first symptom was the incumbent-verification snapshot failing and disabling the false-primal guard for that solve. serialize._known_funcs documents exactly that failure mode — it was already fixed at the deserialization doorway; the GAMS doorway was still open.

That made the generalisation clear (§2: fix the class, not the instance): rather than a shim per name, core._UNREPRESENTABLE_INTRINSICS is now the single registry (floor/ceil/round/trunc/intdiv), enforced in FunctionCall.__init__ — the one choke point the GAMS parser, serialize.loads and user code all funnel through — so these names cannot enter the IR by any route. A test keeps the registry a subset of nl_parser.rs's UnsupportedOpcode names so the two refusal lists can't drift.

dm.floor / dm.ceil / dm.round_ / dm.trunc are exported and raise DiscontinuousIntrinsicError(NotImplementedError) with the reformulation recipe, as the kill criterion asked.

Scope note on sign

Answered rather than deferred, in DiscontinuousIntrinsicError's docstring. sign stays supported because it already has every piece floor/ceil lack — MathFunc::Sign, the [-1, 1] FBBT interval rule, and relax_sign — its range being a bounded three-point set that needs no auxiliary variable. The honest statement is "sign was implemented and these were not", not "sign is smoother": floor over a bounded box is relaxable in principle, which is why the error says not implemented rather than impossible.

Can this be closed?

Your call, and it turns on one thing: whether the in-repo measurement is enough. The work the kill criterion prescribes is complete. What remains is re-running the probe against the full MINLPLib snapshot on a machine that has it — if that also returns ~0, close as "not reachable from the corpus"; if it returns a non-trivial count, the issue stays open for the real IR + FBBT + relaxation + reformulation work and #1252 is the interim loud refusal. I used Contributes to #1237 rather than Closes for that reason.

---

Generated by Claude Code

[jkitchin]

Correction to my previous comment: the corpus measurement is no longer blocked

I said the full-corpus count was unmeasurable here and left the issue conditional. That was giving up too early — retracting it.

www.minlplib.org is denied by the network policy, but raw.githubusercontent.com is not, and lanl-ansi/MINLPLib.jl is a JuMP translation of the library carrying the 1,513 MINLPLib2 instances among 6,221 models. Cloned it and re-ran the probe across all three formats:

scanned .gms / .nl / .jl files : 6 / 153 / 6,221   (6,380 total)
instances with ENDOGENOUS floor/ceil : 0
positive-control hits          : 779,084  (exp/log/sqrt)
CHECKS_EXECUTED                : 884,764

Instance names to report: none. The list is empty.

One thing worth flagging, because it nearly produced a fake result. The first .jl run added zero comparisons — which is indistinguishable from a regex that never fires, the §6 failure mode ("a probe that silently measured nothing and was believed"). So the probe now carries a positive control: it counts exp/log/sqrt over the same files and exits non-zero if that count is zero. Cross-checked independently with raw grep — 0 of 6,221 .jl files contain floor(/ceil( at all, while 796 contain exp(/log(. The zero is a measurement, not an empty scan.

Both formats can represent an endogenous use — .nl emits o13/o14 only for a non-literal argument, and JuMP's nonlinear macros accept floor/ceil over a variable — so an instance using one would have appeared rather than been dropped in translation. The kill criterion is met.

Two more doorways, found and closed

My first pass unified three. Sweeping for the rest turned up two more — and the first of them explains how the GAMS parser drifted in the first place:

• gams/instructions.py (the GAMS link / GMO instruction stream) already refused these — out of its own hand-maintained _DISCONTINUOUS set, with its own wording. That was a fourth copy of the list. It now derives from the core registry and reuses the shared message.
• export/gams.py (the writer) passed any unmapped function name straight through into the .gms file. Measured: a one-argument node named mod was written as mod(y) — GAMS's mod takes two — and the writer reported success. That is the parser's silent-acceptance bug pointing the other way, so it gets the same treatment.

Four hand-maintained copies existed; there is now one, and a test keeps it a subset of nl_parser.rs's UnsupportedOpcode names.

test_every_doorway_into_the_ir_refuses_floor is the closing argument — it walks all six entry routes a floor node could take (public API, FunctionCall, .gms parser, GMO link, serialize.loads, .nl parser) plus the writer on the way out, and asserts all seven refuse:

doorway 1  public modeling API      -> DiscontinuousIntrinsicError
doorway 2  FunctionCall constructor -> DiscontinuousIntrinsicError
doorway 3  GAMS .gms parser         -> GamsParseError
doorway 4  GAMS link (GMO)          -> GamsTranslationError
doorway 5  serialize.loads          -> SerializationError
doorway 6  .nl parser (Rust, C-5)   -> ValueError
exit       GAMS writer              -> ValueError

Can this be closed? Yes.

Unconditionally, and #1252 now says Closes #1237. Every question the issue asks is answered: the entry experiment ran on a real corpus and returned 0, the kill criterion's prescribed fix shipped uniformly, and the sign scope note is answered in DiscontinuousIntrinsicError's docstring.

To be precise about what is not claimed: floor is not implemented, not impossible — over a bounded box it is relaxable in principle, and the error says so. If demand ever appears, native support is a new feature request with a clear spec, not a reopening of "these have no node and are silently accepted." That defect is fixed.

---

Generated by Claude Code