Re: New Fava extension: Tax loss harvester

[Justus Pendleton]

On Tuesday, March 10, 2020 at 10:32:32 AM UTC+7, Red S wrote:
>
> I recently shared 
>  a 
> beancount tool for identifying tax loss harvesting opportunities. This is 
> the fava plugin version. Starting a new thread for this because these these 
> are different code bases, and I intend primarily to develop this one (the 
> fava plugin) unless there is a lot of interest in the other as well.
>

It looks pretty good. Here are a few things I noticed while trying it out: 

It looks like if account_field is set to LEAF(account) then the URLs for 
the accounts are broken -- they take you to my-personal-ledger/account/LEAF 
instead of my-personal-ledger/account/Assets:Tree:Leaf

There's something wrong in how it collects the holdings. The command line 
version generates the correct set of holdings but the fava version also 
includes some lots that I sold last week. I haven't looked yet to figure 
out why they are being included.

The "purchases within the past 30 days" doesn't include purchases I made, 
it only includes sales I made. I think it is supposed to be the other way 
around?

-- 
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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/298b94dd-ed38-4bc2-8a77-cb59f6987f06%40googlegroups.com.

Re: New Fava extension: Tax loss harvester

[Red S]

On Wednesday, March 11, 2020 at 2:43:55 AM UTC-7, Justus Pendleton wrote:
>
> It looks like if account_field is set to LEAF(account) then the URLs for 
> the accounts are broken -- they take you to my-personal-ledger/account/LEAF 
> instead of my-personal-ledger/account/Assets:Tree:Leaf
>

I noticed this as well. I assume fava is adding this link if the column is 
named 'account'. I'll figure out a fix later.
 

> There's something wrong in how it collects the holdings. The command line 
> version generates the correct set of holdings but the fava version also 
> includes some lots that I sold last week. I haven't looked yet to figure 
> out why they are being included.
>

Ah, I included 'date <= DATE_ADD(TODAY(), -30)' in the fava version, to 
filter out purchases within the past 30 days since they cause washes. I 
realize now that is incorrect, since that (incorrectly) filters out sales 
during the last 30 days as well. I should include them in both the holdings 
and in the wash sales. Fix committed. Thanks for spotting this!
 

> The "purchases within the past 30 days" doesn't include purchases I made, 
> it only includes sales I made. I think it is supposed to be the other way 
> around?
>

This needed a fix as well. Not sure why it doesn't include the purchases, 
but I added 'number>0' in the query to filter out sales. Would you mind 
trying again?

Lesson: the queries pack a lot of assumptions into a dense SQL-like 
statement, and I'd not be surprised if there're a few more cases hiding. 
I'll soon commit a unit test to make this easier.

Thank you very much for test driving this and the helpful feedback!

-- 
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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/43a22ede-05db-4252-8018-f2670d945bc1%40googlegroups.com.

Re: "Transitive" conversion of currencies?

[Martin Blais]

That's a nice idea, but one problem is that if the number of transactions
flip-flops the path in the graph after inserting new ones, you will
experience potentially confusing differences in your reporting. The user
has to be aware of this.

On Wed, Mar 11, 2020 at 2:23 AM  wrote:

