Collections TreeSet beinhaltet Objektleichen

[Kubus]

Hallo zusammen!

Ich habe folgendes Problem: Ich füge eine Reihe von Objekten in ein TreeSet ein. Diese Objekte verändern sich während der kompletten Laufzeit nicht, alle Felder sind final. Allerdings nimmt der verwendete Comparator einen Wert aus einer anderen Klasse, multipliziert diesen mit zwei Feldern der Objekte und ermittelt somit welches von beiden größer ist. Dafür hat der Comparator eigens eine Klassenvariable mitbekommen, die entsprechend geupdatet wird.

Leider befinden sich nach einigen Iterationen aber Datenleichen im Set, dh. Objekte sind doppelt vorhanden. Dies stört den weitern Ablauf meines Programms.

Es wird wahrscheinlich daran liegen, dass die entsprechenden Objekte nun nach Meinung des Sets nicht mehr gleich sind, da die berechneten Werte ja nicht übereinstimmen. Hat jemand eine Idee wie ich dies möglichst effizient umgehen könnte? Bislang filtere ich das Set per Hand nach indem ich alles entferne, prüfe und dann neu einfüge. Dies ist aber natürlich mit Laufzeiteinbußen verbunden.

Minimalbeispiel Comparator:

private class COComparator implements Comparator<CompObject> 
{		
     private double x;
	    
     public int compare(CompObject first, CompObject second) 
     {
           double resFirst = first.field()*x;
           double resSecond = second.field()*x;
           if(resFirst == resSecond)
                return 0;
           else
                return (resFirst < resSecond) ? -1 : 1;
     }

}

 

[Ariol]

Da musst du wohl Debuggen.

Könntest du ein KSKB posten, damit man den Fehler nachvollziehen kann?

 

[nillehammer]

1.)Nach Einfügen in ein normales Set dürfen sich die Werte, die für die equals()-Methode herangezogen werden, nicht mehr ändern.
2.)Nach Einfügen in ein SortedSet dürfen sich die Werte, die für equals() herangezogen werden nicht mehr ändern und zusätzlich die, die für compareTo() oder compare() herangezogen werden.
3.)Zusätzlich müssen bei SortedSets equals() und compare-Methoden konsistent sein, d.h. wenn equals true ist muss compare 0 sein bzw, wenn equals false ist, must compare != 0 sein.

Wenn Du trotz der Änderung deiner Comparatoren mindestens die Punkte 1 und 3 gewährleisten kannst, könnte der Aufruf von Collections.sort() nach Änderung des Wertes im Comparator Deine Lösung sein. Eine Inkonsistenz zwischen compare und equals ist unbedingt zu vermeiden.

Leider befinden sich nach einigen Iterationen aber Datenleichen im Set, dh. Objekte sind doppelt vorhanden. Dies stört den weitern Ablauf meines Programms.

Das ist die Folge von inkonsistentem equals und compare. TreeSets benutzen nämlich compare zur Feststellung, ob ein Objekt schon vorhanden ist. Wenn compare != 0 zurück liefert denkt es ok, rein damit. Blöd, wenn equals trotzdem true zurück liefert.

 

[Kubus]

KSKB ist auf die Schnelle schlecht, werd aber nachher versuchen was zusammenzuschustern.

Was das equals()-angeht: So weit kommt er noch nicht mal. Der Comparator vergleicht equals vor allem anderen unabhängig von x; nur die größer-kleiner Relationen sind von x abhängig. Aber leider bricht das TreeSet die Suche für remove() frühzeitig ab, und zwar nachdem ein Wert gefunden wurde der größer als der gesuchte ist (laut Comparator) und einer der kleiner ist. Ablauf ist lauf Debugger in etwa so:

- Ist Wert 'a' gleich 'gesucht'? Nein
- Ist Wert 'a' kleiner / größer 'gesucht'? Kleiner
- Ist Wert 'b' gleich 'gesucht'? Nein ('b' > 'a')
- Ist Wert 'b' kleiner / größer 'gesucht'? Größer

Somit denkt das Set, der Wert sollte zwischen den beiden anderen liegen, da ist aber nichts, deswegen gibt es false zurück. Der gesuchte Wert würde in dem Falle allerdings über dem Wert 'b' liegen, laut dem mittels x berechneten Wert.

 

[Marco13]

