You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've had a few instances where predicted postings lead to an unnatural posting order (and I have at least 2 people confirming having seen the same). For example, the output of:
with the filler in the first slot, and the original posting account being pushed to 2nd slot.
Having stepped through the code as this happens, it does seem to be just a prediction fluke that can occur, where accounts can end up in this order as result of predictor.py#L234.
This seems it can be easily addressed with a somewhat simplified update_postings(transaction, accounts) (entries.py#L6) to honor the original order, i.e. always start with posting[0] and augment with any predicted accounts, but am not 100% confident I understand the intent of the original logic in update_postings() and whether this change would upset existing work flows. PR attached with unit tests.
The text was updated successfully, but these errors were encountered:
awtimmering
added a commit
to awtimmering/smart_importer
that referenced
this issue
Apr 5, 2024
awtimmering
changed the title
Predictions might lead to original posting being siwtched to 2nd place post-prediction
Predictions might lead to original posting being switched to 2nd place after prediction
Apr 5, 2024
I've had a few instances where predicted postings lead to an unnatural posting order (and I have at least 2 people confirming having seen the same). For example, the output of:
in certain circumstances can lead to a predicted posting of
with the filler in the first slot, and the original posting account being pushed to 2nd slot.
Having stepped through the code as this happens, it does seem to be just a prediction fluke that can occur, where accounts can end up in this order as result of predictor.py#L234.
This seems it can be easily addressed with a somewhat simplified
update_postings(transaction, accounts)
(entries.py#L6) to honor the original order, i.e. always start withposting[0]
and augment with any predicted accounts, but am not 100% confident I understand the intent of the original logic inupdate_postings()
and whether this change would upset existing work flows. PR attached with unit tests.The text was updated successfully, but these errors were encountered: