Debugging dbg likelihood calculation. Getting different results when we change the order of calculation. LengthDiff[][] store different values for k1,k2 and paired[k2],paired[k1]
Fixed dbGraphLikelihood caluclation in both implementations. fixed LengthDiff[][] calculation
implementing haplotypeLikelihood MCMC
Found a protential errors in the likelihood calculation, the floating point error when you try to add between haplotypes. The log/scaled log value is different. but when you scale it, the eachSrp[i] became the same
e.g
deltaDist = -1, changed to a good base, likelihood should increase
ln and eachSrp before -1347.4523849704574  -19.397934321800506
The logPD is different
44  8.665924639969688E112  9.372828631120779E110
ln and eachSrp after  -1347.4523849704574  -19.397934321800506
But the ln is the same before/after
Start to Implement bigDecimal calculation
Calculate E^i*NE*(s-i) in closer to R than using BigFunctions(logBinomD) or BigFunctions(CalculateeLogBinomDensityUsingBigDecimal)
use BigDecimal to perform update, very slow, and maybe didn't slove the problem.
-1GGTG
-2947.410990326172-372.47397933127564-371.20469283304761.7242733817308165E-1620.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000172427338173081657222401896268871676313097557026936081577438887639209870447073781573286632517016467647247114146702932703094552253480761753158815293901934143720881049440536368776508338124358789649014901668540648581320409705951098730138378637265075789715803202651648453981195289971311658599819868726963041820457508785
-2947.410990326172-372.47397933127564-371.204692833047551.7242733817308462E-1620.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000172427338173084610292041416679810548399237229246135155792903500391480133030675524718714462837187446709071979299227982510881578998297369367399968727427161307862283522297869250872858323854064988595705281924242555338203629132318748317944202106332543048032562545354928700055396063607368117678020444656429090675200131271
-371.20469283304755-372.47397933127564-372.47397933127562351572588369035107889149859722450040563907982175809724438058444038412082591712716430871029691572345675720072221177114653612936674969630127289604716947258407048888282708590508296725213272253078714532014544842279141513409352736958561072286141738079861494062532111130141288589202140004247391840858122085423935979606747309272724469054306546667000634924260602807644382518096450393410748242351119152015404819583017023711384956380067620220486380585233290296695533148231
6.135504034420051E-626.135504034420051E-62

at some stage (currently, it at eachSrpLogLikelihood[i] = BigDec.doubleValues()) still lost precision.
Implemented full calculation in BigDecimal, which can detect the difference of change is 1 base, but very slow
need another ~10 decimal places to see the differences
Old    -3032.64551945616    -376.9791009666023    1.9057093175026766E-164    0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000019057093175026764316597484999741219618214551337
new    -3032.64551945616    -376.9791009666023    1.9057093175026766E-164    0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000019057093175026764354364528231407890639702392757
-3032.64551945616    -3032.645519456159914898319588862600808915
-3032.64551945616    -3032.645519456159914902304122858286590614

Some need more decimals then this example