Changes between Initial Version and Version 3 of Ticket #18376


Ignore:
Timestamp:
05/07/15 15:11:48 (7 years ago)
Author:
dlucas
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • 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
  • Ticket #18376 – Description

    initial v3  
    1 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.
     1For 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.
    22
    33We 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.
     
    4545With 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.
    4646
    47 Note that, as it sounds more intuitive to manipulate vectors, `C.unencode()` will always return an element of a vectorial space.
     47Users will probably most often use and expect the message space `F^k`,
     48where `k` is the dimension of the code, and `F` the field. For this reason,
     49the default encoder should be an encoder with this message space, such
     50that `C.encode(m)` expects `m` from `F^k` and `C.unencode(c)` returns an
     51element of `F^k`.
     52
    4853We also now have a default implementation of `generator_matrix` in `AbstractLinearCode` which calls the `generator_matrix` method of the selected encoder.