mathematische Operationen als Methode und nicht Infix-Operator

[Q-Base]

Hallo *,

die mathematischen Operationen +, -, *, /, %, ... funktionieren ja sehr schön mit dem primitiven Datentypen. Ich würde jedoch gerne die entsprechenden nummerischen Klassen aus java.lang.* benutzen und auf Auto-Boxing verzichten.

Nun gibt es zwar die Klasse java.lang.Math, in der einige mathematischen Operationen vorhanden sind, aber eben nicht Addition, Subtraktion, ... etc.

Suche ich nur in der falschen Klasse oder ist dem wirklich so, dass ich die Infix-Operatoren nicht ersetzen kann?

Ciao, Q

 

[Wortraum]

Das ist wirklich so. In Java geht das leider nicht.

 

[Noctarius]

OperatorOverloading gibt es in Java offiziell nicht. Mit ein wenig tricksen und einem Eclipse Compiler Mod von mir würde es gehen. Ich würde es aber nicht machen solange es nichts offizielles gibt.

 

[SlaterB]

selber schreiben:

public class Test
{
    public static void main(String[] args)
    {
        Integer x = 4;
        Integer y = 5;
        Integer z = add(x, y);
        System.out.println(z);
    }

    public static Integer add(Integer x, Integer y)
    {
        return Integer.valueOf(x.intValue() + y.intValue());
    }
}

 

[Wortraum]

@SlaterB:
So eine Methode kann man natürlich schreiben, man kann aber nicht den Infix-Operator selbst überladen wie in Ada95 oder C++.

 

[SlaterB]

man kann auch nicht mit Java zum Mond fliegen,
mir scheint, in der Frage geht es in diesem Fall in die andere Richtung, selbst die wenigen vorhandenen Infix-Operatoren sollen gar nicht mehr genutzt sondern durch Methoden ersetzt werden

 

[Leroy42]

man kann aber nicht den Infix-Operator selbst überladen

Davon hat der OP doch überhaupt nichts erwähnt! ???:L

 

[Noctarius]

Suche ich nur in der falschen Klasse oder ist dem wirklich so, dass ich die Infix-Operatoren nicht ersetzen kann?

Doch hat er wenn man ersetzen als überladen interpretiert!

 

[Wortraum]

Davon hat der OP doch überhaupt nichts erwähnt! ???:L

Habe ich schon wieder zu weit gedacht? Ersetzen ergab für mich keinen Sinn, vielleicht las ich deswegen überladen. Aber es geht sowieso beides nicht.

 

[Q-Base]

Nein, das hat einen ganz anderen Hintergrund.

Es wird in einer Map<String, Serializable> in Form von Name=Wert eine Menge Daten gespeichert. Es sind alles Zahlen unterschiedlichen Formats. Problem: mit den Zahlen soll gerechnet werden.

Die Klasseninformationen sind ja noch vorhanden. Nur mit dem Infix-Operator komme ich so nicht weiter, weil man Serializeables nicht addieren, subtrahieren etc kann.

		Serializable s1i = new Integer(42);
		Serializable s2l = new Long(42);
		Serializable s3d = new Double(42);
		Serializable s4f = new Float(42);
		
		System.out.println(s1i + " :: " + s1i.getClass());
		System.out.println(s2l + " :: " + s2l.getClass());
		System.out.println(s3d + " :: " + s3d.getClass());
		System.out.println(s4f + " :: " + s4f.getClass());

Leider ist auch Reflections keine große Hilfe. Der folgende Code ist auch nicht so günstig. Er kompiliert nicht durch.

Long sum = s1i.getClass().cast(s1i) + s2l.getClass().cast(s2l);

Dabei darf man Longs und Integers summieren, die Code below:

Long sumsum = 42 + 42L;

Ideen?

Ciao, Q

 

[0x7F800000]

Die erben aber alle von Number (Number ist auch Serializable). Und bei Number gibt's unter anderem doubleValue(). Double wäre wohl der sinnvollste "umfassendste gemeinsame Format", zumindest solang's um irgendwelchen bürokratisch-wirtschaftlichen kram geht. Also einfach nur in der map deklaration Serializable nach Number abändern.

 

[Q-Base]

Die erben aber alle von Number (Number ist auch Serializable). Und bei Number gibt's unter anderem doubleValue(). Double wäre wohl der sinnvollste "umfassendste gemeinsame Format", zumindest solang's um irgendwelchen bürokratisch-wirtschaftlichen kram geht. Also einfach nur in der map deklaration Serializable nach Number abändern.

Es ist richtig, dass man zum Beispiel auch doubleValue() hat, aber was machst du, wenn es eigentlich ein Long ist? Dass in der Menge der Doubles auch alle Elemente aus Long enthalten sind, bestreite ich ja nicht. Nur die Typinformation geht dadurch verloren bzw. frage ich mich dann ernsthaft, warum es dann noch Long und Double etc gibt, wenn man sowieso nur noch mit Number arbeiten sollte. Schließlich ließe sich ja auch so rechnen.

Ciao, Q

 

[SlaterB]

nimm BigDecimal, das kann alles, wenn auch etwas langsam

 

[Q-Base]

Ich habe mir auch schon überlegt, ob ich nicht einfach alle nummerischen Typen spare und einfach Double benutze. Nur ist das die der wahre Weg. Auch den Wert einfach nur abzuschneiden in der Hoffnung, dass es passt, kann irgendwie zu falschen Ergebnissen führen. Schließlich kann man ja auch shortValue() auf einem wirklich großen Wert von Double ausführen. :-(

Ärgerlich an der Stelle ist einfach, dass man über getClass() nur ein Objekt Class<?> zurück bekommt. Mit dem kann man leider nicht vernünftig rechnen. Was aber sehr gut geht:

		Serializable s1 = 42;
		Serializable s1l = 42L;
		Long longSum = Integer.class.cast(s1) + Long.class.cast(s1l);

Class.class liefert in dem Fall einfach eine statische Klasse. Die kann man dann wunderbar benutzen.

Andere Ideen?

Ciao, Q

 

[0x7F800000]

Es ist richtig, dass man zum Beispiel auch doubleValue() hat, aber was machst du, wenn es eigentlich ein Long ist?

beschwer dich bei demjenigen, der dich dazu zwingt, mit unbekannten zahlentypen rumzurechnen, die gar nicht so richtig zusammenpassen. Sollte es tatsächlich um haufen Kohle gehen, dann wäre BigDecimal wohl wirklich die einzige vernünftige Lösung, sonst kriegst du noch stress mit der Mafia.

Dass in der Menge der Doubles auch alle Elemente aus Long enthalten sind, bestreite ich ja nicht.

nein, sind sie nicht. dafür ist long zu beschränkt und double hat zu kleine genauigkeit. Das sind zwei nichtdisjunkte Mengen, aber keine der beiden ist Teilmenge der anderen.

Nur die Typinformation geht dadurch verloren bzw. frage ich mich dann ernsthaft, warum es dann noch Long und Double etc gibt, wenn man sowieso nur noch mit Number arbeiten sollte. Schließlich ließe sich ja auch so rechnen.

Ja, aber nur sehr ungenau. Aber das ist ja kein allgemeines, sondern dein konkretes problem, weil in deinem Fall irgendwas dazu führt, dass die Zahlen in verschiedenen Formaten angeliefert werden....

Es sind alles Zahlen unterschiedlichen Formats. Problem: mit den Zahlen soll gerechnet werden.