VRUNDEN() in RPG

[Fuerchau]

Noch mal komplett:

eval faktor = %int(Wert:Rundung);

select;
when faktor * rundung = wert;
neuerwert = wert;
when wert > *zero;
neuerWert = (faktor + 1) * rundung;
other;
neuerwert = (faktor - 1) * rundung;
endsl;

7,5 / 5 = 1
when 1 * 5 = 7,5 => 7,5
when 7,5 > 0 => (1+1) * 5 = 10
other => (1-1) * 5 = 0

-7,5 / 5 = -1
when -1 * 5 = -7,5 => -7,5
when -7,5 > 0 => (-1+1) * 5 = 0
other => (-1-1) * 5 = -10

Das ganze dann in eine schöne Funktion "VRunden" gepackt.

[itec01]

sorry das kann nicht richtig sein.
Bei einem Wert von 7,5 und einer Rundung muss 10 als Ergebnis kommen. Bei einem Wert von z.B.: bei 7,49 muss 5 kommen, weil 7,49 näher an 5 ist als an 10.
Ich mache es jetzt anders:
Wert = 7,5
Rundung = 5
Do x

if (x * 5) > 7,49
if %abs((x*5)-7,49) < %abs(((x-1)*5)-7,49)
eval Ergebnis = (x-1)*5
else
eval Ergebnis = x*5
EndIf
EndIf
x =+
Enddo

Bei einem minus Input Value muss es umgekehrt geprüft werden.
Ich packe das mal in eine Funktion.

[B.Hauser]

Einfach: Dividieren, Runden und danach multiplizieren

Ich hab's jetzt hier nur mit SQL ... aber in RPG sollte es genauso funktionieren:

Values(Round(7,4 / 5,0 , 0) * 5);
Values(Round(7,5 / 5,0 , 0) * 5);
Values(Round(7,6 / 5,0 , 0) * 5);

Liefert: 5, 10, 10

[itec01]

Oh mein Gott, wie einfach. Super, vielen Dank.

[Fuerchau]

Dann gehts auch mit RPG:

%dech(7,4 / 5,0 : 11 : 0) * 5,0

[camouflage]

Ich fass es nicht. Dieser Meccano ist doch seit S/34 Zeiten bekannt. Klar, wir müssen hier natürlich auch mit 5er Rundungen leben. Mit ensprechendem Multiplikator und Divisor funktioniert das in allen Schattierungen bis man lustig ist. Mal schauen ob das die KI auch weiss.

[Fuerchau]

Meine 1. Lösung war mal gedacht zum generellen Aufrunden.
Z.B. bei Preiskalulationen auf die nächste schöne Zahl hochrunden, z.B. auf 0,25 oder 2,50 oder bei großen Werten auch gerne af 250 oder 500.
Dabei sollte eben nicht gerundet werden, wenn das Ergebnis bereits passte.
Negative Werte wurden auch aufgerundet, also von -1,20 auf -1,00, um z.B. bei Rechnungen einen höheren Wert als bei Gutschriften zu haben. Das Wertrisiko liegt da beim Kunden.

Interessant ist, dass man für alles und jedes nun SQL nehmen soll;-).

[B.Hauser]

Meine 1. Lösung war mal gedacht zum generellen Aufrunden.
Z.B. bei Preiskalulationen auf die nächste schöne Zahl hochrunden, z.B. auf 0,25 oder 2,50 oder bei großen Werten auch gerne af 250 oder 500.
Dabei sollte eben nicht gerundet werden, wenn das Ergebnis bereits passte.
Negative Werte wurden auch aufgerundet, also von -1,20 auf -1,00, um z.B. bei Rechnungen einen höheren Wert als bei Gutschriften zu haben. Das Wertrisiko liegt da beim Kunden.

Interessant ist, dass man für alles und jedes nun SQL nehmen soll;-).

Das war aber nicht gefragt!
... und wenn, warum sollte man sich in RPG die Fingerchen brechen wenn es in SQL die Funktion CEILING gibt. Diese kann man dann in RPG einbinden genauso mit Division und Multiplikation einsetzen.

[camouflage]

Das war aber nicht gefragt!
... und wenn, warum sollte man sich in RPG die Fingerchen brechen wenn es in SQL die Funktion CEILING gibt. Diese kann man dann in RPG einbinden genauso mit Division und Multiplikation einsetzen.

Birgitta, ich versteh es ja, du verdienst dir mit deiner SQL Kompetenz deine Brötchen. Nur, warum soll ich mir einen SQL Overhead antun, wenn es mit zwei simplen RPG Statements auch geht und das Ganze sogar noch nachhaltiger ist. SQL ist auch nicht immer der letzte Schrei.

[Fuerchau]

Ceiling => %dech(val + 0.49 : 11 : 0)
Floor => %dec(val : 11 : 0)

Meinst du SQL macht da was anderes?

[camouflage]

Und ganz vermessen, wenn man ChatGPT nach der SQL Rundung frägt:

SELECT Wert, ROUND(Wert * 2, 0) / 2 AS GerundeterWert
FROM MeineTabelle;

oder so:
SELECT ROUND(12.345 * 2, 0) / 2 AS GerundeteZahl from sysibm.sysdummy1

Merke, das in Deutsch und funktioniert auch noch.