kaufmännisch auf 0,5 oder 1 runden

[grenzgaenger]

Zitat:

Zitat von juergen

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

alles was den mitarbeiter nicht schlechter stellt, als das gesetz, ist erlaubt. sofern ich das noch recht in erinnerung habe :-)

solltest aber dennoch gucken, dass du deinen auftraggeber nicht, aufgrund eigenwilliger stundenrundung, verärgerst. auch wenn es zum vorteil gereicht, irgendjemand fühlt sich sicherlich auf die füsse getreten und macht stress. von daher, gilt der tip nach wie vor, lieber vorher runden, z.b. alles in dezimalminuten eingeben lassen oder in zeitminuten und sich das anschliessend bestätigen lassen. aufgrund der bestätigten daten, wird dann ohne rundung weitergerechnet. dann kann sich niemand beschweren, dass es anschliessend nicht passt :-)

denke, die manuelle rundungsmethode (mit trunc...) habe ich vorhin genügend ausgeführt, so dass du auch die exotischsten rundungen problemlos hinbekommst. wenn deine zeit sekundengenau sein sollen, siehe dir doch mal das unix datetime format an... ansonsten kannst du ja problemlos 'n einges kreieren auf der basis deiner kleinsten zu berücksichtigten zeiteinheit... denke longint oder int64 sollten eigentlich reichen... sonst der currency typ :-)

viel erfolg GG

[juergen]

Hallo grenzgaenger,
naja, die Aufgabenstellung war in diesem Fall eindeutig:
- alles bezieht sich nur auf Tage. Ergebisse immer in ganze Tage oder halbe Tage (je nach Firma).
Mein Problem war ja, die Personalsachbearbeiterin rechnet mit dem Taschenrechner nach und erhält ein
ganz einfaches Ergebnis -> z.B. 12,25. Das soll dann auf 12,5 gerundet werden.
Da wurde in meinem Fall durch die verwendeten Datentypen "falsch" gerechnet. Die jetzige Ungenauigkeit (16 Stellen hinter dem Komma) kann man aber in meienm Fall vernachlässigen, Ergebnis soll ja immer nur halbe oder ganze Tage sein.

Es gibt bei einigen Firmen auch noch die Urlaubbsberechnungen in Stunden:Minuten (allerdings ziemlich selten).
Hierfür hätte ich was in petto, weil ich mich schon mal ausführlich mit Stunden- und Minutenberechnungen auseinander gesetzt hatte.
Dort verwende ich auschließlich Integer als Basis (2:30 Std = Integerwert von 150).

Deine Erläuterungen zur Trunc-Funktion/Berechnung waren übrigens sehr gut!

Gute Nacht!

[alzaimar]

So ist es allgemein:

Delphi-Quellcode:

Function RoundToGranularity(aValue, aGranularity: Double): Double;
Begin
  Result := Trunc(aValue / aGranularity + 0.5 + 1E-10) * aGranularity
End;

In deinem Fall ist 'aGranularity' = 0.50.

Die Ergebnisse sind zwar (weil Floating-Point) nicht genau, aber die Darstellungsfehler in der 15.ten Stelle sind irrelevant, weil Du ja formatiert ausgibst. Dafür kannst Du dann in Ruhe mit den Werten rechnen. Die Rundungsfehler schaukeln sich nur bei extremen Werten und/oder langen Iterationen langsam hoch.

Wichtig ist hier die formatierte Ausgabe auf eine Nachkommastelle, aber das sollte man ohnehin machen.

Zitat:

Zitat von grenzgaenger

nicht umsonnst sollte man die floats vermeiden... ;-)

Äh.. nö. Man muss nur bei der Ausgabe etwas aufpassen. Floating Point Arithmetik ist nunmal um ein Vielfaches schneller und wird deshalb verwendet. Und Rundungsfehler gibt es auch bei BCD, nur keine Darstellungsfehler.

[QuickAndDirty]

Zitat:

Zitat von juergen

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

OHH JA. Ich mache seit 5 Jahren hier an der Entwicklung Zeiterfassung mit....trotz Flächentarifvertrgägen
und gesetzten gibt es keine 2 Firmen mit den selben Zeitmodellen....aber jede kommt und sagt:
"Wie das muss man einstellen? Das ist doch Tarif standard!" (Von wegen....)
Deswegen haben wir seit 12 Jahren einen Makrointerpreter und zig Makro Einsprungpunkte falls mal "ab und zu"
jemand "seltsame" Regelungen umgesetzt braucht.



@alzeimer:
Wenn du zwei große Floats von einander abziehst kann schon im ersten
Schritt ein echt interessantes Ergebnis bei rauskommen.

[alzaimar]

Zitat:

Zitat von QuickAndDirty

Wenn du zwei große Floats von einander abziehst kann schon im ersten Schritt ein echt interessantes Ergebnis bei rauskommen.

:gruebel: Was soll daran interessant sein (klappt übrigens auch schon mit zwei kleinen Zahlen, z.B. 0.1)? Das ist dann aber ein Darstellungsfehler. Der Rundungsfehler liegt immer innerhalb der Spezifikation für Floating Points (8-20 Stellen, je nach verwendetem Datentyp). Wir wollen hier nicht über die Eigenheiten von Floatingpointarithmetik und -Darstellung diskutieren (das wurde hier schon bis zum Erbrechen durchgekaut), aber wenn man weiss,
1. wo die Darstellungsfehler herkommen
2. was man überhaupt ausrechnet und
3. welche Genauigkeit man benötigt,
dann kann man Floatingpointarithmetik bestimmungsgemäß und fehlerfrei verwenden. Wer die o.g. Punkte nicht richtig zu beantworten weiss, der muss zur Nachhilfe: Was interessieren mich Fehler in der 10 Stelle, wenn ich -im physikalischen Umfeld- nie mehr als 8 signifikante Stellen anzeigen muss (Ein Fehler von 0,00001%, das ist kleiner als fast jede Messeinrichtung).

Im hier diskutierten Fall liegt die benötigte Genauigkeit bei genau einer Dezimalstelle bzw. 3-6 signifikanten Stellen. Und *das* schafft ein Double mit links, hier würde sogar ein Single ausreichen.

Nicht verwechseln: Rundungsfehler und Darstellungsfehler. Ersteres kommt bei Computerrechnungen im Zahlenraum der reelen Zahlen doch öfter vor, letzteres ist eine Eigenheit der Floatingpoint-Datentypen.