Moin,

ich hätte gern mal ein paar Denkstöße. Vielleicht überseh ich eine einfache Möglichkeit.

Ich habe eine Tabelle mit Einheiten und eine Tabelle mit Umrechnungfaktoren.
In den Faktoren steht natürlich drin, wie ich eine Einheit in eine andere umrechnet. Also nur 3 Felder:




heißt in diesem Beispiel 1 Meter * 1000 = 1 KM

Nun muss ich eine Funktion schreiben der ich einen Wert, eine Starteinheit und eine Endeinheit übergebe. Diese Funktion rechnet den Wert also in die Endheit um.
Nun hab ich ja für die Umrechnung z.B. von cm in KM keine "direkte" Umrechnung. Ich muss also einen Zwischenschritt rechnen: cm -> Meter -> Kilometer.
Allerdings hab ich ja für diese Umrechnung noch einen weiteren möglichen Weg: cm -> Dezimeter -> Meter -> Kilometer.
Beide führen zum selben Ergebnis.
Es könnte auch sein, dass die größere Einheit links steht. Dann wäre der Faktor z.B. 0,001. Macht es natürlich nochmal schwerer, weil es 2 Wege gibt.

Meine Frage nun:
Wie finde ich einen Weg von Einheit A nach Einheit B. Es könnte ja auch in Sackgassen enden (wenn z.B. der Schritt von Dezimeter nach Meter nicht vorhanden wäre, würde die Umrechnung von cm in Dezimeter in einer Sackgasse enden, weil ich dort nicht weiter komme).
Ob der Weg optimal ist, ist an der Stelle vermutlich egal. Denn die Wegfindung wird um ein vielfaches länger dauern, als die Umrechnung an sich.

Ich hab dabei an einen A* gedacht. Aber schieße ich da nicht mit Kanonen auf Spatzen? Gibts einen einfacheren Weg?

Gruß,
Jens

Hallo Nersgatt,

da du quasi einen (ungerichteten) Graphen hast, kannst du einfach den Dijkstra-Algorithmus nehmen. Für A* bräuchtest du ja eine Heuristik (bzw. ohne Angabe einer Heuristik wärst du wieder beim Dijkstra-Algorithmus).
Beachte, daß dann deine Kantenkosten aber jeweils nur 1 sind (deine Faktoren spielen ja für den kürzesten Weg keine Rolle).

P.S. Wenn du eine konstante Tabelle hast und sehr oft umrechnen mußt, dann würde ich vorhandene Umrechnungen als Weg cachen, damit du nicht immer wieder die Wegsuche durchführen mußt.

Danke Dir, das sieht sehr gut aus. Ich denke, das ist das, was ich suche.
Wie oft Umrechnungen vorkommen, weiß ich ehrlichgesagt noch nicht. Ich werde das aber sowieso in einer Klasse kapseln, so dass ich da auch noch später eine Möglichkeit zum cachen nachschieben kann, wenn sich das als Flaschenhals erweisen sollte.

Ist das nicht ein bischen übertrieben für so eine billige Umrechnung?
Nimm doch einfach die Faktoren in Beziehung zum Meter (=1), also km = 1000, mm = 0.001 und rechne Faktor(Ausgangsgröße) / Faktor(Zielgröße)
-> z.B. km in mm -> 1000 / 0.001 = 1 000 000 (1 km = 1 000 000 mm) mm in dm -> 0.001 / 0.1 = 0.01 (1 mm = 0.01 dm) u.s.w. ...

Das Problem ist, dass ich nicht weiß, welche Einheiten es geben wird. Die kann der Benutzer selbst pflegen. Bzw. werden die Einheiten teilweise aus einer "fremden" Datenquelle importiert und der Benutzer muss dann noch die Umrechnungen nachpflegen.
Und dabei gehts nicht nur um Stecken, sondern auch z.B. Flächen, Masse, Volumen, etc.

Mit einer festen Größe, auf die sich alle anderen Einheiten beziehen, und den dazugehörigen Umrechnungsfaktoren, sollte das meiner Meinung nach überall funktionieren...
von mir aus auch mit Zentner ( wenn 1 Zentner = 1 -> 1 kg = 0.02 ... Berechnung Zentner in kg -> 1 / 0.02 = 50 -> 1 Zentner = 50 kg )

Wenn du dann allerdings € in $ umrechnen willst und dafür als Basis Meter brauchst...

In meiner Anwednung hab ich so ca 200 Einheiten, wobei die ebenfalls die User selbst anlegen können. Die Einheitenumrechnung brauch ich in zig Masken, teilweise kann der User sogar pro Ds wählen, in welcher Einheit er was sehen will (z.b. Stammdaten sagt Einheit ist KG, er will %, FXU, nmol/100ml, i.E. oder weiss der Geier was sehen).
Dazu hab ich eine Tabelle mit Einheiten (ID, Bez) + eine mit Einheitenumrechnungsfaktoren,
die genau deinem Muster entspricht (IDVon, IDAuf, Wert).
Desweiteren gibts eine kleine Maske, in der die User den Umrechnungsfaktor selbst angeben können (Standard-Einheitsumrechnungen werden natürlich vorbelegt ausgeliefert)
In der Maske gibts 2 Comboboxen (EinheitVon, EinheitAuf) und ein Eingabefeld für den Faktor sowie ein Grid zur Anzeige.

dreht man an den comboboxen, springt die Anzeige immer auf den richtigen DS (ID's der Einheiten liegen im Object der Items), umgerechnet wird z.Teil auch automatisch (kg > g = 1000, dann kann man g > kg auch automatisch setzen ). Alle kleineren 'Schmankerl' verrat ich aber nicht

Eine kleine Funktion in meiner 'Utils'-Unit gibt mir immer den Umrechnungsfaktor zu 2 Einheiten (default = 0), so das ich im Programm immer nur sage:
Faktor := gibUmrechnungsfaktor(EinheitenId1, EinheitenId2);
und kann immer einfach mit dem Faktor rechnen.

Fahre damit seit Jahren sehr gut, wenn's mal rechenfehler gibt, liegts zu 99% daran, das der User nen falschen Umrechnungsfaktor eingegeben hat. Und so kann ich auch ... hmmm .. 'kundenspezifische Umrechnungsfaktoren' nutzen, da kann aus nem Euro auch mal 132 Cent werden

fällt mir gerade ein:
ich bau noch nen Feld 'Kundenwert' in die Umrechnungstabelle ein, so kann ich vergleichen, ob der Kunde meine oder seine Werte nutzt. Zeige ihm dann immer nur seine,
nutze in der Logik immer seine, wenn nicht da, meine, wenn nicht da 0;

Ich machs 'händisch', da mir die Algorithmen aufgrund der 'kundenspezifische Umrechnungsfaktoren' zu steif oder aufwändig sind. So bleib ich flexibler und kann den User jeden 'Mist' machen lassen, ohne mein Programm anpassen zu müssen.

My 2 Cents ;

Zuma

baka0815 hat folgendes geschrieben :

Wenn du dann allerdings € in $ umrechnen willst und dafür als Basis Meter brauchst...

...dann geht das auch -> 1 Euro = 3 Meter, 1 Dollar = 2 Meter -> Euro in Dollar : 3/2 = 1.50 , also 1 Euro = 1,50 Dollar (und Meter kürzt sich raus)

Alles klar. Du übernimmst dann die Hotline und erklärst DAS den Kunden.

Mach ich tagtäglich
Ja, nee, man sollte schon für jede Größe/Umrechnung eine eigene Basis haben, das erleichtert die Sache jedenfalls ungemein aber prinzipiell ist alles möglich ...

Die übliche Variante wäre wirklich, nur eine Hand voll Umrechnungsfaktoren in Richtung einer Basis (SI-Einheiten bieten sich an) zu nehmen. Macht Delphi glaub ich auch so.



Dann besteht eine Umrechnung nur aus Wert * Quelleinheit / Zieleinheit.

Damit kommen meine Kunden nicht klar. Die rechnen in so komischen Einheiten wie Doppelzentner. Vielleicht wissen sie noch, dass das 2 Zentner sind. Und 1 Zentner sind 2 Sack....
Aber wenn man fragt "und wie viel Kilo sind das", dann machen sie ein langes Gesicht. Ist halt leider so.

Aber an den Umrechnungsfaktoren kommst du doch so oder so nicht vorbei... ?
Und selbst, wenn du Zentner als Basis hättest...
Zentner = 1
Doppelzentner = 2
Sack = 0.5
Umrechnung Doppelzentner in Säcke: 2 / 0.5 = 4 , also 1 Doppelzentner = 4 Säcke ...
Was ist daran so schwer zu verstehen?
Und der schlaue Delphi-Programmierer könnt's dann sogar noch in kg umrechnen
Aber wenn nicht mal deine Kunden die Umrechnungsfaktoren wissen, wie willst du's dann machen??

buster hat folgendes geschrieben :

Was ist daran so schwer zu verstehen?

Genau das frage ich mich auch täglich.
Meine Kunden sind kein EDV-Leute. Das sind auch keine Büromenschen. Die habens oft mit der Mathematik nicht so, wenn es das Niveau der 4. Klasse übersteigt. Was aber keinesfalls heißt, dass das bei allen meinen Kunden so ist. Nur ich muss diese Leute "mit einplanen".

Ne, an den Faktoren komm ich nicht vorbei, das ist klar. Es geht darum, dass ich den Kunden nicht erklären kann, dass sie alle Masseeinheiten z.B. in KG umrechnen müssen. Die können das höchstens in die "nächste" Einheit umrechnen. Daher ist es für mich die beste Lösung, ihn wirklich die Faktoren zwischen den Einheiten angeben zu lassen, die er weiß.

Dann wirst du wohl in den sauren Apfel beißen müssen... Oder du bietest das den Kunden als besonderen Service an, (gegen Aufschlag, versteht sich), ihre Umrechnungstabellen zu befüllen wiki hilft da gerne weiter

Nersgatt,
ich hab das gleiche Problem:
Vom Wissenschaftler bis zum Lkw-Fahrer als User,
die einen können dir die Umrechnungsfaktoren für die exotischten Einheiten aus dem Stand sagen, während die anderen bei der Frage nach Umrechnungsfaktor dich anschauen, als hättest du gerade Gotteslästerung betrieben oder sowas

Wir pflegen selber eine Basis in der wir alle 'neuen' faktoren der Kunden sammeln und aktualisieren die Tabellen beim Kunden dann beim nächsten Update automatisch (Falls Wert nicht vom Kunden eingegeben).

Alles andere lässt einen irgendwann verzweifeln, denn jeden intelligenten Programmierer kannste mit genug dummen Usern in den Wahnsinn treiben sagt meine Erfahrung

Zuma

Um zum algorithmischen Teil zurückzukommen: Single-Source kürzeste Wege in einem ungewichteten Graphen sucht man weder mit A* noch Dijkstra, sondern mit Breitensuche .
Wenn die Tabelle auch editiert werden kann, wäre das auf jeden Fall einfacher (und sicher performant genug), als Umrechnungsfaktoren zu einer (beliebig gewählten) Basiseinheit zu cachen (was ja für den Nutzer vollkommen transparent möglich wäre) (ich mag Klammern).