docs(frontend): adding small intros

closes #https://github.com/zama-ai/concrete-internal/issues/837

docs/compilation/direct_circuits.md

@@ -1,5 +1,7 @@
 # Direct circuits
 
+This document explains the concept of direct circuits in Concrete, which is another way to compile circuit without having to give a proper inputset.
+
 {% hint style="warning" %}
 Direct circuits are still experimental. It is very easy to make mistakes (e.g., due to no overflow checks or type coercion) while using direct circuits, so utilize them with care.
 {% endhint %}

docs/core-features/bitwise.md

@@ -1,5 +1,7 @@
 # Bitwise Operations
 
+This document describes how comparisons are managed in Concrete, typically "AND", "OR", and so on. It covers different strategies to make the FHE computations faster, depending on the context.
+
 Bitwise operations are not native operations in Concrete, so they need to be implemented using existing native operations (i.e., additions, clear multiplications, negations, table lookups). Concrete offers two different implementations for performing bitwise operations.
 
 ## Chunked

docs/core-features/comparisons.md

@@ -1,5 +1,7 @@
 # Comparisons
 
+This document describes how comparisons are managed in Concrete, typically 'equal', 'greater than', and so on.  It covers different strategies to make the FHE computations faster, depending on the context.
+
 Comparisons are not native operations in Concrete, so they need to be implemented using existing native operations (i.e., additions, clear multiplications, negations, table lookups). Concrete offers three different implementations for performing comparisons.
 
 ## Chunked

docs/core-features/floating_points.md

@@ -1,6 +1,8 @@
 # Floating Points
 
-**Concrete** partly supports floating points. There is no support for floating point inputs or outputs. However, there is support for intermediate values to be floating points (under certain constraints).
+This document describes how floating points are treated and manipulated in Concrete.
+
+**Concrete** partly supports floating points. There is no support for floating point inputs or outputs. However, there is support for intermediate values to be floating points (under certain constraints). Also, we note that one can use an equivalent of fixed points in Concrete, as described in [our tutorial](../../frontends/concrete-python/examples/floating_point/floating_point.ipynb).
 
 ## Floating points as intermediate values
 

docs/core-features/minmax.md

@@ -1,5 +1,7 @@
 # Min/Max Operations
 
+This document explains how to compute minimum and maximum between values in Concrete, covering different strategies to make computations faster, depending on the strategy.
+
 Finding the minimum or maximum of two numbers is not a native operation in Concrete, so it needs to be implemented using existing native operations (i.e., additions, clear multiplications, negations, table lookups). Concrete offers two different implementations for this.
 
 ## Chunked

docs/core-features/rounding.md

@@ -1,5 +1,7 @@
 # Rounding
 
+This document details the concept of rounding, and how it is used in Concrete to make some FHE computations especially faster.
+
 Table lookups have a strict constraint on the number of bits they support. This can be limiting, especially if you don't need exact precision. As well as this, using larger bit-widths leads to slower table lookups.
 
 To overcome these issues, rounded table lookups are introduced. This operation provides a way to round the least significant bits of a large integer and then apply the table lookup on the resulting (smaller) value.

docs/core-features/table_lookups_advanced.md

@@ -1,5 +1,7 @@
 # Table lookups (advanced)
 
+This document details the management of Table Lookups(TLU) within Concrete for advanced usage. For a simpler guide, refer to the [Table Lookup Basics](table_lookups.md).
+
 One of the most common operations in **Concrete** are `Table Lookups` (TLUs). All operations except addition, subtraction, multiplication with non-encrypted values, tensor manipulation operations, and a few operations built with those primitive operations (e.g. matmul, conv) are converted to Table Lookups under the hood.
 
 Table Lookups are very flexible. They allow Concrete to support many operations, but they are expensive. The exact cost depends on many variables (hardware used, error probability, etc.), but they are always much more expensive compared to other operations. You should try to avoid them as much as possible. It's not always possible to avoid them completely, but you might remove the number of TLUs or replace some of them with other primitive operations.

docs/core-features/tagging.md

@@ -1,5 +1,7 @@
 # Tagging
 
+This document explains the concept of tagging, which is a debugging tool to make a link between the user's Python code and the Concrete MLIR circuits. Such a link can be useful when an issue is raised by the compiler on some MLIR, to know which Python code it corresponds to.
+
 When you have big circuits, keeping track of which node corresponds to which part of your code becomes difficult. A tagging system can simplify such situations:
 
 ```python

docs/core-features/truncating.md

@@ -1,5 +1,7 @@
 # Truncating
 
+This document details the concept of truncating, and how it is used in Concrete to make some FHE computations especially faster.
+
 Table lookups have a strict constraint on the number of bits they support. This can be limiting, especially if you don't need exact precision. As well as this, using larger bit-widths leads to slower table lookups.
 
 To overcome these issues, truncated table lookups are introduced. This operation provides a way to zero the least significant bits of a large integer and then apply the table lookup on the resulting (smaller) value.

docs/dev/compilation/compiler_workflow.md

@@ -1,5 +1,7 @@
 # Compilation
 
+This document explains the different passes happening in the compilation process, from the Concrete Python frontend to the Concrete MLIR compiler.
+
 There are two main entry points to the Concrete Compiler. The first is to use the Concrete Python frontend. The second is to use the Compiler directly, which takes [MLIR](https://mlir.llvm.org/) as input. Concrete Python is more high level and uses the Compiler under the hood.
 
 Compilation begins in the **frontend** with tracing to get an easy-to-manipulate representation of the function. We call this representation a `Computation Graph`, which is a Directed Acyclic Graph (DAG) containing nodes representing computations done in the function. Working with graphs is useful because they have been studied extensively and there are a lot of available algorithms to manipulate them. Internally, we use [networkx](https://networkx.org), which is an excellent graph library for Python.

docs/explanations/fusing.md

@@ -1,6 +1,6 @@
 # Fusing
 
-Fusing is the act of combining multiple nodes into a single node, which is converted to a table lookup.
+This document describes the concept of fusing, which is the act of combining multiple nodes into a single node, which is converted to a Table Lookup.
 
 ## How is it done?
 

docs/explanations/security.md

@@ -1,5 +1,7 @@
 # Security
 
+This document describes some security concepts around FHE that can help you generate parameters that are both secure and correct.
+
 ## Parameter Curves
 
 To select secure cryptographic parameters for usage in Concrete, we utilize the [Lattice-Estimator](https://github.com/malb/lattice-estimator). In particular, we use the following workflow: