Context Navigation

Changes between Initial Version and Version 3 of Ticket #18376

Ticket #18376
- Property Status changed from new to needs_review
- Property Commit changed from to bad97158f1e6b46821bb311422c2e0f73b06319d
- Property Branch changed from to u/dlucas/encoder
- Property Authors changed from to David Lucas

-                      initial
+                      v3
 For now, linear codes don't have a proper structure for encoding, "encoding" meaning handle the bijection between the message space of the code and its ambient space.
+For now, linear codes don't have a proper structure for encoding, "encoding" meaning handle the bijection between a message space of the code and its ambient space.
 We propose in this ticket a new structure, designed to handle message -> codeword and codeword -> message transformations. The former operation is designated as encoding, the latter as unencoding.
 …
 With this design, we are able to satisfy specific experimentation which requires specific encoders as well as generic experimentation for which any encoder will be fine.
+Note that, as it sounds more intuitive to manipulate vectors, `C.unencode()` will always return an element of a vectorial space.
+Users will probably most often use and expect the message space `F^k`,
+where `k` is the dimension of the code, and `F` the field. For this reason,
+the default encoder should be an encoder with this message space, such
+that `C.encode(m)` expects `m` from `F^k` and `C.unencode(c)` returns an
+element of `F^k`.
 We also now have a default implementation of `generator_matrix` in `AbstractLinearCode` which calls the `generator_matrix` method of the selected encoder.