Chars vor array übergabe toLowerUpcase

[Proxy]

Schönen Guten Tag,

ich habe folgendes Problem.Ich möchte gerne das, wenn ich ein Palimdrom eingebe und der erste Buchstabe groß ist, er trotzdem erkennt das es ein Palindrom ist.
Deswegen wollte ich das er erst alle Buchstaben in Kleinbuchstaben umwandelt. Mein Problem ist die Zeile 7 oder 8. Schonmal vielen Dank für die Tipps.

public class Palindrom {

    public static void main(String[] args) {
        
        
        System.out.println("Bitte Wort eingeben: ");
        String word = readWord();
        word.toLowerCase();
        char []array = word.toCharArray();
        System.out.println(palindrom(array));
        
    }
    
    public static boolean palindrom ( char[]array) {
        
        int left =0;
        int rigth = array.length-1;
        
        while(left<rigth) {
            if ( array[left]!=array[rigth]) {
                return false;
            }
            left++;
            rigth--;
            
        }
        return true;
    }
}

 

[httpdigest]

word.toLowerCase(); ----> word = word.toLowerCase();

Oder einfach gleich: String word = readWord().toLowerCase();

 

[Proxy]

word.toLowerCase(); ----> word = word.toLowerCase();

Oder einfach gleich: String word = readWord().toLowerCase();

Oh man richtig dumm von mir
Vielen dank.. das nächste mal mehr darüber nachdenken....

Gruß

 

[Marsupilami]

Du könntest auch einfach die equalsIgnoreCase-Methode aus der String-Klasse verwenden, die , wie sich aus der Bezeichnung auch ableiten lässt, keinen Unterschied zwischen Groß- und Kleinschreibung macht.

Sie hierzu auch https://openbook.rheinwerk-verlag.de/javainsel/05_005.html#u5.5.7

 

[Oneixee5]

Du könntest auch einfach die equalsIgnoreCase-Methode aus der String-Klasse verwenden, die , wie sich aus der Bezeichnung auch ableiten lässt, keinen Unterschied zwischen Groß- und Kleinschreibung macht.

Sie hierzu auch https://openbook.rheinwerk-verlag.de/javainsel/05_005.html#u5.5.7

equalsIgnoreCase gehört zur Klasse String, nicht zu char (-Vergleich). Funktioniert hier also nicht.

 

[temi]

das nächste mal mehr darüber nachdenken....

Und vor allem in die Dokumentation zur Methode schauen. Das kann man eigentlich gar nicht oft genug wiederholen.

 

[Marsupilami]

Es ging mir nur darum Ihm aufzuzeigen, dass es noch andere Möglichkeiten gibt, die Groß- bzw. Kleinschreibung außer Acht zu lassen. Er muss um auf ein mögliches Palindrom zu prüfen ja auch nicht zwingend zuerst in ein char-array konvertieren, sondern kann ja auch anders prüfen.

 

[Blender3D]

Schönen Guten Tag,

ich habe folgendes Problem.Ich möchte gerne das, wenn ich ein Palimdrom eingebe und der erste Buchstabe groß ist, er trotzdem erkennt das es ein Palindrom ist.
Deswegen wollte ich das er erst alle Buchstaben in Kleinbuchstaben umwandelt. Mein Problem ist die Zeile 7 oder 8. Schonmal vielen Dank für die Tipps.

Wie @httpdigest bereits erwähnt hat fehlt die Zuweisung.
Mein Tipp geht in eine andere Richtung.
1) Das Umwandeln des Strings in ein char Array ist ein unnötiger Umweg.
Grund: Du liest das Wort in einen String ein und musst diesen in ein char Array umwandeln.
2) Die Namensgebung
Die Funktion gibt einen boolean zurück. In dem Fall ist es üblich, dem Funktionsnamen ein (is)Name voranzustellen.
Also statt palindrom() lieber isPalindrom().
3) Unnötiger Gebrauch von 2 Variablen
Das Ganze lässt sich mit einer laufenden Variable realisieren.

public static boolean isPalindrom(String txt) {
        txt = txt.toLowerCase();
        for (int i = 0; i < txt.length() / 2; i++) {
            if (txt.charAt(i) != txt.charAt(txt.length() - 1 - i))
                return false;
        }
        return true;
    }

 

[Marsupilami]

Geht auch mit einem Einzeiler😀
public class Palindrom {

public class Palindrom {

    public static void main(String[] args)
    {
        System.out.println(Palindromtest());
    }

