Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-zero balances when zero is expected #112

Open
gbtorrance opened this issue Apr 20, 2024 · 2 comments
Open

Non-zero balances when zero is expected #112

gbtorrance opened this issue Apr 20, 2024 · 2 comments

Comments

@gbtorrance
Copy link

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
Copy link
Owner

eprbell commented Apr 21, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants