Re: [Discuss-gnuradio] modification of gr-trellis to support, multiple initial and/or final states

[Tim Meehan]

Achilleas and Eric,

Thanks for the reply.  .  I agree performance should  not be an issue.

I understand the steps you describe below, and that is the approach I
am taking.
I have overloaded the viterbi_X for using (int S0) or (vector<int> S0)
and the calls through Python seem to work.  I think I will need a
total of four overloaded methods for each combination when I include
SK.

The modification to  void viterbi_algorithm(int I, int S ... )  was
very straightforward.

I agree with replacing the internal d_S0 and d_SK with vectors.  That
is what I have already done.  I am hesitant about changing the
accessors because I would not want to break someone else's code.

I will finish up with the changes for SK and double check my tests
then send out a patch (after I get some sleep :-)


Tim

On 2/26/07, Achilleas Anastasopoulos <address@hidden> wrote:
> Eric,
>
> Don't see any problem with either of your concerns.
> Mapping <vectors> to python is straightforward as you know
> better than I.
> Also, performancewise there is absolutely no additional overhead,
> since the initialization of the metrics is done anyway; Tim will only
> change some values from INF to 0; that's all.
>
> Tim, the easiest way to do it is to define  2 additional private
> vectors, say d_S0v and d_SKv in the class.
> Then update the existing constructor so that those new vectors are
> initialized, and overload an additional contructor.
>
> Finally update the core VA algorithm to work for the general case.
>
> Let me know if you need any help with this.
>
> Achilleas
>
> Eric Blossom wrote:
> > On Mon, Feb 26, 2007 at 08:02:45PM -0800, Tim Meehan wrote:
> >
> >>Hi Achilleas,
> >>
> >>Yes, I will overload the method so that I don't break any existing
> >>code.  I am going to have to think about the return values.  There are
> >>public methods to return d_S0 and d_SK, and I don't want to break
> >>these either.  I will consult some friends who are better C++
> >>programmers then I am.
> >
> >
> > Of concern to me is how you plan to map all this stuff into Python.
> >
> >
> >>I am looking at MLSD of bit-stuffed sequences assuming the number of
> >>stuffed bits in the sequence is known a-priori.  I am really just
> >>using it as a toy problem as an excuse to get me going with gnuradio.
> >>
> >>Tim
> >
> >
> > I'm also wondering how or if this code will impact the performance of
> > the existing decoder???
> >
> > Eric