Manche Java-Programmierer ärgerten sich - zumindest bis Java 7 - immer wieder über die Tatsache, dass Fundamentaldatentypen oder Simple Types nicht nativ in Collections unterstützt werden. Mit der Addition von Auto-(Un)Boxing wurde das zwar etwas einfacher, gleichzeitig wurden aber neue Stolpersteine eingeführt. Ich sehe dieses als gute Gelegenheit, an die Auswirkungen von Machine-Epsilons erinnert zu werden...

Man mag manchmal dazu versucht sein, Doubles oder Floats als Schlüssel in Maps einzusetzen oder Sets dazu zu missbrauchen, zu checken, ob ein bestimmter Gleitkommawert bereits aufgetreten ist.

Das ist aus dem Blickwinkel der begrenzten numerischen Trennschärfe der gängigen Gleitkommatypen auf digitaler Hardware keine gute Idee: Berechnet man das Machine Epsilon in Java und versucht dann, eine 1 und eine 1 addiert um die Hälfte des Machine Epsilon voneinander zu unterscheiden, schlägt das fehl:

		double machEps = 1.0;
		do
		{
			machEps /= 2.0;
		}
		while ((double) (1.0 + (machEps / 2.0)) != 1.0);
		System.out.println("machine Epsilon= "+machEps);
		machEps /= 2.0;
		Double a = new Double(1);
		Double b = new Double(a.doubleValue() + machEps);
		java.util.Set doubles = new java.util.HashSet();
		doubles.add(a);
		System.out.println(doubles.contains(b));

Es sei darauf verwiesen, dass auch die Klasse BigDecimal dieses Problem nicht löst. Versucht man ein Machine Epsilon dafür zu errechnen, stellt man fest, dass die Berechnung

		java.math.BigDecimal machEpsBD = new java.math.BigDecimal(1.0);
		java.math.BigDecimal sum=null;
		int loop=0;
		do
		{
			machEpsBD = machEpsBD.divide(java.math.BigDecimal.ONE.add(java.math.BigDecimal.ONE));
//			if(loop%1000==0)
//				System.out.println(loop+" "+machEpsBD.scale());
//			++loop;
			sum=java.math.BigDecimal.ONE.add(machEpsBD.divide(java.math.BigDecimal.ONE.add(java.math.BigDecimal.ONE)));
		}
		while (sum.equals(java.math.BigDecimal.ONE)==false);
		System.out.println("machine Epsilon (BigDecimal)= "+machEpsBD);

sehr viel länger dauert und könnte versucht sein, zu jubeln, dass es hier kein Machine Epsilon gibt - und damit kein Trennschärfeproblem. Liest man sich jedoch die Dokumentation der Klasse durch, stellt man fest, dass das Machine-Epsilon bei der Verwendung von BigDecimal lediglich sehr viel kleiner ist - es verschwindet durch deren Einsatz nicht:

Immutable, arbitrary-precision signed decimal numbers. A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale. If zero or positive, the scale is the number of digits to the right of the decimal point.

Das bedeutet, wenn der Wert für scale bei dem durch die festgelegten 32 Bit angekommen ist, tritt das Problem wieder auf! Die Tatsache, dass der Wert bei der Suche nach dem Machine Epsilon stetig steigt, kann man erkennen, wenn man die auskommentierten Zeilen im obigen Quelltextschnipsel aktiviert.

Man sieht daran auch wunderschön, wie sich die Komplexität der Berechnungen mit BigDecimals unter Java mit steigender Anzahl Nachkommastellen erhöht.

Lizenz

Quelltext

Artikel, die hierher verlinken