Non-zero balances when zero is expected

[gbtorrance]

In fifo_open_positions.odt in the "Asset" and "Asset - Exchange" tabs I am seeing a few cases where Exchange balances for certain Access should be zero, but they are non-zero by a tiny fraction. For example: 0.00000000003 and 0.00000000011.

In all cases the funds should have been fully transferred out of the particular Exchange (resulting in a zero balance), but this is not reflecting correctly in the open positions. I have checked the numbers in the spreadsheet multiple times, and I'm pretty sure they are correct (i.e. should be zero). It's not a big deal, but as someone who likes things to be precise, it's a little distracting.

Is this an expected situation given imprecision of the underlying number types (either in LibreOffice or Python), or could there be something else going on here?

I'm happy to create a test case to replicate this, but before I do so I just wanted to ask, "Is this normal?" (If it is expected, no worries; feel free to close the ticket.)

Thanks!

[eprbell]

Errors around the tenth decimal position could be due to precision limits (RP2 uses 13 digits of precision, I'm not sure what LibreOffice's limits are). Do you see similar errors in the rp2_full_report.ods file?

[gbtorrance]

Hi. Thanks for the reply and the info.

To your question, yes, the same thing shows in the rp2_full_report.ods file.

Actually, I'm seeing another issue that I think is related to precision. It's resulting in the "Total in-transaction crypto value < total taxable crypto value" error occurring (when I believe there should be none).

In both cases I think the numbers should "zero out" nicely, but they're resulting in either tiny positive exchange balances or tiny negative ones (producing an error).

I've got examples for both in the attached and have added comments to the sheets (in red) for explanation.

Interested in your thoughts. Thanks!

RP2_Test.zip