On BrownianInterval/Path/Tree about torchsde HOT 2 CLOSED

Thanks for initiating the discussion on this!

I agree that the Brownian portion of dev is messy. Though, I'd still like to keep BrownianPath (either C++ or Python, but ideally just one). I think it's likely I'll get it more performant on small problems than BInterval in terms of speed, since it doesn't involve the random seed splitting computation, and the Python-end of that is not too far from being finished. blist is slightly an issue, but I can switch to other libraries with better Python 3 support.

I think it's also good to keep BrownianTree around, since there might be a scenario where we actually need to have a strict mapping from global entropy to the trajectory. FWIW, I don't think that's strictly achievable with BInterval without much modification, though I'm afraid I don't totally follow the proposal you listed above. If there's an easy way to let BInterval do this, then I think letting BTree be a special case sounds like a good plan.

If the concern is that these will block the new release, I think we can temporarily deprecate the blocking ones. For now, I'm not inclined to deprecate BrownianPath. I can spend some time in getting it fixed this week, but I don't think I'll add support for davie/foster Levy area for it.

from torchsde.

I think it's possible to have BInterval include the global entropy->trajectory determinism when used as a BTree, so I'll make that happen.

True that BPath should be able to avoid the seed splitting overhead. I'd be inclined to have it still be an alias for BInterval, just with an additional use_entropy flag set to false.

One negative of this proposal is that BPath and BTree both support efficient point-based evaluation, whereas BInterval only does intervals efficiently. This isn't an issue for anything we're doing in torchsde, as we only need intervals, but if someone is using B* for this as part of some other project it would affect them.

from torchsde.