Bob,
I agree there is seems to be something fishy about the
multimarriage procedure, as the repeat-until loop can only ever be
executed once and, if it is reached, multi is always set to be true. I
checked in mlink.p and multi is only used once, inside collapseup, where
it causes a recursive call to the same routine. I suggest (but haven't
verified) that this effectively fails safe - the extra call will always
be made if there are offspring, and doesn't hurt if the other parent is
the same as before. Multiple marriages don't cause zero likelihoods or
obvious errors, and generally the results from MLINK agree with those
from LIPED, so the code must actually work, but this could be another
prime candidate for a speed-up.
The multimarriage procedure would make sense if, inside the
repeat-until loop, multi was set true if q <> child.ma (or q <>
child.pa for females). Then the loop would continue until it either ran
out of sibs or encountered a different spouse, and multi would reflect
whether or not this person had kids by more than one partner. Since there
is guaranteed to be at least one child (p.foff <> NIL) when the loop is
entered, a further small speedup could be made by starting with the
pointer to the second child (foff.ma or foff.pa according to the sex of
the parent) and changing the loop to a while loop which checks for child
<> NIL at the top rather than the bottom of the loop. Obviously, this
would only speed up reading the data and have no effect on the subsequent
calculations.
If multi was set to true only when someone has more than one
partner, this should, in most cases, approximately halve the number of
calls to collapseup and make quite a difference to the time taken to
calculate the likelihoods. All the above is reasoning, though, and hasn't
been checked out, but it wouldn't be too hard to construct example
pedigrees to see whether what I've surmised is really true.
I'd be interested to hear the outcome.
Good luck,
John Attwood.
