Use this guide when answering merge request review comments.
A posted code suggestion is a sketch that has not been compiled; verify it like your own work before adopting it — including the C++14 baseline, Matrix/Array and expression-type mismatches, and numerically deliberate groupings. Reproduce a claimed defect before fixing it, and judge the suggested remedy separately from the finding: a real bug often arrives with a fix that breaks cases the current code handles. Hold your own claims to the same standard — a behavioral claim is established by reading the function body and the branch actually taken, never by a header‘s own Doxygen, which can be stale or describe an adjacent case; confirming that a path or symbol exists proves nothing about behavior, and universals need enumeration rather than inference from a few instances. Address every thread: apply the suggestion or explain the deviation, naming the commit that resolved it. Keep the response within the comment’s scope; a defect it exposes in shared code belongs in its own commit or merge request. After each round, re-verify that the merge request description and commit messages still describe the current head.
.coderabbit.yaml holds the path-specific instructions the CodeRabbit review bot applies when it is enabled on the project; they are the bot's rendering of these conventions and predict what an automated review will flag.
GitLab renders KaTeX in merge request descriptions and comments. Typeset real mathematics — bounds, recurrences, identities, error terms — as math: inline with dollar-backtick delimiters ($`h_j = \varepsilon\,\max(|x_j|, 1)`$; bare $...$ does not render on gitlab.com), display equations in a fenced ```math block. Keep identifiers that name actual code (eps, numext::maxi) in code spans, and do not dress a code-level statement up in LaTeX.