NOTES

(-) fitCode (returned from bdotsFit) (located in bdotsFitter function)
Allows for subset based on condition fit
  ## Fail Code ==
  # + 1 - 0.8 < R2 < 0.95
  # + 2 - R2 < 0.8
  # + 3 - AR1 == FALSE
  ## This gives
  # 0 - AR1 TRUE and R2 > .95
  # 1 - AR1 TRUE and 0.8 < R2 < 0.95
  # 2 - AR1 TRUE and R2 < 0.8
  # 3 - AR1 FALSE and R2 > .95
  # 4 (3 + 1) - AR1 FALSE and 0.8 < R2 < 0.85
  # 5 (3 + 2) - AR1 FALSE and R2 < 0.8
  # 6 indicates model did not fit at all

(-) For bdotsObject, the fist is stored as a length one list with gnls object inside

(-) Bob made note to hide 0.9 for cor default from user, but allow to be specified with dots

(-) In bdotsBoot, for the while loop determining PD matrix, have escape hatch and issue warning if fit without correlation in bivariate normal

(-) value of rho is implied by argument to `cor`. If cor == TRUE rho <- 0.9 (or user input). If cor = FALSE, rho = 0

(?) sys.nframe() returns number of frames from global env. How does this work in parellel? Fuck, I've got something sexy for that.

(-) should make doubleGauss(concave = TRUE), logistic(), poly(n = N) actual functions that return everything needed for fitting parameters based on input of data. This would keep the model/parameter fitting fullyl specified by this function. If we assume it has a specified form, anybody could create their own to do the same. We can put the ones we built into their own R files (all gauss functions, all logistic), but then document what it is, and what it requires

Say they pass `call = doubleGauss(concave = TRUE)`, we can then take this and do `call[[data]] <- data` to add what is needed to these functions. It will also make passing shit to clusterExport cleaner. FUCK, we can do that from the beginning. Pass in rho, cor, whatever else we need to do so

(-) print.bdots <- wrapper around print.data.table. Take the bdotsObj, hide the rows that are marked as 'removed' and only print out the remaining ones

(-) add model coefficients to bdotsObj output <- I don't like this just being appended. I think it would be far cleaner as a matrix stored in attributes
-- Note, though, that means I would have to add bdots::`[`. It would also not save them from using subset(bdotsObj, ..., ...). Fuck. Or any of the dplyr things. For now, I'm going to not worry about the refit step.

(-) Can I fit paired group in gnls at same time? By melting DT by group?

(-) https://stackoverflow.com/questions/27547548/solving-error-message-step-halving-factor-reduced-below-minimum-in-nls-step-a

(-) For fitting multiple curves simultaneously, this seems to confirm my original intuitiion:
https://stackoverflow.com/questions/27405484/2-curves-simultaneous-nonlinear-regression

(-) (!) LOL. I can rewrite bdotsFit and bdotsFitter so that bdotsFitter is the "base case" and I can otherwise just call bdotsFit on itself. That removes an entire function from this package! ARHARHAHRA!!!!! (it's in parallel  because there are only two cases 1) it's a single observation or 2) its multiple, and then when parApply that shit

(-) instead of checking class  "bdotsObj", make function isBdots. That way, if something is lost while transforming it, we can still recover

(-) Should rewrite split.data.table for split.bdotsObj <- When doing this, also check to see if the returnX attribute is there. If so, that should be split according to however the bdotsObj is split. Possibly this should extend to subsetting as well, i.e., functions with `[`

(-) If we want to be able to show significant regions for arbitrary collection of objects (for example, for diff of diff, we have 7 total fits, 3 of which constitute a set of differences. If we wanted to make which of these regions were were significant that were not the main analysis, we need to repeat the findModified alpha. FOr example, we do that for diff of diff. But If I want to do sub analysis for LI.W and LI.M WITHIN that bdBootObj, I would want my plots to also show me there where things are significant.

(-) To the above - if we do that, i.e., if the user specifies that that calculation should be done, we should find a way to save it in the bdotsBootObj. We can also 'recommend' the memoise package, in case they wish to view the plots multiple times

(-) re bdotsBoot curveList. Instead of having everything sprawled out, we should perhaps have something like list(grp, diff). That is, instead of curveList == (LI.W, LI.M, LI.diff, TD.M, TD.W, TD.diff, diff), perhaps curveList == (LI, TD, diff), with LI == (LI.W, LI.M, LI.diff). But then, if we only have a single group, is it curveList == (LI, diff) with LI == (LI.W, LI.M)? Doing it that way removes internal consistency, and we are left with the same sort of 'conditional' splitting that we had before (conditional in that we can tell by length of curveList or values of curveGroup what happened).

(-) For deployment of shiny app - https://stackoverflow.com/questions/37830819/developing-shiny-app-as-a-package-and-deploying-it-to-shiny-server

(-) in curveList from bdotsBoot, determine if we actually need to retain curveMat. If we have parMat and time, we can just rebuild it. It takes up quite a bit of memory, which can get expensive passing it around. Then we can abstract away the curve buildilng part of curveBooter, making that function quite a bit simpler on its own

(-) pressing issue, and perhaps pervasive throughout, is the issue of the original names of the dataset and how they contrast with what i had (time, y, group,. etc). This comes up in plots, formulas, and refits. Right now we have a unsightly mix of transferring around a modified copy of the dataset, but this is NOT ideal at all. Worse, this fucks things up within the curveFunction stuff too. Goddamnit

(-) If bdotsFit made to be recursive, it will be much easier to call and get the exact format I want for bdotsRefit

(-) Should make fitCode not a factor, but then add it as factor ONLY in summary where it is used. 

Ideas:
- Add argument for minimum R2 (i.e., if R2 < 0.8, drop auto correlation and try again)

--------
Loading required package: data.table
data.table 1.14.0 using 1 threads (see ?getDTthreads).  Latest news: r-datatable.com
**********
This installation of data.table has not detected OpenMP support. It should still work but in single-threaded mode.
This is a Mac. Please read https://mac.r-project.org/openmp/. Please engage with Apple and ask them for support. Check r-datatable.com for updates, and our Mac instructions here: https://github.com/Rdatatable/data.table/wiki/Installation. After several years of many reports of installation problems on Mac, it's time to gingerly point out that there have been no similar problems on Windows or Linux.
**********