Algorithmus für Matrizenberechnung

[Exceptionfault]

Guten morgen,

ich habe ein kleines mathematisches Problem an dem ich schon 3 Tage rumrechne. Es geht um eine zweidimensionale Matrix, die ich gerne ausgleichen möchte.

Man stelle sich vor, ich habe eine variable Anzahl von Konten. Jedes Konto setzt sich aus 12 Monatswerten zusammen und ergibt daraus einen Jahresgesamtwert.
Weiterhin sind 12 Monatswerte gegeben, die eine Summe der entsprechenden Monate
über alle Konten ergeben.

Es sind jeweils die Summen gegeben, die Monatswerte müssen errechnet werden.

         Sum    Jan  Feb  Mrz  Apr  Mai  Jun  Aug  
+------+-------------------------------------------+
|KTO 1 |  100      ?    ?    ?    ?    ?    ?    ? |
|KTO 2 |  200      ?    ?    ?    ?    ?    ?    ? |
|KTO 3 |  300      ?    ?    ?    ?    ?    ?    ? |
|KTO 4 |  400      ?    ?    ?    ?    ?    ?    ? |
+------+-------------------------------------------+
 SUM     1000    100  200  100  100  100  200  200

Erster Ansatz:
1.) Anteil Jan(Gesamt) zu Gesamt(Gesamt) ermitteln
2.) Errechneter Anteil von KTO1(Gesamt) auf KTO1(Jan) schreiben
3.) etc...

Aufgetretenes Problem waren Rundungsdifferenzen. Es gelang nur die Rundungsdifferenzen entweder horizontal, oder vertikal auszugleichen, nie beides.

Nächste Herausforderung ist die Änderung eines KTO Wertes(Gesamt) und eine Umverteilung unter der Annahme dass alle Monatssummen bis z.B. April fix sind, und ab April geändert werden dürfen.

Hat jemand eine Idee für einen Algorithmus ?

 

[Thomas Darimont]

Hallo!

Also fuer dein Angegebenes Problem habe ich mal schnell eine moegliche Loesung durchgerechnet:

 	Sum	Jan 		Feb 		Mrz 		 Apr 	 		Mai 		 Jun 	 		Aug
 KTO1	100 26.42857130714230000000 58.57142834285720000000	-19.99999958571400000000 -1.42857155714267000000	-20.71428629285710000000 28.57142889285710000000	28.57142889285710000000
 KTO2	200 10.23809556428600000000 32.85714288571430000000 25.71428552857140000000 19.52380918571430000000 25.95238076428570000000 42.85714303571410000000	42.85714303571430000000
 KTO3	300 24.52380985000010000000 47.14285717142860000000 39.99999981428570000000 33.80952347142850000000 40.23809505000000000000 57.14285732142850000000	57.14285732142850000000
 KTO4	400 38.80952327857150000000 61.42857160000000000000 54.28571424285690000000 48.09523889999990000000 54.52381047857140000000 71.42857075000020000000	71.42857075000010000000
 	1000	100 		200 		100 		 100 	 		100 		 200 	 		200

Wobei ich auch Rundungsdifferenzen bekommen habe. Ich denke ganz ohne Rundungsdifferenzen laesst sich solch eine Sache nicht loesen. Aber da das ganze sicherlich eher zu Auswertungszwecken in Form eines Berichts fuers Datawarehousing verwendet wird denke ich, dass es kein Problem ist, wenn da mal ne Abweichung von 0.00000001 % drinnen ist

Einfach gleichungsystem aufstellen und entsprechende Nebenbedingungen formulieren und dann ein beliebiges Tool zur Loesung des LG Systems heranziehen...

 		 Sum    Jan  Feb  Mrz  Apr  Mai  Jun  Aug  
 +------+-------------------------------------------+
 |KTO 1 |  100	  ?    ?	?	?    ?	?	? |
 |KTO 2 |  200	  ?    ?	?	?    ?	?	? |
 |KTO 3 |  300	  ?    ?	?	?    ?	?	? |
 |KTO 4 |  400	  ?    ?	?	?    ?	?	? |
 +------+-------------------------------------------+
  SUM	 1000	100  200  100  100  100  200  200
 
 Jan=a 
 Feb=b
 Mrz=c
 Apr=d
 Mai=e
 Jun=f
 Aug=g
 
 100 = a1 + a2 + a3 + a4
 200 = b1 + b2 + b3 + b4
 100 = c1 + c2 + c3 + c4
 100 = d1 + d2 + d3 + d4
 100 = e1 + e2 + e3 + e4
 200 = f1 + f2 + f3 + f4
 200 = g1 + g2 + g3 + g4
 
 100 = a1 + b1 + c1 + d1 + e1 + f1 + g1
 200 = a2 + b2 + c2 + d2 + e2 + f2 + g2
 300 = a3 + b3 + c3 + d3 + e3 + f3 + g3
 400 = a4 + b4 + c4 + d4 + e4 + f4 + g4
 
 1000 = a1 + b1 + c1 + d1 + e1 + f1 + g1 + a2 + b2 + c2 + d2 + e2 + f2 + g2 +a3 + b3 + c3 + d3 + e3 + f3 + g3 +a4 + b4 + c4 + d4 + e4 + f4 + g4
 
 Da ich davon ausgehe, dass ein Monatswert auch negative Haben kann braucht man
 keine nicht negativitaets Bedingungen.

Das ist zwar der Brute Force Ansatz, aber wenns funktioniert...

Gruss Tom

 

[Exceptionfault]

Danke für deine Mühe. Mittlerweile hab ich sogar einen kleinen Algorithmus zusammenbekommen der ein Näherungsverfahren darstellt (in PL/SQL) um die Rundungsdifferenzen möglichst klein zu halten. Da es leider nicht um DataWarehousing geht, sondern um Bilanzplanung kann ich die Monatswerte nicht mit 24 Nachkommastellen darstellen, sondern nur mit 2 ;-) und dann passt eben nix mehr so wirklich.

Naja, mal schaun ob den Usern so passt, zumal der zugehörige Bericht wirklich in T€ od. höher rauskommt...