The purpose of this introducing this trait
is to purposefully create a breaking change
so that later we have more freedom on refactoring
some stuff with less risk of breaking
From SageMath point of view some tfhe-rs parameters set are
equivalent. We deduplicate those by storing their name in the tag
field. Grouping them that way we decrease analysis time
dramatically.
- the CPU data layout is truncated to only store relevant bodies (i.e.
emtpy bodies are assumed to be 0) but the GPU CUDA code manages full GLWEs
only. To fix that we manage the data layout during conversions to have
consistent behavior when copying the list to/from CPU/GPU. Compression code
has been fixed on the CPU side to have the proper length for the output
expected by the CUDA code
This commit fixes a few bugs
* The shift/rotate functions used when blocks encrypt a number of bits
that is a power of 2 was causing a panic when working on one block.
- Also, when the number of blocks was low (e.g 2 blocks with 2_2
params) a noise cleaning step was wrongly skipped
* The function used when blocks encrypt non power of 2 number of bits
also had a problem
The test have been updated to test with different block sizes and check
the noise level
Overall these bugs only affected low block counts (e.g FheUint2,
FheUint4) ciphertexts
We use large GitHub hosted runners to run CI pipeline for external
contributions. This avoids possible secret exposition due to usage
of pull_request_target event. It also removes a layer a complexity
to ensure such secrets are not exposed.
The flow would be improved since tfhe-rs maintainers won't have to
relaunch failed jobs individually, thanks to the "approve and run"
button in GitHub user interface.
Some counts where to copied from the correct
source to correct destination.
And more importantly, the list on cuda side was stored
using a GlweCiphertextList but the data was compressed
(so the list was mostly empty). This use of a GlweList
instead of a specialized type lead to problems when converting
to Cpu
Running against last remote commit would induce undesired behavior,
especially on pull-request approval.
For example a change in integer layer could occur in the
pull-request commits list but the changes aren't contained in the
last remote commit. Then, on approval, aws_tfhe_integer_tests.yml
workflow would be skipped although it should run regarding the
base commit.
