On Wed, Dec 30, 2020 at 1:39 AM [email protected] <[email protected]> wrote:
> On Tuesday, December 29, 2020 at 10:02:15 PM UTC-8 [email protected] wrote: > >> On Wed, Dec 30, 2020 at 12:55 AM [email protected] <[email protected]> >> wrote: >> >>> That makes sense. I was thinking of a system where >>> plugin/booking/interpolation iterate over the same entries until no more >>> modifications occur. This would involve some thought to prove (a) >>> commutativity (order doesn't matter), and (b) convergence (no infinite >>> iterations). >>> >> >> "Iterate over the same entry until no more modification occurs" seems >> error prone to me, and a potential nightmare for debugging. >> > > Agreed. Although I've seen it work very well in systems where the key was > to identify the constraints to make it work predictably. > > > Reg. the other approach -- i.e., supporting this in core booking algos: >>> even outside crypto, isn't the philosophy you've put forth "works on >>> unambiguous source"? Given that, is there a syntax that removes ambiguity? >>> For example: >>> *2020-01-01 * "Transfer"* >>> * Asset:BrokerageA -10 HOOLI {}* >>> * Asset:BrokerageB: 10 HOOLI {}* >>> >>> might be unambiguous for FIFO, LIFO, and STRICT, and arguably for NONE >>> (and AVG in the future). I.e., identical CostSpec after inverting the sign >>> of one. I haven't thought deeply about all cases, and anyway, not the most >>> important thing for v3. >>> >> >> I'm not sure I understand what you mean by "works on unambiguous source", >> > > What I mean is: even if a CostSpec if incompletely specified, as long as > it is unambiguous beancount will process it correctly. For example: there's > no need to specify date in a cost specification as long as the price is > adequate to uniquely identify the lot. Along those lines, I was making the > argument that the transaction above is unambiguous in saying "transfer all > lots from BrokerageA to BrokerageB," and thus, it would be nice for the > core booking algos to handle it correctly rather than depend on a plugin. > Yes The challenge is to design those things to be general. I think in this case the addition could be as simple as honoring a special flag on an interpolation posting, telling the interpolation code not to convert to cost. > > > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOXf%3DQ9xRCsPgKw0_uBJFRZhjR9EVt%2B2vbDxvrRb-WQNw%40mail.gmail.com.
