Taschenrechner ohne explizite und implizite Datentypen

[nh2003]

Hallo zusammen,

hat jemand von euch eine Idee, wie man einen (numerischen) Taschenrechner in Java umsetzt, der bei der Implementierung keine Zahlentypen (implizit und explizit) verwendet?

Man darf folglich auch nicht die Länge von zwei Zeichenketten vergleichen oder ein Array verwenden, weil bei letzterem folglich der Random Access durch einen Zahlentyp erfolgt.

Es ist sinnvoll hier die polnisch umgekehrte Notation zu verwenden.

Mein Ziel ist es, bei der Aufgabe fortgeschrittene Java Konzepte wie records, streams, lambda expressions, sealed interfaces und classes zu verwenden

Danke für die Hilfe!

 

[KonradN]

Sorry, das klingt alles irgendwie sinnlos. Du willst Operationen mit Zahlen durchführen, aber ohne jeden "Zahlentyp". Selbst ein char ist eine 16 Bit Zahl. Ein String ist auch nur eine Menge (Array) an Codepoints, wobei diese 16Bit Zahlen sind ...

Daher ist die Frage, wie Du fortgeschrittene Java Konzepte verwenden willst, wenn Du eigentlich alle primitiven Datentypen bereits ausgeschlossen hast? Und wenn Du nur einen Teil ausgeschlossen hast: Was willst Du erreichen durch die Beschränkung? Was willst Du üben oder vertiefen?

Also sorry, im Augenblick verstehe ich nicht, was Du vor hast oder erreichen willst (und wozu das gut sein sollte).

 

[mihe7]

Also sorry, im Augenblick verstehe ich nicht, was Du vor hast oder erreichen willst (und wozu das gut sein sollte).

Diese künstlichen Anforderungen sehen mir doch sehr nach (Haus-)Aufgabe aus.

 

[KonradN]

Diese künstlichen Anforderungen sehen mir doch sehr nach (Haus-)Aufgabe aus.

Beim Anfang sehe ich das ähnlich, aber der Satz mit den fortgeschrittenen Java Konzepten passt da dann doch nicht....

Und so über die Jahre sollten wir doch die "üblichen" Hausaufgaben kennen dachte ich 🙂

 

[M.L.]

records, streams, lambda expressions, sealed interfaces und classes

Diese Schlagworte haben mit Berechnungen eher weniger zu tun, eher deren Änderungsrate i.V. zur "klassischen" Vorgehensweise:
records <-> classes : Records, wenn die Änderung oder Erweiterung (z.b. durch Vererbung) einer Klasse eher selten zu erwarten ist
streams: dient nur zum lesenden Zugriff auf Datenströme
lambda expressions: Kurzfassung einer "klassischen" Methodendefinition und -nutzung
sealed interfaces: (Zitat von Gemini) "...können nur von explizit aufgelisteten Klassen oder Interfaces erweitert werden... Die Verwendung von versiegelten Interfaces empfiehlt sich daher in Situationen, in denen die Implementierung eines Interfaces stabil gehalten und vor ungewünschten Änderungen geschützt werden soll."

 

[mihe7]

Ja, man kann auch alles kompliziert machen.

Natürlich geht das Grundprinzip relativ einfach umzusetzen:

Deque<String> stack = new ArrayDeque<>();
String[] parts = input.split("\\s");
for (String part : parts) {
    stack.push(switch(part) {
        case "+", "-", "/", "*" -> applyOperator(part, stack);
        default -> part;
    });
}
if (stack.size() != 1) {
    throw new IllegalArgumentException("Boooooh!");
}
System.out.println(stack.pop());

Naja, und applyOperator:

String right = stack.pop();
String left = stack.pop();
return switch(operator) {
    case "+" -> plus(left, right);
    case "-" -> minus(left, right);
    case "*" -> multiply(left, right);
    case "/" -> divide(left, right);
    default -> throw new IllegalArgumentException();
};

Mal als Skizze, ich habs jetzt nicht ausprobiert, sollte aber ungefähr passen. "3 4 + 2 *" sollte in ["3","4","+","2","*"] gesplittet werden, dann würden 3 und 4 auf den Stack gelegt, bevor der + Operator erreicht wird, dann würden in applyOperator 3 und 4 vom Stack genommen addiert und das Ergebnis auf den Stack gelegt, so dass im Stack nur noch die "7" stünde. Dann würde die 2 auf den Stack gelegt, applyOperator aufgerufen, die 7 und die 2 vom Stack genommen, multipliziert, das Ergebnis "14" auf den Stack gelegt und die Schleife beendet. Im Stack liegt nur ein Element, nämlich das Ergebnis, und das wird vom Stack geholt und ausgegeben.

Um das ohne Stack und nur mit Streams, records, pattern matching etc. zu schreiben, muss man m. E. schon künstliche Verrenkungen auf sich nehmen.