- check that those are actually failing or that they are a doctest bug
- add _ci_run_filter so that we can easily make sure tests run in CI even
if they don't have the "parameter format"
- adding the tfhe package as a dependency is currently causing issues with
Cargo because of unified feature resolution it seems, it needs an
additional version specifier to disambiguate which package we are referring
to, an issue exists on their end but I don't think a fix is to be expected
soon https://github.com/rust-lang/cargo/issues/12891
- commiting this to main and then backporting the relevant pieces to 0.4.x
The BooleanBlock wrapper type is meant to convey the fact that
the ciphertext encrypts a 0 or 1.
Since its meant to be a simple wrapper, the goal for is to be flexible
and not add more burden than usefulness.
Hopefully this implementation somehow achieves that
Breaking Changes:
- This changes the return type of comparisons from a T to
a BooleanBlock. Requiring existing code to explicitely convert
using `.into_radix`.
- This makes the cmux/if_then_else functions take a BooleanValue
as the input type Requiring existing code to wrap their condition
ciphertext in a new BooleanValue
This commit removes the wrapping of the `tfhe::boolean`
that was done in the HLAPI, effectively making the HLAPI
only wrapping `tfhe::integer`.
FheBool is now reused to be a single shortint block
compatible with other type FheUint8,16,etc (previously they were not).
In the future, `tfhe::boolean` could be re-wrapped in hlapi, but
this time, to be used as a base for all integers and not just
FheBool.
BREAKING CHANGE:
- hlapi no longer wraps tfhe::boolean API.
- tfhe::ConfigBuilder::enable_bool/disable_bool/all_disabled/all_enabled
removed. Now default configuration should be done using
`tfhe::ConfigBuilder::default()`.
- `tfhe::ConfigBuilder::use_default_small_integer` removed
use `tfhe::CondifBuilder::default_with_small_encryption()`
- Uninitialied{ClientKey, PublicKey, CompressedPublicKey} error types
removed as these erros are no longer possible
This removes the wrapping of shortints from the HLAPI,
the reasons are:
Contrary to integers for which we have different bit size
by combining different number of blocks from the _same_ key.
shortints had different bit size, but also different keys
which lead to:
- Not being able to cast between 2 different shortint type
and between 1 shortint and 1 integer. Technically these casts
are possible, but requires a keyswitch (and likely a PBS).
But the keyswitch requires parameters, which may not always exists.
- Due to each shortint having different keys, the internal code to
manage that made heavy use of macros to avoid having thousands of
repeated lines. However, this made the code harder to follow / modify
especially for people that were not familiar with that.
- In practive to really benefit from shortints, proper management of
carry space is needed, however the HLAPI completely hides that,
resulting in less optimal performances. In short, shortints
are better used as a low level construct.
- Building a FheUint4 with two block of message_2_carry_2
is likely to be faster the one message_4_carry_4 for most use
cases.
So removing the wrapping of shortints will simplify the code, and
allow for more simplification later.
Also, it will allow us to expose Fhe{Ui/I}nt{2, 4, 6} types
which are compatible (cast_from/into) with Fhe{Ui/I}nt{8, 16, 32, etc}.
BREAKING CHANGE:
- FheUint{2,3,4} removed from HLAPI
- All HLAPI functions thied to shortints are removed
In encrypted shifts we pack 3 bits from 3 different blocks into the same
blocks by doing `b0 * 4 + 2 * b1 + b2`, and then do a PBS to simulate a
hardware mux gate.
If the inputs of shift (ie, in lhs << rhs, lhs != rhs, ie we don't do
lhs << lhs) this is fine regarding the norm2 noise.
However if we do things like `a << a` or `a >> a`, which is probably a
very rare thing but not impossible, the norm2 noise would go above the
limit that guarantees our error probability.
To fix that, we extract the bits that tells shift amount, so that they
are already properly aligned to their mux input position.
The packing becomes `b0 + 2 * b1 + b2` and so,
the noise growth is ok even in the worst case of doind `a << a`.
- remove buggy unchecked_scalar_add_assign and replace by the proper
implementation which had a different name
BREAKING CHANGE:
removed an API entry point which was not required
Move the comparisons test (eq, ne, ge, gt, etc)
that were in the comparator module out of the comparator module.
This is so that in later commits will create test cases out
of these tests so they can, like other unsigned tests be
used to test other implementations of ServerKey
