AngouriMath has no rounding functions (floor, ceil, round), nor min, max or gcd

[Rafael-SOWNet]

Split out of #733 at @Happypig375's request — "the inclusion of those functions belong to their own issue".

#733 was about these names being silently read as products (floor(x) → floor * x). That is fixed: every one of them is now refused by name, with a message saying what is missing. What is left is the functions themselves, which is a feature rather than a defect.

Measured on master (21f0d16)

floor(x)	UnrecognizedFunctionParseException
ceil(x)	UnrecognizedFunctionParseException
round(x)	UnrecognizedFunctionParseException
min(3, 5)	UnrecognizedFunctionParseException
max(3, 5)	UnrecognizedFunctionParseException
gcd(12, 18)	UnrecognizedFunctionParseException

For contrast, the neighbours that do exist:

sign(x)	sgn(x)
abs(x)	abs(x)

Why they are not just three more grammar lines

log10 and factorial were added to the grammar because a node already existed behind them. These have no node, so each needs a decision before a rule:

• floor / ceil / round — need a node, a derivative (zero almost everywhere, undefined on the integers), a Latexise form, and a rule for what they mean on a complex argument. round additionally needs a tie-breaking convention (half away from zero, or half to even).
• min / max — expressible as (a + b - abs(a - b))/2 and (a + b + abs(a - b))/2, so they could be sugar over abs rather than nodes. That is a design choice: sugar simplifies well and prints badly, a node prints well and needs its own rules everywhere.
• gcd — only defined on integers, so it needs a decision about what it does with a symbolic or non-integer argument. Providedf is the obvious answer but is worth agreeing before implementing.

Adding any of these introduces a new Entity subtype, which is a breaking change for consumers that switch exhaustively over the node hierarchy — see #248 for that discussion.

Sensible to take them separately rather than as one change; min/max are the cheapest and round the most opinionated.

[Rafael-SOWNet]

Every decision this issue flags has a checkable answer, so here they are measured against SymPy 1.14 rather than argued. AGENTS.md asks for exactly this — "check what the other systems answer … check it, do not reason about it from memory".

floor / ceil

floor(3/2)   1        ceiling(3/2)   2
floor(-3/2)  -2       ceiling(-3/2)  -1        toward -inf and +inf, not toward zero
floor(-1/2)  -1       ceiling(-1/2)  0
floor(2)     2        ceiling(2)     2

On a complex argument, componentwise:

floor(3/2 + 5/2i)    1 + 2i
ceiling(3/2 + 5/2i)  2 + 3i
floor(-3/2 - 5/2i)   -2 - 3i

The derivative is left unevaluated — this is the answer to the question in the issue, and it is not zero:

diff(floor(x), x)    Derivative(floor(x), x)

Which is the same call this library already makes everywhere else: the derivative does not exist on the integers, so claiming 0 would be asserting something false at every integer rather than declining. An unevaluated Derivativef is the honest node, and it agrees with SymPy.

Simplifications worth having, all measured:

floor(n) where n is known integer     n
floor(floor(x))                       floor(x)
floor(x + 1)                          floor(x) + 1
floor(x + n) where n is integer       n + floor(x)

LaTeX: \left\lfloor{x}\right\rfloor and \left\lceil{x}\right\rceil.

round

Half to even, and unambiguously so — SymPy and Python agree, and it is IEEE 754's default:

round(1/2)   0        round(-1/2)  0
round(3/2)   2        round(-3/2)  -2
round(5/2)   2

So the issue's "half away from zero, or half to even" resolves to half to even on precedent. Worth noting it is not what Math.Round(double) does by default in C# — that is also half to even, but Math.Round(decimal) and most people's expectation is away from zero, so the choice needs writing down wherever it lands.

gcd — bigger than the issue said

I described this as "only defined on integers". That is wrong. SymPy's gcd is the polynomial gcd, and the integer case is a special case of it:

gcd(12, 18)        6
gcd(1/2, 1/3)      1/6          rationals, not just integers
gcd(x**2-1, x-1)   x - 1        polynomials
gcd(x, y)          1

That matters here because AngouriMath already has a polynomial GCD — Functions/Simplification/PolynomialGcd.cs, used by the PolynomialGcdCancellation rule set. So gcd is not a new algorithm needing a decision about symbolic arguments; it is largely an exposure of machinery that already exists, and the honest default for the cases it cannot settle is an unevaluated node rather than a Providedf.

