Hi Greg and Joe,
As Joe said, the stack decoder is only in wsprd_exp and it requires a
command-line argument (-J) to activate it, as the default algorithm in
wsprd_exp is the Fano algorithm.
The tests conducted by me and Joe show that my implementation of Jelinek’s
stack-bucket algorithm doesn’t seem to provide any significant advantage over
the Fano decoder in the wspr application. I am still inclined to replace the
current wsprd with the Fano version of wsprd_exp. All of my tests indicate that
the default configuration of wsprd_exp produces more decodes in less time than
wsprd does. This is due to improvements in the sync algorithm and not due to
anything related to the sequential decoder. However --- when Joe compared wsprd
to wsprd_exp (Fano) he didn’t find any significant difference between the two.
If you decide to do some tests, Greg, it’d be interesting to see if you see any
difference between wsprd and wsprd_exp (with the default settings).
Steve
> On Jul 28, 2015, at 2:22 PM, Joe Taylor <j...@princeton.edu> wrote:
>
> Hi Greg,
>
> The experimental ("Jelinek") decoder is currently being built only as
> wsprd_exp.
> -- Joe
>
> On 7/28/2015 3:08 PM, Greg Beam wrote:
>> Hi Joe, Steve,
>>
>> Are these updates in the main wsprd binary, or do we still need to build
>> the wsprd_exp binary and copy it over to wsprd to test the changes?
>>
>> 73's
>> Greg, KI7MT
>>
>> On 7/28/2015 12:22 PM, Joe Taylor wrote:
>>> Hi Steve,
>>>
>>> Nice job with implementation of a sequential decoder using the Jelinek
>>> Stack Algorithm!
>>>
>>> I have now run some reasonably thorough tests of it, comparing results
>>> with the default Fano decoder in wsprd. I confirm essentially all of
>>> your basic conclusions. Jelinek with maxcycles=5000 produces nearly the
>>> same results, in the same execution time, as Fano with maxcycles=10000.
>>>
>>> In my tests the command-line "-d" option produced about 7-8% more
>>> decodes, at the cost of roughly 5 x longer execution time. Again, this
>>> was true for both Fano and Jelinek.
>>>
>>> Now we know... which is good!
>>>
>>> -- Joe, K1JT
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> ------------------------------------------------------------------------------
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