    public static boolean Palindromtest()
    {
        String s = "Otto";
        StringBuilder sb = new StringBuilder(s);
        
        return sb.reverse().toString().equalsIgnoreCase(s);
    }
    
}

 

[Blender3D]

Geht auch mit einem Einzeiler😀

Du meinst so?

public static boolean isPalindrom(String s) {       
        return (new StringBuilder(s)).reverse().toString().equalsIgnoreCase(s);
    }

Ja funktioniert.
Aber zu welchem Preis? (Umweg )
1) Es wird ein Stringbuilder Objekt aus dem String erzeugt
2) Das Stringbuilder Objekt wird umgedreht.
3) Aus dem Stringbuilder Objekt wird ein neuer String erzeugt.
4) Der ursprüngliche String wird in seiner vollen Länge mit dem neuem String verglichen.

In der anderen Variante wird ausschließlich der übergebene String in der halben Länge durchlaufen.
Ein Algorithmus der die Aufgabe hat 1 Million oder mehr Worte auf die Eigenschaft Palindrom zu testen würde sich wahrscheinlich nicht über nur 1 Zeile Code freuen.

 

[KonradN]

Also da meine Sichtweise doch deutlich abweicht, möchte ich diese einmal hier etwas darstellen. Ich sehe vor allem Clean Code Aspekt und da komme ich halt zu einer deutlich anderen Bewertung als @Blender3D:

Aber zu welchem Preis? (Umweg )

Also genau das sehe ich anders. Das ist eine Form der Optimierung und da gilt aus meiner Sicht: Don't do it:
Roter Grad | Clean Code Developer (clean-code-developer.de)

Der Ansatz aus meiner Sicht sollte doch sein:
a) Fachliches Verständnis. Und da schaut man einfach, was ein Palindrom ist:

Als Palindrom (altgriechisch παλίνδρομος palíndromos „rückwärts laufend“) werden in der Sprachwissenschaft Wörter, Wortreihen oder Sätze bezeichnet, die rückwärts gelesen genau denselben Text oder zumindest einen Sinn ergeben.

Palindrom – Wikipedia

b) Und das setze ich dann 1:1 um:

public boolean isPalindrom(@NonNull String text) {
    text.equalsIgnoreCase(reversed(text));
}

Dann kommt natürlich noch das reversed, das man benötigt. Dazu kann man dann z.B. zu dem StringBuilder greifen. Das wäre vermutlich auch mein Ansatz.

Das erfüllt die Anforderung sehr einfach und gradlinig. Klar: Mit etwas nachdenken weiss man: Ich muss nur die erste Hälfte prüfen, aber das verkompliziert den Code. KISS - Keep it simple, stupid. (Auch im roten Grad von Clean Code Developers, erster gegebener Link.)


Also um es ganz klar und deutlich zu sagen: So Optimierungen sind der größte Feind von Clean Code! Toll, dass Du irgend einen optimierten Algorithmus hast, aber der Code zeigt nicht auf einen Blick, was er macht.

Und ganz nebenbei: Es kann durchaus schneller sein, einen ganzen String zu vergleichen als viele Einzelvergleiche zu haben. Die CPUs haben zum Vergleich von Speicherbereichen Befehle (z.B. CMPS bei i386 CPUs.) Somit denke ich, dass eine Aussage zur Performance hier schlicht keine Grundlage hat. Die Optimierungen kennen wir z.B. nicht und müssten da also deutlich mehr betrachten. (Daher: Keine Optimierungen ohne genaue Analyze! Und eine Analyze umfasst im das ganze Problem. 1. Ist es wirkliche diese Stelle, die das Problem ist? 2. Was für Lösungsmöglichkeiten gibt es? Evtl. ändert man die Datenhaltung oder macht gewisse Dinge generell an anderer Stelle oder so.)

Ich würde also definitiv die Lösung mit dem StringBuilder bevorzugen. (Wobei die ganze Fragestellung an dem Kernthema vorbei geht - das dürfte eine Übung für Anfänger gewesen sein, wo es darum ging, paar Grundlagen zu erlernen. Da ist der Ansatz mit der Schleife natürlich die gewünschte Lösung. Aber der Punkt wurde bei der Diskussion ja außen vor gelassen.)

 

[Blender3D]

Also genau das sehe ich anders. Das ist eine Form der Optimierung und da gilt aus meiner Sicht: Don't do it:

Ich bin so wie Du für gut lesbaren Code. Aber auch hier gilt es den Kontext zu betrachten.
Bei Util funktionen die eventuell sehr oft in Folge benutzt werden ist die Geschwindigkeit viel wichtiger als die Lesbarkeit. So werden z.B. Math.sqrt .. sogar meist nativ umgesetzt.
Die Lesbarkeit ist trotzdem gegeben, da sich die Benutzung auf die Schnittstelle beschränkt.
wert = Math.sqrt( 3 ).
isPalindrom( "otto" )

Würde der Benutzer mit dieser Funktion die Anzahl der Palindrome in vielen Büchern zählen wollen, wäre er mit der schnelleren Variante sicher besser beraten.

