Auswertung mathematischer Werte in Zahlenfeldern

[wulf@…]

Der anhaengende Patch erlaubt die Eingabe beliebiger mathematischer
Funktionen bestehend aus +-*/ in alle Zahlenfelder.
(technisch: alles was durch SL::Form:parse_amount() geht)

Ich benutze das schon einige Zeit und es hat sich sehr bewaehrt. Vor
allem zur Berechnung von Nettopreisen, da ich teils mit Endverbrauchern
zu tun habei, aber intern ausschliesslich mit Nettopreisen arbeite, finde
ich es praktisch.
Beispiel:

• Ich vereinbare mit einem Kunden eine Endpreis von 100,- EUR
• Beim Editieren eines Artikels gebe ich als Preis 100/1.19 (Zahlenformat 1000.00) ein
• Das System macht daraus 84.0336134453782

oder

• ein Kunde hat 136 Stueck eines Artikel bestellt und will noch 20 mehr, dann haenge ich nur ein +20 im Mengenfeld an und gut. (ich weiss, das ginge auch ganz gut im Kopf -- ist nur ein Beispiel)

Das ganze funktioniert auch beim Anlegen Editieren von
Waren/Dienstleistungen?, Rabatt, Menge usw.

Natuerlich muss die Eingabe dem gewaehlten Zahlenformat entsprechen, bei
Zahlenformat 1.000,00 also 100/1,19 usw.

Habe mich noch mal eine bisschen am Kopf gekratzt, ob ich in
parse_amount() ein Sicherheitsloch aufreisse, bin aber der Meinung nein.

Auswertung mathematischer Werte in Zahlenfeldern

Auswertung mathematischer Werte in Zahlenfeldern 2

<pre>

Habe mich noch mal eine bisschen am Kopf gekratzt, ob ich in
parse_amount() ein Sicherheitsloch aufreisse, bin aber der Meinung nein.

heute morgen beim Duschen fiel es mir wie Schuppen von den Augen, ist
zwar kein Sicherheitsloch, aber trotzdem ein fiese Falle:

Durch meine Ersetzungen wuerde aus:

(5+1)*3 = 8 -- sind aber 18
Zinseszins waere in manchen Notierungen gegangen:

100 EUR mit 5 % ueber 10 Jahre
100*1.0510 = 162.889462677744 -- stimmt
100*(1+0.05)10 = 105.1 -- stimmt nicht, ist besonders fies,

weil es nicht so schnell als Fehler aufaellt.

100*1.05^{10 = 9765725 -- stimmt natuerlich nicht}

Also um hier kein Fass ohne Boden aufzumachen:

Ich habe nun auf die 4 Grundrechenarten beschraenkt. Wenn die sich
nicht parsen lassen, evaluiert es nach 0, das ist das Gleiche, was auch
vorher bei ungueltigen Eingaben passierte. Es sollte durch den Wert 0
auch eindeutig auffallen, das bei der Eingabe was nicht stimmte.

Anbei noch mal ein Patch mit der ueberarbeiteten

SL::Form::parse_amount()

So ist das wenn man da aus seinem kleinen Dreisatz-Kosmos kommt,
vielleicht haette ich doch Abitur machen sollen ...
</pre>

aktuelle patches unter

​git://gpl.coulmann.de/git/lxo-wulf.git

branch: publish_1500_calc_numbers

rebased to

commit 915e943a8fa8ab2a32576d4609632d598898cf20
Merge: 7b47939 27ae865
Author: C. Braun <information@…>
Date: Fri May 13 15:46:47 2011 +0200

Hmm. Ich empfinde diese Beschränkung auf die Grundrechenarten als überflüssig. Sobald du einfach Klammern zulässt, sollte das doch kein Problem mehr sein.

Der Check auf gültige Eingaben sieht erst einmal nur so aus:

return 0 unless $input =~ m/ ^{[ 0-9 , \. \( \) \+ \- \* \/ \s ]* $/x;}

Musst Whitespaces nicht entfernen. Sicherheitstechnisch ist das vollkommen OK, solange du nicht ermöglichst, Funktionen oder Shell-Befehle aufzurufen. Funktionen gehen deshalb nicht, weil in Perl Funktionsnamen mit einem Buchstaben beginnen müssen, und Shell-Befehle klappen nicht, weil du kein Backtick ` zulässt.

Also:

Aus

return ($amount * 1);

wird schlicht

return $amount =~ m/ ^{[ 0-9 , \. \( \) \+ \- \* \/ \s ]* $/x ? eval($amount) * 1 : 0;}

(ungetestet)

Auch dieses ist nun in Revision a1b919c gemerget. Ich habe auch meine Variante noch mit reingezogen, sodass nun auch Klammern erlaubt sind.

danke fuer's einbauen, hier noch der Changelog

​git://gpl.coulmann.de/git/lxo-wulf.git
branch: publish_1500_changelog