Tim,
sounds like a good idea.
I guess you are planning to overload this additional method
to the existing one, so we can still intantiate the block
the usual way, right?
Achilleas
PS: I wonder what is the application you are interested in…
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.
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
On Mon, Feb 26, 2007 at 08:02:45PM -0800, Tim M. 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
Tim M. wrote:
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.
BTW, I wouldn’t worry about these accessors…
they are pretty much useless and can be either eliminated
or made more general, ie, essentially returning a vector
of length S with 1s and 0s indicating whether a specific state is
permitted or not.
Coming to think about it, d_S0 and d_SK can be eliminated as well and
this relevant information can be kept in the more descriptive d_S0v
and d_SKv length-S vectors.
Achilleas
Eric,
Don’t see any problem with either of your concerns.
Mapping 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
Achilleas and Eric,
I have attached a patch to trellis_viterbi_X.cc.t,
trellis_viterbi_X.i.t and trellis_viterbi_X.h.t
This patch allows for multiple initial and/or final states by calling
viterbi with a vector for S0 and/or SK. The call is overloaded so
that viterbi can still be called with a scalar. The two accessor
methods for d_S0 and d_SK still work for scalars but just return the
first element if S0 or SK are vectors. I was not sure how to overload
this based on return type.
I would be happy to write a patch for the test code qa_trellis.py but
it does not seem to have a test for viterbi right now.
I would also be happy to write a patch for the documentation
gr_trellis.xml (was this written by hand or machine generated?)
I don’t think there was any bounds checking for the scalar call with
S0 and SK so I did not add any for the vector call. i.e. you can call
viterbi with a value for SK that is greater than the number of states.
Tim
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 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
Tim,
thanks for the contribution.
At this point I am gnuradio-less since my hard disk
failed a couple of days ago…
but I’ll test all the uploaded code as soon as I am
up and running.
Thanks again,
Achilleas
Hi Achilleas
No problem. Would you like me to update the documentation and submit a
patch?
Good luck getting back up and running.
Tim