min / max

Min(3, 5)      3
Min(x, y)      Min(x, y)        unevaluated, not expanded into abs
Max(x, 3, 5)   Max(5, x)        n-ary, and constants are absorbed

SymPy keeps them as nodes and does not rewrite them to (a + b -+ |a - b|)/2. That is evidence for the node rather than the sugar: the closed form is what you simplify to when it helps, not what you print. The sugar option would mean min(a, b) could never be printed back as min, which the round-trip contract makes permanent.

LaTeX: \min\left(1, x\right), \max\left(1, x\right).

Consequence for the order of work

floor and ceil are now the least contested — every question about them has a measured answer and they share all their machinery. I am implementing that pair first. round follows them cheaply once they exist (it is floor(x + 1/2) with the tie rule). min/max are next. gcd should be looked at alongside the existing PolynomialGcd rather than as a fresh number-theory function.

One thing I can confirm about cost: regenerating the unmodified grammar with JDK 25 and the committed ANTLR 4.13.1 jar, followed by the post-processing step, reproduces the checked-in parser byte for byte. So the grammar half of this is safe to touch — any diff from here is the new rule and not a toolchain difference.

[Rafael-SOWNet]

#827 landed floor and ceil. Recording what that closed, what it broke, and what is left, so this
issue is about the remainder rather than the whole list.

Closed by #827

Measured on master (46140f8):

simplify(floor(7/2))          3
simplify(ceil(-7/2))          -3
eval(floor(3/2 + 5/2i))       1 + 2i
simplify(floor(floor(x)))     floor(x)
derive(floor(x), x)           0 provided not x in ZZ
latex(floor(x))               \left\lfloor{x}\right\rfloor
solve(floor(x) = 3, x)        { 3 + t_1 provided t_1 in RR and t_1 >= 0 and t_1 < 1 }

The solve answer is better than this issue asked for.

Two defects it introduced

• Limit over floor or ceil overflows the stack and kills the process #829 — Limit over any floor or ceil overflows the stack and kills the process. It
  reintroduces lim x->2 signum(x) overflows the stack #704 on a new node pair: ComputeLimitDivideEtImpera has no override, so both take a
  base default that returns an unevaluated limit of themselves.
• floor and ceil of an infinity or NaN throw OverflowException #830 — floor(+oo), ceil(-oo) and floor(NaN) throw OverflowException out of evaluation.

Both are cases the node's own tests did not reach, and neither is specific to floor: they are the
two files a new Entity subtype is easiest to forget. That is worth a checklist and a
reflection-driven test before the rest of this list is implemented, not after.

One rule from the earlier comment that did not land

simplify(floor(x + 3))    floor(3 + x)

floor(x + n) -> n + floor(x) for integer n was listed above as worth having and is not there.

What is left, and how it splits

This issue is three questions with one title, and they have different blockers:

1. round / trunc — the rest of the rounding family. Cheap now that floor/ceil exist; they
   share all of the machinery. round's tie rule resolves to half to even on the precedent
   already measured in this thread. Worth adding frac (x - floor(x)) and div (floor(a/b), so
   that a = b*(a div b) + (a mod b) becomes statable alongside the Modf that already exists).

2. min / max — not a rounding question. It is N-ary operators with variables #248 wearing a different hat, because both want
   to be n-ary and commutative. One measurement settles the sugar-versus-node argument this issue
   left open:

   	Complexity
   (a + b - abs(a - b))/2	10
   a Minf(a, b) node	3

   Simplify returns the lowest-complexity candidate, so the closed form loses every ranking contest
   it enters — it would be generated and never chosen, which is the Simplifications of surds #205 failure mode. Node, not
   sugar. The closed form stays useful as an expansion rule that something asks for.

3. gcd — not a number-theory question and not a new algorithm.
   Functions/Simplification/PolynomialGcd.cs already computes polynomial GCD and is used by the
   PolynomialGcdCancellation rule set. This is an exposure. lcm comes with it.

Splitting along those three lines would let (1) ship without waiting on #248, and would stop gcd
being scheduled as though it needed an algorithm written.

Blocker for the node half

Everything in (2) and (3) that is a node is gated on #248 — whether adding an Entity subtype is
a breaking change — which #814 item 1 already flags as gating this issue, #286 and #495. (1) is
gated too for round/trunc; frac and div are not, since they are expressions over Floorf.