Und ganz nebenbei: Es kann durchaus schneller sein, einen ganzen String zu vergleichen als viele Einzelvergleiche zu haben. Die CPUs haben zum Vergleich von Speicherbereichen Befehle (z.B. CMPS bei i386 CPUs.) Somit denke ich, dass eine Aussage zur Performance hier schlicht keine Grundlage hat.

Es handelt sich hier nicht nur um den Vergleich der halbiert ist.
Wichtiger ist:
Es werden pro Vergleich 2 neue Objekte erzeugt.
a) StringBuilder mit zusätzlichem Aufruf von reverse
b) String
c) Vergleich über die gesamte Länge
Wenn wir das Ganze millionenfach aufrufen .....
Funktionen wie Palindrom gehören zu sogenannten Utilfunktionen. Diese werden normalerweise importiert und benutzt. Wichtig für die Lesbarkeit ist die Schnittstelle.
Der Benutzer der Funktion kennt die Implementierung nicht, und braucht sie auch nicht zu kennen. Er benutzt sie lediglich über die Schnittstelle die in beiden Fällen gleich lautet
isPalindrfom( text ) .

 

[mrBrown]

Der ursprüngliche String wird in seiner vollen Länge mit dem neuem String verglichen.

Vergleich über die gesamte Länge

Wie kommst du darauf? Verglichen wird bis zum ersten unpassenden Zeichen.

Es werden pro Vergleich 2 neue Objekte erzeugt.
a) StringBuilder mit zusätzlichem Aufruf von reverse
b) String

Wird der Compiler weg-optimieren, das teure ist das Umdrehen des Arrays

 

[Blender3D]

Wie kommst du darauf? Verglichen wird bis zum ersten unpassenden Zeichen.

Das ist selbstverständlich die Worst Case Situation. Im Vergleich also lenght/2 vs lenght.

Wird der Compiler weg-optimieren, das teure ist das Umdrehen des Arrays

Gibt es da eine Garantie in den Richtlinien für jeden Compiler ?

 

[Neumi5694]

Du meinst so?

public static boolean isPalindrom(String s) {     
        return (new StringBuilder(s)).reverse().toString().equalsIgnoreCase(s);
    }

Ja funktioniert.
Aber zu welchem Preis? (Umweg )
1) Es wird ein Stringbuilder Objekt aus dem String erzeugt
2) Das Stringbuilder Objekt wird umgedreht.
3) Aus dem Stringbuilder Objekt wird ein neuer String erzeugt.
4) Der ursprüngliche String wird in seiner vollen Länge mit dem neuem String verglichen.

In der anderen Variante wird ausschließlich der übergebene String in der halben Länge durchlaufen.
Ein Algorithmus der die Aufgabe hat 1 Million oder mehr Worte auf die Eigenschaft Palindrom zu testen würde sich wahrscheinlich nicht über nur 1 Zeile Code freuen.

Kommt jetzt drauf an, was der Compiler daraus macht. Wenn jeder Teilbefehl einzeln in die CPU geschickt wird, dann ist das klar langsamer.
Da es aber Pipelines mit 20 oder mehr Befehlen gibt, könnte es sich die Waage halten. Inwiefern die JVM das nutzen kann, steht freilich auf einem anderen Blatt.
Wer Lust hat, kann das gerne mal testen

Aber selbst falls seine Methode langsamer ist ... macht man das denn wirklich eine Million mal in Folge? Ob der Check in einem Userformular nun eine oder zwei Millisekunden braucht, ist nämlich vollkommen irrelevant.
Fast alles, was heutzutage zu gutem Programmierstil gehört, ist deutlich langsamer, als wenn man es direkt hardcodiert, so wie auch das Aufrufen von Methoden per se. Die JVM muss da im Hintergrund einiges machen. Die Befehle direkt als Spaghetticode zu schreiben, wäre effizienter. Mittlerweile ist Lesbarkeit und Wiederverwertbarkeit wichtiger als Kosteneffizienz. Anwendungen werden weniger durch CPU-Leistung als durch Verzögerungen beim Netzwerkzugriff ausgebremst. So lange man keine Treiber schreibt oder aufwendige mathematische Berechnungen macht, sollte man den Fokus nicht auf i-Tüpftelchen legen.
Und ja, auch ich hab meine Schwierigkeiten damit. Ich hasse Streams in Java nach wie vor, weil sie so arschlangsam sind. Wo es keinen deutlichen Vorteil bringt, einen Stream zu verwenden, bleibe ich bei Iterables. Einen Lesbarkeits-Kompromiss stellt forEach bei Collections dar, intern wird da mit einer Iterable gearbeitet (bei mir geht's aber auch wirklich fast immer um mathematische Berechnungen, bei den Formularen bin ich da toleranter).