Kleiner Einschub zu deinem Comparator: Erstens ist nicht klar, wo der Wert "x" herkommt, und was er bedeuten soll: Der Vergleich von A und B sollte IMMER das gleiche liefern, wie der Vergleich von A*x und B*x (außer für x=0, dann ist das aber sowieso alles kaputt...).

Ansonsten kann den return-Wert einfacher bestimmen als
return Double.compare(first.field()*x, second.field()*x);
was wie andedeutet das gleiche sein sollte wie
return Double.compare(first.field(), second.field());

 

[nillehammer]

Was das equals()-angeht: So weit kommt er noch nicht mal.

Ja genau, hab ich ja auch geschrieben:

TreeSets benutzen nämlich compare zur Feststellung, ob ein Objekt schon vorhanden ist.

Wie gesagt, Du musst die Voraussetzungen beachten und immer, nachdem Dein Comparator sich ändert, ein Collections.sort machen. D.h. Deine Komparatoren müssen sich von Dir kontrolliert ändern. Wenn sie sich zu jedem beliebigen Zeitpunkt ändern und Du das nicht mit bekommst, hast Du verloren.

 

[Kubus]

Kleiner Einschub zu deinem Comparator: Erstens ist nicht klar, wo der Wert "x" herkommt, und was er bedeuten soll: Der Vergleich von A und B sollte IMMER das gleiche liefern, wie der Vergleich von A*x und B*x (außer für x=0, dann ist das aber sowieso alles kaputt...).

Ansonsten kann den return-Wert einfacher bestimmen als
return Double.compare(first.field()*x, second.field()*x);
was wie andedeutet das gleiche sein sollte wie
return Double.compare(first.field(), second.field());

Der Wert ist die x-Koordinate in einem 2-Dimensionalen Raum. Die beiden Objekte die verglichen werden sind geraden. x wird in beide Geradengleichungen eingesetzt und damit deren Reihenfolge bestimmt. Aber soweit ich mich nicht irre bedeutet A < B sowieso nicht automatisch A*x < B*x, das hängt von den Vorzeichen der Werte ab (A & B fix, x variabel).

Wie gesagt, Du musst die Voraussetzungen beachten und immer, nachdem Dein Comparator sich ändert, ein Collections.sort machen. D.h. Deine Komparatoren müssen sich von Dir kontrolliert ändern. Wenn sie sich zu jedem beliebigen Zeitpunkt ändern und Du das nicht mit bekommst, hast Du verloren.

Hatte ich nicht überlesen, keine Sorge^^ Aber Collections.sort() ist für Listen. Ich habe ein TreeSet, kann es also nicht benutzen. Ich bekomme mit wenn der Comparator sich ändert, muss dort allerdings aus dem alten TreeSet ein neues machen um die Sortierung wiederherzustellen, was natürlich schon ein wenig an der Performance nagt :/

 

[nillehammer]

ber Collections.sort() ist für Listen. Ich habe ein TreeSet, kann es also nicht benutzen.

Wie peinlich! Stimmt natürlich! Beim TreeSet sollte man das ja nicht benötigen, weil es immer sortiert ist. Keine Ahnung, was ich mir dabei gedacht habe. Werd mal schnell meine ganzen Posts editieren, damit es keiner merkt...

 

[Marco13]

Dass sich die Reihenfolge bei negativem x umdreht ist klar, aber wenn sich das Vorzeichen mittendrin ändert ist die Sortierung ja genauso kaputt wie bei x=0. Vielleicht solltest du das ganze mal auf "höherer" Ebene beschreiben, also nicht angefangen bei "Bei meiner TreeSet verusacht mein Comparator Objektleichen", sondern bei ~"Ich will Punkte sortieren ... ". Vielleicht findet man dann eine Lösung, evtl. auch mit einem komplett anderen Ansatz, je nachdem...

 

[Kubus]

Macht ja nicht, jeder überliest mal was

