Skip to content

docs(fmpz_lll): document U initialisation for transformation capture#2718

Open
edgarcosta wants to merge 1 commit into
flintlib:mainfrom
edgarcosta:docs/fmpz-lll-u-init
Open

docs(fmpz_lll): document U initialisation for transformation capture#2718
edgarcosta wants to merge 1 commit into
flintlib:mainfrom
edgarcosta:docs/fmpz-lll-u-init

Conversation

@edgarcosta

@edgarcosta edgarcosta commented Jun 12, 2026

Copy link
Copy Markdown
Member

The LLL functions apply the row operations performed on B to U as well, so U must be set to the identity matrix beforehand to capture the transformation; a freshly initialised U is zero and stays zero. This was undocumented (the module's tests and arb_mat_spd_lll_reduce call fmpz_mat_one first). Reported by @JohnCremona on flint-devel: fmpz_lll returns U=0.

Documents this for fmpz_lll_d, fmpz_lll_wrapper and fmpz_lll, points the ULLL and with_removal variants at the same note, and records that fmpz_lll_t allocates no memory and so has no clear function (the PS of the same thread).

fmpz_mat_hnf_transform and fmpz_mat_snf_transform need no such note: they write U (and V) entirely themselves.

The LLL functions apply the row operations performed on B to U as well,
accumulating the transformation into U's existing contents; they never
initialise U themselves. A freshly initialised (zero) U therefore stays
zero, which is surprising and was undocumented.

Also note that fmpz_lll_t context objects allocate no memory, so there
is no clear function to call.

Reported by John Cremona on flint-devel (fmpz_lll returns U=0, May 2026).
@edgarcosta

Copy link
Copy Markdown
Member Author

@JohnCremona please feel free to suggest edits on the language

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant