Hi Marc,
thanks for the quick response.
On Tue, Sep 26, 2017 at 06:45:42PM +0200, Marc Rehmsmeier wrote:
> Hi Andreas,
>
> I am not entirely sure what I was doing there and then. That seems to be
> version 2.1.2, correct?
Yes, that's correct. We always try to package the latest upstream
> In version 2.1.1, the array is allocated with ALPHASIZE+1. The <= in the
> k-loop is originally not a mistake; the function's sibling,
> init_dl_dangle_dg_ar, has the <= in the first loop (the i-loop). These are
> the allocations in version 2.1.1:
>
> double dr_dangle_dg_ar[ALPHASIZE][ALPHASIZE][ALPHASIZE+1];
> double dl_dangle_dg_ar[ALPHASIZE+1][ALPHASIZE][ALPHASIZE];
>
> You see that there's a +1 on the corresponding sides.
Yes, I see. Would you like to express that the better fix for that
issue would be to restore this allocation inside energy.h instead of
fixing the loop index?
> At some point I introduced an additional letter to the alphabet, the X (a
> masking letter; see input.h). I am not sure about the program logic anymore,
> whether X can actually be used for lookups in the energy tables (as the N
> could). In hybrid_core.c, where the energy functions are used, I check for X
> in a few places, so the idea was perhaps to not use X for lookups (in fact, I
> do not want to consider any masked sequence at all). Should that be true,
> ALPHASIZE being 6 would be wasteful, but it shouldn't harm otherwise. Of
> course, you could change the two for-loops (the k-loop in
> init_dr_dangle_dg_ar and the i-loop in its sibling) so that they use <
> instead of <=, but, while that might fix the array bound bug, it might not
> solve an underlying logic problem. In effect you might have a program that
> works technically, but produces the wrong result. Unfortunately I can't help
> with that. You could try fixing the loops and then do a few runs and compare
> the outputs, as a minimal test.
So it seems to me that it is safer to leave the loop untouched ...
> I hope that helps.
Definitely.
Thanks again
Andreas.
--
http://fam-tille.de