Was die Beschreibung auf höherer Ebene angeht: Ich habe eine vertikale Gerade die sich horizontal im Raum bewegt. Diese wird durch die x-Koordinate repräsentiert. Ich möchte nun für jedes x wissen in welcher Reihenfolge eine Menge an anderen Geraden die vertikale schneiden. Dafür setze ich das jeweils aktuelle x in die Gleichung der Geraden ein und bestimme somit das y der Schnittkoordinate. Nach diesen Koordinaten werden dann die Objekte in meinem TreeSet sortiert. Sollte sich an der Reihenfolge von zwei Geraden etwas ändern, so bekomme ich das auf jeden Fall mit. Das Problem ist nur, versuche ich nachdem ich weiß das die Reihenfolge sich ändert die jeweilige Gerade aus dem Set zu entfernen und neu einzufügen, so schlägt ersteres manchmal fehl und ich habe Objekte doppelt (aber an verschiedenen Stellen) im Set.

 

[Landei]

Wenn ich das richtig verstehe, ist das Problem ähnlich wie in einem 3D-Spiel (oder 2D in Draufsicht), wo abhängig von der Position des Spielers die Flächen/Kanten von "vorn" nach "hinten" geordnet werden müssen, um sie effizient rendern zu können. Ich kenne jetzt die Details nicht, aber wenn ich mich recht entsinne, ist dort die "übliche" Lösung ein BSP-Tree, der genau das ermöglicht.

 

[Kubus]

Sieht interessant aus, danke für den Tipp Landei, ich werde mich mal einlesen!

Habe jetzt nebenbei bemerkt eine Umgehungslösung eingebaut: Eine eigene Klasse die TreeSet erweitert und ihm eine HashMap hinzufügt. In dieser befindet sich die Gerade mitsamt der Koordinate mit der die sie zuletzt eingefügt wurde. Vor allen Operationen die auf eine konkretes Gerade zugreifen wird die aktuelle Koordinate im Comparator auf die gespeicherte gesetzt und anschließend wieder zurück. Die anderen Geraden bleiben dadurch unbeeinflusst. Nicht schön, verbraucht mehr Speicher und Rechenleistung, aber immer noch besser als alles in ein neues Set einzufügen :/

 

[Marco13]

Sollte sich an der Reihenfolge von zwei Geraden etwas ändern, so bekomme ich das auf jeden Fall mit. Das Problem ist nur, versuche ich nachdem ich weiß das die Reihenfolge sich ändert die jeweilige Gerade aus dem Set zu entfernen und neu einzufügen, so schlägt ersteres manchmal fehl und ich habe Objekte doppelt (aber an verschiedenen Stellen) im Set.

Wenn sich die Reihenfolge ändert, ist das TreeSet quasi in einem "ungültigen Zustand". Alle Operationen werden dann potentiell Unfug machen. WARUM (also, wodurch) ändert sich die Reihenfolge? Nur durch ein geändertes x?

 

[Kubus]

Genau, nur das x und die Geradengleichungen bedingen die Reihenfolge. Mein Umgehungsversuch ist leider ein 'dirty hack', aber ein anderer Weg will mir leider nicht einfallen :/

Zu den BSP-Bäumen: Die arbeiten für meine Bedürfnisse leider etwas zu langsam, ich brauche ca. O(log n) wie im TreeSet garantiert wird.

 

[nillehammer]

Hallo Kubus,
es lässt mich nicht los. Nur, dass ich Deinen Anwendungsfall richtig verstehe. Ich hab mal ein Bild gezeichnet (siehe Anhang geraden.jpg). Wenn ich Dich richtig verstanden habe, sind die grünen Geraden in dem Bild die Geraden, die Du in Deinem TreeSet speicherst. Die roten Geraden sind die, deren x-Koordinate sich ändert. Das Sortierkriterium für die grünen Geraden ist die y-Koordinate ihres Schnittpunkts mit der roten Geraden?

Und noch ne Frage, die grünen Geraden ändern sich aber nicht oder?

Gruß nillehammer

 

[Kubus]

Ok, mein Umgehungsversuch macht auch Murks, ich stehe wieder am Anfang.

Genau nillehammer, es ist so wie du es beschrieben hast, nur das sich nicht mehr als 2 Geraden in einem Punkt schneiden können. Somit weiß ich immer, das WENN es einen Schnittpunkt gibt, sich die Reihenfolge der beteiligten Geraden ändert. Diese wollte ich einfach Entfernen und wieder Einfügen um die Sortierung zu ändern.

Ach genau, die grünen Geraden ändern sich nicht, all ihre Attribute sind final.

 

[Marco13]

