kaufmännisch auf 0,5 oder 1 runden

[juergen]

Hallo zusammen,

im Moment verwende ich nachfolgendes, weil am genauesten:
JasonDX's Vorschlag:
round((StrToFloat(s) * 2 + 0.00000000000001)) / 2) Edit1.Text:= '12,4999999999999999999' -> 12,5 -> erst ab der 19.Stelle falsch

Marc seine Funktion:
myround(StrToFloat(Edit1.Text)) Edit1.Text:= '12,2499999999999999' -> 12,5 -> ab der 16.Stelle falsch

grenzgaenger seine Funktion:
trunc((StrToFloat(Edit1.Text)) * 2 + 0.5) / 2 Edit1.Text:= '12,4999999999999999' -> 12,5 -> ab der 16.Stelle falsch

Prinzipiell lässt sich diese Ungenauigkeit mit diesem Konzept von Stringkonvertierung und Real wohl nicht lösen.
Ich vermute man müsste expliziet nur mit Integer und dessen Funktionen arbeiten um genauere Ergebnisse zu erreichen.

Da ich keine Summierungen verwende wo sich dann die evtl. Ungenauigkeiten summieren könnten, kann ich damit leben.

Danke an alle für die Unterstützung! :thumb:

[grenzgaenger]

wenn du genaue ergebnisse haben möchtest, darfst du keine gleitkommazahlen (single, double, real, extented, float, etc. pp.) verwenden. hier kommen nur integer werte in betracht. also, z.b. integer, word, longint, int64, currency.

weshalb rechnest du die zahlen nicht erst in ein datenformat um, welches auch einigermassen valide ist? ansonsten hast du immer die probleme, dass sie in die eine oder andere richtung, willkürlich, kippen. damit wirst du nie glücklich werden...

wenn du auf assembler ebene schaust, schau dir mal "binary coded decimal" (BCD) an. das format wurde extra erfunden um die rundungsprobleme zu vermeiden.. die CPU hat hierfür auch einen extra modus ... :-) (COBOL kann das von haus auf..., 'ne bilanz macht einfach keinen spass, wenn aktiva und passiva nicht aufgehen ;-) )

[Der.Kaktus]

Zitat:

Zitat von juergen

Hallo zusammen,

im Moment verwende ich nachfolgendes, weil am genauesten:
JasonDX's Vorschlag:
round((StrToFloat(s) * 2 + 0.00000000000001)) / 2) Edit1.Text:= '12,4999999999999999999' -> 12,5 -> erst ab der 19.Stelle falsch

Marc seine Funktion:
myround(StrToFloat(Edit1.Text)) Edit1.Text:= '12,2499999999999999' -> 12,5 -> ab der 16.Stelle falsch

grenzgaenger seine Funktion:
trunc((StrToFloat(Edit1.Text)) * 2 + 0.5) / 2 Edit1.Text:= '12,4999999999999999' -> 12,5 -> ab der 16.Stelle falsch

Prinzipiell lässt sich diese Ungenauigkeit mit diesem Konzept von Stringkonvertierung und Real wohl nicht lösen.
Ich vermute man müsste expliziet nur mit Integer und dessen Funktionen arbeiten um genauere Ergebnisse zu erreichen.

Da ich keine Summierungen verwende wo sich dann die evtl. Ungenauigkeiten summieren könnten, kann ich damit leben.

Danke an alle für die Unterstützung! :thumb:

haste kein Vertrauen zur primitivsten Version? *sfg* s.o.

[grenzgaenger]

Zitat:

Zitat von Der.Kaktus

haste kein Vertrauen zur primitivsten Version? *sfg* s.o.

denke, das hat nix mit vertrauen zu tun, so lange er keinen datentyp nimmt, welcher keine rundungsfehler erzeugt, wird er immer probleme haben. nicht umsonnst sollte man die floats vermeiden... ;-)

[Der.Kaktus]

Zitat:

Zitat von grenzgaenger

Zitat:

Zitat von Der.Kaktus

haste kein Vertrauen zur primitivsten Version? *sfg* s.o.

denke, das hat nix mit vertrauen zu tun, so lange er keinen datentyp nimmt, welcher keine rundungsfehler erzeugt, wird er immer probleme haben. nicht umsonnst sollte man die floats vermeiden... ;-)

na da sagen wir mal nix gelle ? ;-)

[grenzgaenger]

sehe grad, dass delphi einen eigenen BCD datentyp mit an board hat :-)

Delphi-Quellcode:

TBcd

[grenzgaenger]

Zitat:

Zitat von Der.Kaktus

Zitat:

Zitat von grenzgaenger

Zitat:

Zitat von Der.Kaktus

haste kein Vertrauen zur primitivsten Version? *sfg* s.o.

denke, das hat nix mit vertrauen zu tun, so lange er keinen datentyp nimmt, welcher keine rundungsfehler erzeugt, wird er immer probleme haben. nicht umsonnst sollte man die floats vermeiden... ;-)

na da sagen wir mal nix gelle ? ;-)

wenn juergen das für sich privat macht, ist das in ordnung. wenn allerdings kunden sein programm nehmen sollen, wird es ihm irgendwann um die ohren fliegen, wenn er mit groben approximationen arbeitet, wie im vorliegenden post... aber man gönt sich ja sonst nix ... :-)

[Der.Kaktus]

@grenzgaenger

Jep, son Rechnungslegungsprogramm, was net richtig rundet, kommt net so gut beim Kunden.*fg*

[bit4bit]

Grundsätzlich würde ich das ursprüngliche Problem so lösen :

Delphi-Quellcode:

xr := trunc(x * 20 + 5) / 20

Dein Anwendungsfall muss aber IMHO anders gelöst werden!

Laut Gesetz ...

BUrlG § 5 Teilurlaub

Absatz 2 : Bruchteile von Urlaubstagen, die mindestens einen halben Tag ergeben, sind auf volle Urlaubstage aufzurunden.

... werden also Werte von x,5 bis x,999999... auf x+1 aufgerundet !

Von kaufmännischem Runden ( schon gar nicht auf halbe Tage ) steht da nix.

Man kann dem Arbeitnehmer natürlich mehr Urlaub geben als ihm eigentlich zusteht, wenn z.B. einen Anspruch von x,000000001 bis x,499999... auf x,5 aufgerundet würde:

Delphi-Quellcode:

xr := trunc(x * 20 + 9) / 20

Gesetzlich müsste man tatsächlich z.B. nur 0,1 Tage Urlaub gewähren *lol*

Übrigens: Dein Beispiel mit dem 15. Mai ergibt nur einen Urlaubsanspruch von 16,333... Tagen und nicht 17,672131147541 Tage , weil angebrochene Monate nicht zählen!

[juergen]

@ bit4bit,
8)
Für deine Beispiele hast du Recht.
Da mein "Urlaubsrechner" aber nicht nur für Angestellte/ Beamte gelten soll, sondern vorwiegend im industriellen Bereich, musste ich alle möglichen Varianten abdecken...
Zur Veranschaulichung habe ich das Programm mal angehängt.

Ps.:
Angewandtes Tarifrecht...
Es ist erstaunlich wieviel Spielraum/ Interpretation Gesetzestext in der Praxis so zulässt.