Skip to content

unify full and complex packing among FBT - #1370

Merged
pascoec merged 3 commits into
devfrom
fully-packed-FBT
Oct 21, 2026
Merged

pascoec merged 3 commits into
devfrom
fully-packed-FBT

Conversation

@andreea-alexandru

Copy link
Copy Markdown
Collaborator
  • Discrete FBT: with CKKSDataType REAL, N/2 RLWE values are processed as a single ciphertext in the modular reduction and LUT evaluation; two ciphertexts only for COMPLEX (N values). Previously two were always used at full packing, even with the upper coefficient half empty.
  • FE FBT: with CKKSDataType COMPLEX the function is applied to the real and imaginary parts separately, f(a) + i f(b), over two ciphertexts. Previously the imaginary parts were silently discarded.
  • Examples, benchmark and tests set the data type from the packing; new test rows cover N/2 values and both parts of complex inputs.

Closes #1369.

@pascoec pascoec added this to the Release 1.6.2 milestone Oct 17, 2026
@pascoec pascoec linked an issue Oct 17, 2026 that may be closed by this pull request
@pascoec pascoec added the optimization Improves performance label Oct 17, 2026
@andreea-alexandru

andreea-alexandru commented Oct 20, 2026 •

Copy link
Copy Markdown
Collaborator Author

20d4337 is a pure optimization.
e60648f is touching on some things that should go in the FBT refactoring. The main distinction between my commit and this one is that to work with all the N RLWE values, the user has to explicitly mention COMPLEX, otherwise, the second N/2 half would be dropped. To ensure no existing user project which used N values and did not specify COMPLEX changes functionality, a new argument of numValues was added. However, note that this argument would be redundant in the pure CKKS FBT, and will likely be revised in the refactoring.

andreea-alexandru and others added 3 commits October 20, 2026 18:05
For CKKSDataType COMPLEX, FE functional bootstrapping and full-packing
EvalMVB evaluated the series on the real and imaginary channels and took
twice the real part of each with its own conjugation. Compute
2Re(s0) + i*2Re(s1) as (s0 + i*s1) + conj(s0 - i*s1) instead, so one
conjugation (one key switch) serves both channels; multiplication by i
is a free monomial multiplication. RecombineFEChannels is replaced by
TwiceRealPartPair, and the order-1 integer branch of EvalMVBNoDecoding,
which has no conjugation, keeps its own recombination.

Per-function EvalMVBNoDecoding on full complex packing is 1.18x (2-bit
FLEXIBLEAUTO) and 1.26x (2-bit FIXEDMANUAL) faster, 1.04x for 4-bit and
unchanged for 8-bit; FE functional bootstrapping with precomputed powers
is 1.01-1.03x faster. Outputs and precision are unchanged.
EvalFBTSetup takes a trailing numValues argument, the number of values
encrypted in the RLWE input, and records the resulting layout in the
FBT precomputation. EvalMVBPrecompute and EvalMVBNoDecoding read it
there instead of the CKKS data type. With full packing, more than N/2
values are processed as two ciphertexts (real and imaginary channels),
and N/2 values as one, at half the cost of the approximate modular
reduction and the look-up table evaluation. More values than the slots
hold are rejected at setup.

numValues defaults to the capacity of the slots (N for full packing),
which keeps the two-ciphertext processing of earlier releases. Code that
passes N values without setting a CKKS data type therefore stays correct,
instead of silently losing the upper half of its values under the default
REAL data type. The CKKSDataType settings derived from the packing are
removed from the examples, benchmark and tests, which pass the value
count instead.

FE functional bootstrapping still uses the CKKS data type, which
describes its input. The documentation notes when full complex packing
needs CKKSDataType COMPLEX: encoding complex plaintexts or decrypting
the CKKS ciphertext before EvalHomDecoding.
@pascoec
pascoec merged commit c4355ef into dev Oct 21, 2026
20 checks passed
@pascoec
pascoec deleted the fully-packed-FBT branch October 21, 2026 13:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

optimization Improves performance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unify treatment of N/2 complex slots across bootstrapping flavors

3 participants