> I was also looking for strong cross-currency support for my accounts where
> prices do get very transitive... I ended up writing my own code to do this.
> The algorithm is as follows
>
> 1) Examine all cross-currency transactions to find all conversion
> "vertices" of a graph
> 2) Find the shortest distance (Dijkstra's algorithm) from the desired
> reporting currency to every other currency using a node distance of 1/n
> where n is the number of transactions between those two commodities
> 3) Convert the price of all non-reporting currencies to the reporting
> currency by converting along that path. Intermediate conversion use an
> interpolation algorithm for non-matching dates (I just chose linear)
>
> The result of this one off computation is a single CCY->USD type map that
> can be used for all remaining reporting just like before and have the same
> performance
>
> Hope this idea is of use!
>
> Regards,
>
>
> On Sunday, 13 October 2019 11:07:08 UTC+8, Martin Blais wrote:
>>
>> It does not, it's intended, and going down that route will lead you down
>> a rabbit hole. See previous chat on mailing lists.
>>
>> On Sat, Oct 12, 2019, 18:26  wrote:
>>
>>> I ran the query
>>>
>>> bean-query data/main.bean "SELECT account, sum(convert(position, 'CHF'))
>>> WHERE account ~ 'Assets' group by account"
>>>
>>> and I have in my ledger some entries in, say, GOLD and EUR.
>>> I also have a price datapoint for GOLD in EUR, and for EUR in CHF, at
>>> the same date.
>>>
>>> The result is that the assets in EUR are converted to CHF, but the ones
>>> in GOLD are left in GOLD.
>>>
>>> So unless I am mistaken, it would seem that beancount does not "combine"
>>> prices to get more conversions. Is that true? If so, is that intended?
>>> Would it make sense to try and write a plugin for this?
>>>
>>> Thanks
>>>
>>> M.
>>>
>>> --
>>> 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 bean...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beancount/b053a42b-44a9-44b0-abe3-fb85adb541b2%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 beancount+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beancount/fb6b97ad-3857-48ab-8741-8951043e5a96%40googlegroups.com
> 
> .
>

-- 
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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/CAK21%2BhPpmPB6JCj2AaPWm_f153CNgEGLMoURL1Pv6BHe1B%3DTCw%40mail.gmail.com.

Re: "Transitive" conversion of currencies?

[glorat]

Theoretically that can happen but in practice I don't think hit happens. 
And even if it does the effect is more noticeable.

My personal accounts that I have represented in beancount are probably 
close to the worst case scenario of real-life transitivity... I have income 
in GBP, I earn in CNY. I have some investment accounts in GBP with GBP 
investments and some investment accounts in USD with mixed investments. 
Through the history of adding new transactions, no flip flops happen 
(except maybe after just the initial txs) because of the trick of weighting 
the graph distances by 1/txs.size. So the more transactions happen, the 
more "obvious" the shortest path becomes.

In any case, I take it you're busy with non-beancount things these days so 
this might be academic for you. If there is interest, I can share more with 
those looking to implement

Kevin
p.s. The whole thing becomes somewhat moot if I inject daily historic FX 
prices into my accounts so almost everything goes through USD at that point.


On Wednesday, 11 March 2020 22:07:43 UTC+8, Martin Blais wrote:
>
> That's a nice idea, but one problem is that if the number of transactions 
> flip-flops the path in the graph after inserting new ones, you will 
> experience potentially confusing differences in your reporting. The user 
> has to be aware of this.
>
> On Wed, Mar 11, 2020 at 2:23 AM > wrote:
>
>> I was also looking for strong cross-currency support for my accounts 
>> where prices do get very transitive... I ended up writing my own code to do 
>> this. The algorithm is as follows
>>
>> 1) Examine all cross-currency transactions to find all conversion 
>> "vertices" of a graph
>> 2) Find the shortest distance (Dijkstra's algorithm) from the desired 
>> reporting currency to every other currency using a node distance of 1/n 
>> where n is the number of transactions between those two commodities
>> 3) Convert the price of all non-reporting currencies to the reporting 
>> currency by converting along that path. Intermediate conversion use an 
>> interpolation algorithm for non-matching dates (I just chose linear)
>>
>> The result of this one off computation is a single CCY->USD type map that 
>> can be used for all remaining reporting just like before and have the same 
>> performance
>>
>> Hope this idea is of use!
>>
>> Regards,
>>
>>
>> On Sunday, 13 October 2019 11:07:08 UTC+8, Martin Blais wrote:
>>>
>>> It does not, it's intended, and going down that route will lead you down 
>>> a rabbit hole. See previous chat on mailing lists.
>>>
>>> On Sat, Oct 12, 2019, 18:26  wrote:
>>>
 I ran the query

 bean-query data/main.bean "SELECT account, sum(convert(position, 
 'CHF')) WHERE account ~ 'Assets' group by account"

 and I have in my ledger some entries in, say, GOLD and EUR.
 I also have a price datapoint for GOLD in EUR, and for EUR in CHF, at 
 the same date.

 The result is that the assets in EUR are converted to CHF, but the ones 
 in GOLD are left in GOLD.

 So unless I am mistaken, it would seem that beancount does not 
 "combine" prices to get more conversions. Is that true? If so, is that 
 intended? Would it make sense to try and write a plugin for this?

 Thanks

 M.

 -- 
 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 bean...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beancount/b053a42b-44a9-44b0-abe3-fb85adb541b2%40googlegroups.com
  
 
 .

