Re: [wsjt-devel] Strange hash collision?

[Bill S. <g4...@cl...>]

Hi Paul,

it is a known defect in WSJT-X v2.0.0, already fixed for the next release.

Note your callsign does not have a unique hash code, hash codes are a 
one-way function, a.k.a. lossy compression. Many callsigns can have the 
same hash code, the point is to represent a callsign using less bits 
that necessary to exactly represent the callsign, which is necessary if 
the callsign is non-standard, or the other callsign is non-standard. A 
standard callsign requires 28 bits to store, a non-standard callsign in 
WSJT-X v2.0.0 FT8 and MSK144 modes can take up to 58 bits to store.

73
Bill
G4WJS.

On 16/01/2019 01:15, Paul Kube wrote:
> Bill,
>
> Then I don't understand why the hashcode for my call isn't used. It is 
> known, or my call wouldn't be correctly decoded in those two received 
> messages. Or so it seems to me.
>
> 73, Paul K6PO
>
>
> On Tue, Jan 15, 2019 at 4:11 PM Bill Somerville <g4...@cl... 
> <mailto:g4...@cl...>> wrote:
>
>     On 16/01/2019 00:02, Paul Kube wrote:
>     > But why is my call hashed wrong in my own Rx Frequency window?
>
>     Hi Paul,
>
>     hash codes are just numbers, what you see is a lookup of a table
>     indexed
>     by the hash code. The wrong call is being looked up and printed.
>     There
>     is nothing wrong with the hash code, just a problem with how it is
>     translated to a callsign.
>