
Bugs and bug fixes for R/qtl
----------------------------------------------------------------------
This file is intended to contain all known bugs in the R/qtl package,
version by version.  The bugs marked with ">>" are not yet fixed.  See
STATUS.txt for further information on changes to the package.

If you find a potential bug in R/qtl, please send an email, with as
many details as possible and possibly example data, to Karl Broman,
<kbroman@jhsph.edu>.
----------------------------------------------------------------------

Version 0.91 bugs:

    1. There was a problem with read.cross with method="csv" in R
       version 1.4.0.  This was partly a bug in R, which has been
       fixed in version 1.4.1.  But by changing the use of
       as.is=TRUE to colClasses="character", the new package should
       work in R ver 1.4.0 as well.  [Fixed in version 0.92.]


Version 0.90 bugs:

>>  1. The X chromosome is not treated properly in either read.cross
       or, most importantly, in scanone and scantwo.  I should have
       written this down some time ago, as this bug has been known for
       a long time. 


Version 0.88 bugs:

    1. In the windows version, Rprintf in the C code only print after
       all of the calculations are complete.  We should flush the
       print buffer after each line. [Not really a bug; the issue with
       Rgui in Windows could be fixed by simply unchecking the
       "buffered output" option in "Misc" on the menu bar.] 

    2. scantwo.mr gives really bad results for the hypertension data.
       Lots of lod scores are extremely large. [Fixed in version
       0.89-9.] 

>>  3. scantwo with method EM can give interactive LOD scores < 0.
       This is a multiple modes problem.  In my experience so far,
       this only occurs at uninteresting loci, and so probably so not
       a big deal.  It'd be best to have some automatic selection of
       multiple starting points, at least as an option.


Version 0.87 bugs:

    1. Problem with subset.cross when one pulls out just one
       individual: cross$geno[[1]]$data is a vector rather than a
       matrix.  Look at $prob, $argmax, $draws, $errorlod, too.
       Similar problem for more than 1 individual if the $draws
       argument has one one simulation replicate.  [Fixed in version
       0.88-12.] 

    2. plot.scanone puts the chromosome numbers in the wrong place.
       Something to do with the argument gap.  [Fixed in version
       0.88-12.] 

    3. There is apparently a problem reading in data when a chromosome
       has only one marker.  This suggests a study of *all* functions
       to ensure that they work in the unusual case of a single
       marker. [Fixed in version 0.88-12.]

    4. sim.cross.f2 wasn't capturing an X chromosome in the input map
       appropriately.  [Fixed in version 0.88-11.]


Version 0.86 bugs:

    1. I suspect that there is a bug in sim.geno.  I have no
       evidence, to support this, but I'll be doing my best to verify
       that it is working correctly. [There isn't a bug in sim.geno,
       as far as I can see.  The problem I'd noticed was in the
       imputation method in scanone.  The return value was 
       mean{L}+var{L}/2, but should be mean{L}+log(10)*var{L}/2. 
       This is fixed in version 0.86-12.]


Version 0.85 bugs:

    1. There really was a bug in argmax.geno!  [Fixed in version
       0.86.]

    2. scanone.perm is wrong: I was doing independent permutations
       for each chromosome and then maximizing across chromosomes.
       I've scrapped the C code and am now just doing the simple
       thing: repeated calls of the R function scanone. [Fixed in
       version 0.86.]

    3. There's a problem with the convergence criteria in vbscan:
       The function is faster with tol=1e-8 than with tol=1e-5.
       [Fixed in version 0.86.]


Version 0.84 bugs:

    1. The "hyper" data has some markers out of order. [Fixed in
       version 0.85]


Version 0.83 bugs:

>>  1. In scanone, when there is a spike in the phenotype,
       sometimes the LOD curve has huge peaks and sometimes not.  I
       believe this is due to multiple modes in the likelihood surface,
       and with floating point errors, sometimes you go to one mode
       and sometimes another.  (I've seen the same problem in
       vbscan as well.)

    2. There seems to be an error in summary.scanone when there is
       only one chromosome.  Also, if there is more than one location
       sharing the maximum LOD, it returns all of them. [Fixed in
       version 0.85.]


Version 0.81 bugs:

>>  1. I often getting the following warning message when reading data
       with read.cross in "karl" format:
       
         "no finite arguments to min/max; returning extreme. in: 
          max(..., na.rm = na.rm)"

    2. read.cross.karl can give an error when it's trying to
       determine the number (and thus autosomal/sex-linked status) of
       each chromosome using the marker names, if the marker names are
       not of the usual mouse form. [I believe this is fixed in
       version 0.84.]

    3. Regarding the function read.cross.mm (for reading data in 
       mapmaker format):
 
       a. It gives an error when the map file has *'s in front of each
          of the marker names. [Fixed in version 0.82.]

       b. It leaves 0's where there is missing data; these should be
          NAs. [Fixed in version 0.82.]

       c. It fails to assign the correct chr type ("A" vs "X") to each
          chromosome. [Fixed in version 0.82.]

       d. It doesn't give marker names to the columns in the data
          matrices.  This causes major problems in argmax.geno. 
          [Fixed in version 0.82.]

    4. summary.cross should ensure that there are marker names in
       the appropriate places. [Fixed in version 0.82.]


Version 0.80 bugs:

    1. Slight bug in replace.map for 4way crosses.  [Fixed in
       version 0.81.]


Version 0.78 bugs:

    1. There is a bug in argmax.geno, in the case step > 0.
       I saw some data like 2-2-2-2-2-1, where with error.prob=0.01,
       it gave argmax=2-2-2-2-2-2 when step=1 but not when step=0.
       [This isn't really a bug, but rather a sad truth in result of
       the Viterbi algorithm.  The current code does, however,
       incorrectly chose among the most likely sequences, if there are
       several possible such.]  [NOTE: See version 0.85 above; there
       really was a bug, though Viterbi is still not to be trusted in
       the presence of appreciable missing data when error.prob > 0.] 


version 0.77 bugs:

    1. In create.map (used in calc.genoprob), there's a "names" 
       problem (resulting in an error) when the markers are
       equally-spaced and the "step" argument is at exactly that
       spacing. [Fixed in version 0.78.]


version 0.76 bugs:

    1. In sim.cross, there's a problem with the dimnames for
       the error indicator component, when simulating genotyping
       errors with a QTL present. [Fixed in version 0.77.]
       
----------------------------------------------------------------------
end of BUGS.txt