>>> -- 
>> 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 bean...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beancount/fb6b97ad-3857-48ab-8741-8951043e5a96%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/6b22905f-d188-4221-98f3-6db8049fd1e9%40googlegroups.com.

Re: "Transitive" conversion of currencies?

[glorat]

11 Mar (12 hours ago)
That's a nice idea, but one problem is that if the number of transactions 
flip-flops the path in the graph after inserting new ones, you will 
experience potentially confusing differences in your reporting. The user 
has to be aware of this.

- show quoted text -

> - show quoted text -
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beancount/fb6b97ad-3857-48ab-8741-8951043e5a96%40googlegroups.com
>  
> 
> .
>
me (glo...@gmail.com change) 
10:28 (less than a minute ago)
Theoretically that can happen but in practice I don't think it happens. And 
even if it does the effect is not noticeable in practice

My personal accounts that I have represented in beancount are probably 
close to the worst case scenario of real-life transitivity... I have income 
in GBP, I earn in CNY. I have some investment accounts in GBP with GBP 
investments and some investment accounts in USD with mixed investments. 
Through the history of adding new transactions, no flip flops happen 
(except maybe after just the initial txs) because of the trick of weighting 
the graph distances by 1/txs.size. So the more transactions happen, the 
more "obvious" the shortest path becomes.

In any case, I take it you're busy with non-beancount things these days so 
this might be academic for you. If there is interest, I can share more with 
those looking to implement

Kevin
p.s. The whole thing becomes somewhat moot if I inject daily historic FX 
prices into my accounts so almost everything goes through USD at that point.


On Wednesday, 11 March 2020 22:07:43 UTC+8, Martin Blais wrote:
>
> That's a nice idea, but one problem is that if the number of transactions 
> flip-flops the path in the graph after inserting new ones, you will 
> experience potentially confusing differences in your reporting. The user 
> has to be aware of this.
>
> On Wed, Mar 11, 2020 at 2:23 AM > wrote:
>
>> I was also looking for strong cross-currency support for my accounts 
>> where prices do get very transitive... I ended up writing my own code to do 
>> this. The algorithm is as follows
>>
>> 1) Examine all cross-currency transactions to find all conversion 
>> "vertices" of a graph
>> 2) Find the shortest distance (Dijkstra's algorithm) from the desired 
>> reporting currency to every other currency using a node distance of 1/n 
>> where n is the number of transactions between those two commodities
>> 3) Convert the price of all non-reporting currencies to the reporting 
>> currency by converting along that path. Intermediate conversion use an 
>> interpolation algorithm for non-matching dates (I just chose linear)
>>
>> The result of this one off computation is a single CCY->USD type map that 
>> can be used for all remaining reporting just like before and have the same 
>> performance
>>
>> Hope this idea is of use!
>>
>> Regards,
>>
>>
>> On Sunday, 13 October 2019 11:07:08 UTC+8, Martin Blais wrote:
>>>
>>> It does not, it's intended, and going down that route will lead you down 
>>> a rabbit hole. See previous chat on mailing lists.
>>>
>>> On Sat, Oct 12, 2019, 18:26  wrote:
>>>
 I ran the query

 bean-query data/main.bean "SELECT account, sum(convert(position, 
 'CHF')) WHERE account ~ 'Assets' group by account"

 and I have in my ledger some entries in, say, GOLD and EUR.
 I also have a price datapoint for GOLD in EUR, and for EUR in CHF, at 
 the same date.

 The result is that the assets in EUR are converted to CHF, but the ones 
 in GOLD are left in GOLD.

 So unless I am mistaken, it would seem that beancount does not 
 "combine" prices to get more conversions. Is that true? If so, is that 
 intended? Would it make sense to try and write a plugin for this?

 Thanks

 M.

 -- 
 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 bean...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beancount/b053a42b-44a9-44b0-abe3-fb85adb541b2%40googlegroups.com
  
 
 .

