[gnucash-de] Bayes Algorithmus: Wichtige Verbesserungsvorschläge

Christian Gruber christian_gruber at gmx.de
Mi Jun 3 17:19:27 EDT 2020


Ich habe die Verbesserungsvorschläge in der englischen Mailingliste mit
einigen Entwicklern diskutiert. Die Rückmeldungen dazu siehe unten.


Am 18.05.20 um 00:21 schrieb Christian Gruber:
>
> Hallo Theophilix
>
> Am 15.05.20 um 12:03 schrieb Matthias Gruhn:
>>
>> Hallo zusammen,
>>
>> dass der Import-Zuordnungen Editor existiert habe ich erst jetzt
>> gesehen! Danke für den Hinweis. Habe nun alle Zuordnungen gelöscht.
>>
>> Zwei wichtige Verbesserungsvorschläge, die sehr schnell umsetzbar
>> sein dürften:
>>
>> 1. Bitte eine Option für die Mindestlänge der gespeicherten
>> Bayes-Begriffe in die Gnucash-Einstellungen rein. Begründung: Wenn
>> jedes „+“ oder jeder Schrägstrich aufgenommen wird oder jede kleine
>> Zahl, dann sorgt das für Chaos, wenn man die Liste bearbeitet.
>> Vielleicht kommt dadurch auch der Algorithmus durcheinander.
>>
> Ja, diese Überlegung hatte ich anfangs auch. Da man aber normalerweise
> wenig bis gar nicht mit dem Import-Zuordnungen Editor arbeiten muss,
> ist das auch nicht wirklich schlimm. Ich nehme das mal als Anregung
> auf und werde es ggf. an die Entwickler weitergeben.
>
Der Vorschlag wurde im Allgemeinen als sinnvoll betrachtet. Die Regeln,
welche Begriffe in die Liste aufgenommen werden sollen und welche nicht,
sollten aber vom Benutzer editierbar sein.

Wer es nachlesen möchte: https://bugs.gnucash.org/show_bug.cgi?id=797779

> Ich kann aber zumindest dazu sagen, dass der Bayes-Algorithmus nach
> meinen Erkenntnissen durch die vielen kleinen Zeichen weder im
> negativen noch im positiven Sinne beeinflusst wird.
>
>> 2. Der Bayes Algorithmus sollte alle Buchungen desjenigen Kontos, in
>> das die Buchungen reinsollen, vorher auslesen (falls das nicht schon
>> so funktioniert) und diesen Daten höchste Priorität zuteilen.
>> Begründung: Die Daten von vergangenen Buchungen im betreffenden Konto
>> sind 99% richtig, da bereits überprüft / korrekt zugeordnet.
>>
> Das ist ebenfalls eine Überlegung, die mich nach wie vor beschäftigt.
> Ich halte das ebenfalls für sinnvoll. Wenn etwas dagegen spricht, dann
> ist es maximal der Zeitaufwand für das Auslesen aller Buchungen,
> welcher dann bei jedem Import anfallen würde. Möglicherweise war das
> der Grund, warum sich die Entwickler gegen diese Vorgehensweise
> entschieden haben. Ich werde das mal in Erfahrung bringen.

Der Hauptgrund gegen das Auslesen aller Buchungen direkt vor dem Import
war wie vermutet die Befürchtung, dass das zu lange dauern könnte.
Alternativ wurde aber vorgeschlagen, dass der Nutzer das Auslesen
manuell starten könnte (siehe auch die Anmerkung von Christoph R.). Auch
die Angabe eines Zeitraums für das Auslesen der Buchungen wurde von den
Entwicklern begrüßt.

Wer es nachlesen möchte: https://bugs.gnucash.org/show_bug.cgi?id=797778

>> Hierzu eine Überlegung (ignorieren, falls zu banal und schon
>> integriert): Statt alle vorhandenen Buchungen auszulesen und in
>> Begriffe zu zerlegen (Dauer? Sinn?), könnte der Algorithmus nur einen
>> Begriff (Mindestlänge wichtig, s.o. ) der neuen Buchung extrahieren
>> und in allen vorhandenen Buchungen danach suchen. Wenn eine passende
>> vorhandene Buchung gefunden wird, in der der Begriff vorkommt, soll
>> zur Sicherheit ein zweiter Begriff (Mindestlänge wichtig, s.o. ) aus
>> der neuen Buchung extrahiert und in der gefundenen Buchung gesucht
>> werden. Wenn dieser zweite Begriff in der gefundenen Buchung
>> ebenfalls vorliegt soll der Algorithmus das Buchungsziel übernehmen.
>> (Verfeinerung des Prinzips dann mit weiteren Begriffen).
>>
>> Grüße,
>>
>> Theophilix
>>
>>
>> _______________________________________________
>> gnucash-de mailing list
>> gnucash-de at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-de


Mehr Informationen über die Mailingliste gnucash-de