Ich hänge immernoch auf der "höheren Ebene". Der Grund dafür ist ganz einfach: Könnte es sein, dass das, was du dort erreichen (oder letztenendes berechnen) willst vielleicht viel einfacher, eleganter und effizienter berechnet werden kann, wenn man das nicht über TreeSet & Co löst, sondern mit blanker Mathematik?
Aber zu dem Bild: Gibt es nur EINE Vertikale Gerade, oder mehrere? Und bewegt sich die Vertikale Gerade "kontinuierlich" (vielleicht sogar stetig in eine Richtung?) ? Geht es als (vielleicht) NUR daraum, rauszufinden, wo die Schnittpunkte zwischen irgendzwei nicht-vertikalen Geraden sind, und um die Reihenfolge der Schnittpunkte zwischen der Vertikalen und den Anderen ZWISCHEN den Schnittpunkten der nicht-vertikalen?

 

[Kubus]

Ich wollte das Stichwort zwar nicht in den Raum werfen, weil ich dachte es betrifft das Problem nicht wirklich und stiftet nur Verwirrung, aber aus deiner Beschreibung erkenne ich das du weißt was ich machen will: Ein Sweep-Algorithmus zur Berechnung der Schnittpunkte. Die vertikale Gerade ist nur ein mal da, bewegt sich im Verlauf aber horizontal von links nach rechts durch den Raum. Das klappt alles soweit auch ganz gut, bis auf diese blöde Statusstruktur, die ich nach wie vor per Hand bereinigen muss :/

 

[nillehammer]

