Wednesday, April 13, 2022

Re: Some thoughts regarding GSoC

El 13/4/22 a las 19:37, Elof Wecksell escribió:

> There was a discussion a while ago regarding how polynomials are used in
> the different blocks of GRC and GR. At least for GRC, my opinion is that
> it should be friendly towards new users who might not be programmers.
> Today, polynomials are entered as an integer, and the size of the
> polynomial must be entered in another field, even though it could be
> determined from the polynomial. Example: Mask: 0x8003 K:14 => [15,1,0]
>
> My suggestion is that, at least in GRC, maybe as parallel blocks to the
> existing, that polynomials are entered in the [15,1,0] fashion, as a
> Python-list of exponents, and that mask and K are derived from that
> input, instead of the other way around. This goes for the blocks
> Scrambler, Descrambler, LFSR-generators, Reed-Solomon FEC, and probably
> more.

Hi Elof,

I think that's a good idea about making polynomials easier to use.
However, there is another tricky fact about polynomials, and it is that
some authors will list p(x), while others will list the "reverse"
polynomial p(1/x)x^d (here d is the degree of p). I don't know how to
solve this notation inconsistency, other than with good documentation
about what notation we use. In some cases there might be a choice which
is more natural (the polynomial of a multiplicative scrambler, for
instance, since it's its transfer function in the usual Z-tranform sense).

Additionally, when listing the polynomials in hex (as a mask), some
authors will omit the leading term (since it's always 1), and some
authors will omit the independent term (since in most non-degenerate
cases it's also 1).

In any case, I think that the approach we take should be
retro-compatible, and not break people's flowgraphs and documentation.
An approach could be to provide the two kinds of input as alternatives
in the same block.

Best,
Daniel.

No comments:

Post a Comment