Mz/glwe ks test

[mayeul-zama]

Check-list:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

---

This change is 

[IceTDrinker]

Some small comments on the parts I've started reading

Reviewed 3 of 9 files at r1, all commit messages.
Reviewable status: 3 of 9 files reviewed, 3 unresolved discussions

---

tfhe/src/core_crypto/commons/math/decomposition/decomposer.rs line 149 at r1 (raw file):

    /// Decode a plaintext value using the decoder to compute the closest representable.
    pub fn decode_plaintext(&self, input: Scalar) -> Scalar {

let's open an issue on that, we have lots of places in the code and/or docstrings doing that

also here input should be a Plaintext and output should be a Cleartext ? How is this called in the GLWE KS thing ?

---

tfhe/src/core_crypto/algorithms/polynomial_algorithms.rs line 924 at r1 (raw file):

}

pub fn polynomial_list_wrapping_sub_scalar_mul_assign<Scalar, InputCont, OutputCont, PolyCont>(

doesn't feel like this should have scalar in the name ? What am I missing, both polynomials have the same scalars right ?

---

tfhe/src/core_crypto/algorithms/polynomial_algorithms.rs line 948 at r1 (raw file):

}

pub fn polynomial_list_wrapping_sub_scalar_mul_assign_custom_mod<

same thing on the scalar naming ?

[IceTDrinker]

Some more comments

Reviewed 1 of 9 files at r1.
Reviewable status: 4 of 9 files reviewed, 8 unresolved discussions (waiting on @mayeul-zama)

---

tfhe/src/core_crypto/commons/math/decomposition/term.rs line 237 at r1 (raw file):

    T: UnsignedInteger,
{
    level: usize,

I would think having the slice first would be better layout wise ? Even though rust may be doing whatever it wants, would also be more consistent wit all our entities which have containers

---

tfhe/src/core_crypto/commons/math/decomposition/term.rs line 322 at r1 (raw file):

    /// assert_eq!(term.level(), DecompositionLevel(3));
    /// ```
    pub fn level(&self) -> DecompositionLevel {

no need for a base log accessor ?

---

tfhe/src/core_crypto/commons/math/decomposition/term.rs line 351 at r1 (raw file):

        level: DecompositionLevel,
        base_log: DecompositionBaseLog,
        slice: &'a [T],

same thing with the ordering of fields

---

tfhe/src/core_crypto/commons/math/decomposition/term.rs line 466 at r1 (raw file):

    /// assert_eq!(term.level(), DecompositionLevel(3));
    /// ```
    pub fn level(&self) -> DecompositionLevel {

same thing, need an accessor for base log I would think

---

tfhe/src/core_crypto/commons/math/decomposition/iter.rs line 161 at r1 (raw file):

/// called again.
///
/// Such a pattern can not be implemented with iterators yet (without GATs), which is why this

Not sure I understand this comment here, some GATs have been added to Rust, we use them notably for the ContiguousEntityContainer trait family, so, what's the limitation here ?

The reference I see proposes to have an IntoIterator implementation which would return a type implementing the Iterator trait borrowing from this type

compiler has the same suggestion

error: associated type `Iterator::Item` is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
   --> tfhe/src/core_crypto/commons/math/decomposition/iter.rs:191:17
    |
191 |     type Item = &[T];
    |                 ^
    |
note: you can't create an `Iterator` that borrows each `Item` from itself, but you can instead create a new type that borrows your existing type and implement `Iterator` for that new type
   --> tfhe/src/core_crypto/commons/math/decomposition/iter.rs:190:39
    |
190 | impl<T: UnsignedInteger> Iterator for SliceSignedDecompositionIter<T> {
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `tfhe` (lib) due to 1 previous error

The same way we have Vec::iter which returns a specific Iter<'a, T> object which implements IntoIterator

[IceTDrinker]

Reviewable status: 4 of 9 files reviewed, 8 unresolved discussions (waiting on @mayeul-zama)

---

tfhe/src/core_crypto/commons/math/decomposition/iter.rs line 161 at r1 (raw file):

Previously, IceTDrinker (Arthur Meyre) wrote…

Not sure I understand this comment here, some GATs have been added to Rust, we use them notably for the ContiguousEntityContainer trait family, so, what's the limitation here ?

The reference I see proposes to have an IntoIterator implementation which would return a type implementing the Iterator trait borrowing from this type

compiler has the same suggestion

error: associated type `Iterator::Item` is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
   --> tfhe/src/core_crypto/commons/math/decomposition/iter.rs:191:17
    |
191 |     type Item = &[T];
    |                 ^
    |
note: you can't create an `Iterator` that borrows each `Item` from itself, but you can instead create a new type that borrows your existing type and implement `Iterator` for that new type
   --> tfhe/src/core_crypto/commons/math/decomposition/iter.rs:190:39
    |
190 | impl<T: UnsignedInteger> Iterator for SliceSignedDecompositionIter<T> {
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `tfhe` (lib) due to 1 previous error

The same way we have Vec::iter which returns a specific Iter<'a, T> object which implements IntoIterator

Some attemps on my end failed, otherwise use interior mutability with a Cell to wrap the Vec ? potential issues with invalidated iterators, but hoepfully our usage should not suffer from that problem

[IceTDrinker]

Reviewable status: 4 of 9 files reviewed, 8 unresolved discussions (waiting on @mayeul-zama)

---

tfhe/src/core_crypto/commons/math/decomposition/iter.rs line 161 at r1 (raw file):

Previously, IceTDrinker (Arthur Meyre) wrote…

Some attemps on my end failed, otherwise use interior mutability with a Cell to wrap the Vec ? potential issues with invalidated iterators, but hoepfully our usage should not suffer from that problem

Or rather RefCell for enforcing borrow rules at runtime

[IceTDrinker]

Reviewable status: 4 of 9 files reviewed, 8 unresolved discussions (waiting on @mayeul-zama)

---

tfhe/src/core_crypto/commons/math/decomposition/iter.rs line 161 at r1 (raw file):

Previously, IceTDrinker (Arthur Meyre) wrote…

Or rather RefCell for enforcing borrow rules at runtime

Actually that's probably not doable, which is a shame, I would still like to see if we can have some better ergonomics than the manual next_term which looks error prone to me

[IceTDrinker]

Reviewable status: 4 of 9 files reviewed, 8 unresolved discussions (waiting on @mayeul-zama)

---

tfhe/src/core_crypto/commons/math/decomposition/iter.rs line 161 at r1 (raw file):

Previously, IceTDrinker (Arthur Meyre) wrote…

Actually that's probably not doable, which is a shame, I would still like to see if we can have some better ergonomics than the manual next_term which looks error prone to me

Ok thinking about this some more, we said this would be the easy to use API, so maybe let's remove the inner outputs buffer and return owned values here, knowing that we already have an optimized version for the PBS that does the smart thing, we can add/use more optimized primitives later

[IceTDrinker]

Actually maybe a while let (Some(key), Some(decomp)) = (iter.next(), decomp.next_term())

Could do the trick ?