Also ich hab noch mal drüber nachgedacht. Für eine mathematische Lösung des Problems bin ich in Mathe zu schlecht. (Obwohl ich eigentlich dachte, dass ich garnich sooo schlecht bin :rtfm Ich bin der Meinung, dass Du um die Erzeugung neuer TreeSets nicht drum rum kommst. Dein original TreeSet ist dein Datenbestand, den Du sauber halten muss. Und die TreeSets, die entstehen, wenn Du Deinen Algorithmus anwendest sind "Sichten" auf den Datenbestand. Dafür hab ich mal folgendes Zusammengetippt. Der Einfachheit halber mal alles in einer Klasse.

package spielwiese;

import java.util.*;

import org.apache.commons.lang.builder.*;

public final class GeradenSpeicher {

	private final SortedSet<Gerade> geraden = Collections
			.synchronizedSortedSet(new TreeSet<Gerade>());

	public SortedSet<Gerade> getGeraden() {

		// Unsere clients sollen aus dem SortedSet nur lesen dürfen.
		// Für veränderung sollen sie unsere add-/remove methoden benutzen.
		return Collections.unmodifiableSortedSet(this.geraden);
	}

	public boolean addGerade(final Gerade gerade ) {

		// Vor null als Parameter schützen.
		if (gerade == null) {
			return false;
		}

		return this.geraden.add(gerade);

	}

	public boolean removeGerade(final Gerade gerade ) {

		// Reine nettigkeit, wir haben sowieso keine nulls
		// in unserem TreeSet. Wir prüfen hier nur,
		// um nicht unnötig den synchronisierten Abschnitt
		// betreten zu müssen.
		if (gerade == null) {

			return false;
		}

		return this.geraden.remove(gerade);
	}

	public SortedSet<Gerade> getSortedByFunktionsErgebnis(final float x ) {

		final SortedSet<Gerade> result = new TreeSet<Gerade>(
				new FunktionsVergleich(x));
		result.addAll(this.geraden);
		
		return result;
	}

	public static final class Gerade implements Comparable<Gerade> {

		private final float m; // Steigung

		private final float n; // y-Achsenabschnitt

		Gerade(final float m, final float n) {

			this.m = m;

			this.n = n;
		}

		/**
		 * Geraden werden zunächst nach ihrem y-Achsenabschnitt sortiert und dann
		 * nach ihrer Steigung.
		 */
		@Override
		public final int compareTo(final Gerade that ) {

			if (that == null) {
				throw new NullPointerException("That darf nicht null sein.");
			}

			return new CompareToBuilder().append(this.n, that.n)
					.append(this.m, that.m).toComparison();
		}

		/**
		 * Konsistent zu {@link #equals(Object)}.
		 */
		@Override
		public final int hashCode() {

			return new HashCodeBuilder(1, 13).append(this.m).append(this.n)
					.toHashCode();
		}

		@Override
		public final boolean equals(final Object obj ) {

			// Gerade ist final, also kann hier praktiverweise mit
			// instanceof gleichzeitig gepfüft werden, ob obj
			// != null und eine Gerade ist. Bei nicht finalen Klassen
			// muss muss mit getClass() und null separat geprüft werden.
			if (!(obj instanceof Gerade)) {

				return false;
			}

			final Gerade that = (Gerade) obj;

			return new EqualsBuilder().append(this.m, that.m).append(this.n, that.n)
					.isEquals();
		}

		@Override
		public final String toString() {

			return new ToStringBuilder(this).append("Steigung", this.m)
					.append("y-Achsenabschnitt", this.n).toString();
		}

	}

	public static final class FunktionsVergleich implements Comparator<Gerade> {

		private final float x;

		public FunktionsVergleich(final float x) {

			this.x = x;
		}

		@Override
		public final int compare(final Gerade g1, final Gerade g2 ) {

			final float ergebnis1 = g1.m * this.x + g1.n;

			final float ergebnis2 = g2.m * this.x + g2.n;

			final int ergebnisVergleich = new CompareToBuilder().append(ergebnis1,
					ergebnis2).toComparison();

			return ergebnisVergleich != 0 ? ergebnisVergleich : g1.compareTo(g2);
		}

	}
}

Der Code ist so wenigstens einigermaßen sauber und speichermäßig ist das auch vertretbar. Es wird nur zusätzlicher Speicher für die neuen TreeSets verbraucht und nicht für die Geraden. Performancemäßig ist TreeSet auch sehr schnell. Aber bei sehr vielen Geraden wird man merken, dass es dauert.

Gruß nillehammer

 

[Marco13]

"Wissen" tat ich es zwar nicht, aber es klang schon so, als würde das auf irgendwas rauslaufen, was mit Computergraphik (Polygonfüllen oder Triangulieren oder so...) zu tun hat

Für konkretere Tipps wäre es da evtl. notwendig oder hilfreich, die schon existierenden Datenstrukturen zu kennen (d.h. wie etwa eine "Linie" bisher gespeichert ist, oder wie die Schnitte berechnet werden). Aber vielleicht auch nicht. Ich habe mir über das Problem selbst noch nicht viele "konkrete" Gedanken gemacht, schätze aber, dass die Leute, die damals z.B. Polygone mit VGA-Grafik gefüllt haben, sich da schon geschickte Sachen ausgedacht haben, wie man das effizient in C oder Assembler (also gaaanz weit weg von einem TreeSet ) implementieren kann. Da müßte man sich mal schlau machen.

Aber ein Punkt, aus dem Bauch heraus: Ist das "ständiger sortiert-halten" der Mange in dieser Form(!) wirklich notwendig? Also, man erstellt am Anfang eine (meinetwegen einmal sortierte) Liste, und danach ... ändert sich doch immer nur die Reihenfolge von ZWEI Enträgen, und zwar genau dann (!), wenn ein Schnittpunkt überschritten wird, oder?! Kann man nicht dediziert genau diese beiden Elemente herauspicken und die "von Hand" vertauschen, statt das ganze so "implizit" über das Basteln einer TreeSet mit passenden Comparatoren zu machen?

 

[Landei]

Im Prinzip handelt es sich um eine Art Scanline-Algorithmus. Vielleicht mal schauen, was dort so als Datenstruktur verwendet wird.

 

[Kubus]

...

Dankeschön für die Mühe! Ich hatte es ähnlich implementiert wie du, nur ohne über ein SortedSet drauf zuzugreifen und ohne den Geraden ein compareTo, equals() oder HashCode() zu spendieren. Bei deiner Implementierung wird es aber wahrscheinlich dasselbe Problem geben: remove() wird oftmals nicht die richtige Gerade finden, bzw. add() nicht feststellen dass es das Objekt an anderer Stelle schon gibt.

Aber ein Punkt, aus dem Bauch heraus: Ist das "ständiger sortiert-halten" der Mange in dieser Form(!) wirklich notwendig? Also, man erstellt am Anfang eine (meinetwegen einmal sortierte) Liste, und danach ... ändert sich doch immer nur die Reihenfolge von ZWEI Enträgen, und zwar genau dann (!), wenn ein Schnittpunkt überschritten wird, oder?! Kann man nicht dediziert genau diese beiden Elemente herauspicken und die "von Hand" vertauschen, statt das ganze so "implizit" über das Basteln einer TreeSet mit passenden Comparatoren zu machen?

An sich wäre es schon möglich, das Problem ist nur, dass der Algorithmus als obere Schranke der amortisierten Laufzeit gerade die Zeit hat die für teuersten Operationen im Baum benötigt werden. Ich probiere jetzt gerade das ganze durch eine TreeMap zu ersetzen und das irgendwie wirksam sortiert zu halten. Sollte es zu ernsteren Erfolgen kommen schreibe ich nochmal

Im Prinzip handelt es sich um eine Art Scanline-Algorithmus. Vielleicht mal schauen, was dort so als Datenstruktur verwendet wird.

Fast, ich benutze einen modifizierten Bentley-Ottmann Algorithmus Laut aller Literatur die ich dazu finden konnte ist ein balancierter Baum auch genau das richtige, ich scheine nur etwas Wesentliches zu übersehen.

Naja, ich probiere noch ein wenig herum, ihr braucht euch nicht den Kopf damit zuzukleistern, habt mir schon genug geholfen. Danke an alle! Falls ich des Rätsels Lösung finde schreibe ich nochmal.

 

[nillehammer]

und ohne den Geraden ein compareTo, equals() oder HashCode() zu spendieren.

Was? Um Objekte in Java's Collection Klassen zu speichern, musst Du das aber machen! Ok, compareTo muss nicht sein, wenn Du einen expliziten Comparator angibtst, aber equals() und hashCode() müssen undbedingt sein. Und sie müssen auch konsistent zu einander sein. D.h. wenn equals() true liefert, müssen die Ergebnisse von hashCode() gleich sein, wenn equals() false liefert sollten die hashCodes verschieden sein.

 

[Kubus]

Was? Um Objekte in Java's Collection Klassen zu speichern, musst Du das aber machen! Ok, compareTo muss nicht sein, wenn Du einen expliziten Comparator angibtst, aber equals() und hashCode() müssen undbedingt sein. Und sie müssen auch konsistent zu einander sein. D.h. wenn equals() true liefert, müssen die Ergebnisse von hashCode() gleich sein, wenn equals() false liefert sollten die hashCodes verschieden sein.

Nicht im TreeSet, das wertet Gleichheit nur aufgrund des angegebenen Comparators aus, vgl.

[...]but a TreeSet instance performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of the set, equal

Quelle: TreeSet (Java 2 Platform SE v1.4.2)

Aber sogar wenn equals() und hashCode() da wären würde er ja leider gar nicht erst so weit kommen. Ich habe beides jetzt aus anderen Gründen eingebaut, keine Veränderung. Ich scheine vorher irgend einen anderen Fehler zu machen. JVM Debugger mein Freund und Helfer wird mir schon auf die Sprünge helfen

 

[nillehammer]

Nicht im TreeSet, das wertet Gleichheit nur aufgrund des angegebenen Comparators aus, vgl.

Das ist aber eine gewagte Annahme. Ich habe mir gerade den Quellcode von TreeSet angeschaut und es scheint tatsächlich so zu sein, dass es nicht equals() benutzt, aber sicher, dass ich etwas übersehen habe, bin ich nicht. Außerdem solltest du Deine Klassen nicht so entwickeln, dass sie nur genau mit einer speziellen Implementierung funktionieren. Aber egal, Du hast ja geschrieben, dass Du es sowieso schon gemacht hast...

 

[maki]

Das steht so in der Doku zum TreeSet
Da steht dann auch, dass das Verhalten von TreeSet definiert ist, falls euqals und compare nicht symetrisch arbeiten, aber eben der generelle Set Vertrag gebrochen wird.

 

[Kubus]

So, habe es jetzt hinbekommen. Es lag zum einen an einer mangelnden Präzision bei den Berechnungen (habe jetzt eine Klasse mit arbiträrer Präzision genommen) sowie der Nutzung des Vektorkreuzproduktes statt der Geradengleichungen bei der Schnittpunktbestimmung mit der Geraden. Ist also nichts technisches, sondern eher ein Problem der Umlegung von mathematischen Gedanken in die Welt der PC's, vor allem bei der Konvertierung Dezimal->Binär. Thread kann als erledigt markiert werden! Ich kann das leider nicht machen, war zu dem Zeitpunkt noch nicht angemeldet.

Danke nochmal an alle die ihre Gedanken beigesteuert haben!