TODO.txt

TODO List + Notes
=================

Slice passing is starting to actually work pretty well.

ak-build_next_active_chains will assert() in append_ev when there is a loop with exactly one stitch.
 --> Not fixing, because earlier code should *not* allow this situation to arise (really broken)

ak-peel_slice will sometimes create a disconnected next chain (one that doesn't contain a time function maximum)
 --> Should fix by checking that each next chain contains a bind-off location [time function maximum, I guess? could also just tag edges]
  This will require some changes to level_chains, as well as the time fn being passed to peel_slice.

Have now implemented: "if a next course intersects a boundary, the whole boundary is accepted" (more-or-less -- it actually takes the right part of the boundary to complete the chain; I suppose a different version of this would be to replace all boundary-intersecting chains with the boundary itself. That might have actually been easier.)

Note that without the special casing that explicitly discards, something goes wrong in slicing (probably because chains on boundaries result in vertices not getting used).


DTW nice-to-have in ak-link.

In the scheduling code:
 - the special-typed 'Start' / 'End' stitches basically require knitting not to end at a short row (i.e., I need to add code that hacks ending cycles onto everything)
 - some sort of offset-determination for cycles is needed
 - should consider using real xfer cost

Other than the flatten code being more permissive than it should be, balancing of both splits and merges should actually be working when linking. (Haven't had a lot of test data to run through it, yet.)

NOTE: the 'flatten' code will currently accept situations with unpaired segments. This won't work with the split/merge balancing of Appendix A.


-----
DAG Embedding v2 ("multipass")
  time ./dist/schedule st:tests/st/test-B.st js:temp.js
Before: 8.766s

  Idea: come up with left-to-right orderings *first*, then push through the weights for each ordering.
  Problem: split nodes actually have correlated/path-dependant left/right sides. So pushing through potentially generates a lot more states than you'd expect.

  Idea2: push weights without caring about order-dependence/node coupling; use this as a heuristic for A*.
  Note: table still as large as the number of active paths. I'm sure there's a way to find a node ordering that minimizes the maximum active options; maybe it requires trying all orderings?

Interruption: Why are the *so many* options reported for splits? Ah, because we're baking xfers into the nodes.
 Rolling xfers into edges for split/join nodes (which edge-collapse requires *anyway*) seems to really improve runtimes. (test-B gets to 1.509s)

-----

~Scheduling~

Fixed some bugs in shape assignment to options; running into the 'embed_DAG is slow' problem again.

Instruction generation would be a lot cleaner with some map<>s to track loop locations and storage stash statuses.
(actually, could avoid tracking stash statuses by reading tracked loop locations, which imply de-facto stash status)