>>> -- 
>> 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 bean...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beancount/fb6b97ad-3857-48ab-8741-8951043e5a96%40googlegroups.com
>>  
>> 

Re: "Transitive" conversion of currencies?

[glorat]

Theoretically that can happen but in practice I don't think it happens. And 
even if it does the effect is not noticeable in practice

My personal accounts that I have represented in beancount are probably 
close to the worst case scenario of real-life transitivity... I have income 
in GBP, I earn in CNY. I have some investment accounts in GBP with GBP 
investments and some investment accounts in USD with mixed investments. 
Through the history of adding new transactions, no flip flops happen 
(except maybe after just the initial txs) because of the trick of weighting 
the graph distances by 1/txs.size. So the more transactions happen, the 
more "obvious" the shortest path becomes.

In any case, I take it you're busy with non-beancount things these days so 
this might be academic for you. If there is interest, I can share more with 
those looking to implement

Kevin
p.s. The whole thing becomes somewhat moot if I inject daily historic FX 
prices into my accounts so almost everything goes through USD at that point.

On Wednesday, 11 March 2020 22:07:43 UTC+8, Martin Blais wrote:
>
> That's a nice idea, but one problem is that if the number of transactions 
> flip-flops the path in the graph after inserting new ones, you will 
> experience potentially confusing differences in your reporting. The user 
> has to be aware of this.
>
> On Wed, Mar 11, 2020 at 2:23 AM > wrote:
>
>> I was also looking for strong cross-currency support for my accounts 
>> where prices do get very transitive... I ended up writing my own code to do 
>> this. The algorithm is as follows
>>
>> 1) Examine all cross-currency transactions to find all conversion 
>> "vertices" of a graph
>> 2) Find the shortest distance (Dijkstra's algorithm) from the desired 
>> reporting currency to every other currency using a node distance of 1/n 
>> where n is the number of transactions between those two commodities
>> 3) Convert the price of all non-reporting currencies to the reporting 
>> currency by converting along that path. Intermediate conversion use an 
>> interpolation algorithm for non-matching dates (I just chose linear)
>>
>> The result of this one off computation is a single CCY->USD type map that 
>> can be used for all remaining reporting just like before and have the same 
>> performance
>>
>> Hope this idea is of use!
>>
>> Regards,
>>
>>
>> On Sunday, 13 October 2019 11:07:08 UTC+8, Martin Blais wrote:
>>>
>>> It does not, it's intended, and going down that route will lead you down 
>>> a rabbit hole. See previous chat on mailing lists.
>>>
>>> On Sat, Oct 12, 2019, 18:26  wrote:
>>>
 I ran the query

 bean-query data/main.bean "SELECT account, sum(convert(position, 
 'CHF')) WHERE account ~ 'Assets' group by account"

 and I have in my ledger some entries in, say, GOLD and EUR.
 I also have a price datapoint for GOLD in EUR, and for EUR in CHF, at 
 the same date.

 The result is that the assets in EUR are converted to CHF, but the ones 
 in GOLD are left in GOLD.

 So unless I am mistaken, it would seem that beancount does not 
 "combine" prices to get more conversions. Is that true? If so, is that 
 intended? Would it make sense to try and write a plugin for this?

 Thanks

 M.

 -- 
 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 bean...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beancount/b053a42b-44a9-44b0-abe3-fb85adb541b2%40googlegroups.com
  
 
 .

>>> -- 
>> 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 bean...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beancount/fb6b97ad-3857-48ab-8741-8951043e5a96%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/c658ab8b-55d9-4ec4-8829-0af5e16aa873%40googlegroups.com.