String umformatieren

[P2oldi]

Moin zusammen!

Ich sitz hier grade an einem Problem bei welchem mir langsam die Ideen ausgehen, wie das schneller / einfache zu lösen wäre.

Problem: ich bekomme einen String in beliebiger Groß-/Kleinschreibung und soll den ganzen String entweder nur in Groß- oder nur in Kleinschreibung zurückgeben.

da ich weder an ASCII oder Hex-Werte der einzelnen Buchstaben komme, wäre mein Ansatz folgender (Pseudocode, Beispiel zum Umsetzen auf Kleinbuchstaben):
while index1 < eingabestring.laenge
{
while index2 < großesAlphabet
{
if eingabestring[index1] == großesAlphabet[index2]
{
eingabestring[index1] = kleinesAlphabet[index2]
}
}
}

durch die geschachtelten Schleifen ist das aber nicht grade performant, bei einem 10-stelligen String hab ich ja im ungünstigsten Fall schon 26 * 26 = 676 Durchläufe, und das kanns ja net sein.

Vielleicht hatte ja jemand schonmal ein ähnliches Problem, oder ne andere Idee, wie ich das entweder beschleunigen oder ganz anders lösen kann.

Vielen Dank schonmal für eventuelle Tips,

Gruß P2

[Trap]

2 andere Möglichkeiten:
a) ausnutzen dass die Codes der kleinen Buchstaben und die Codes der großen Buchstaben jeweils zusammenhängend sind und beide gleich geordnet sind: if(klein(a[i])) a[i]+='A'-'a'
b) Sets benutzen und zu jeden Buchstaben direkt auch das Gegenstück im Set speichern: x = map.lookup(a[i]); if(x) a[i]=x.substitute;

Edit:
Du hast die Codes ja nicht, dann geht nur b)
In welcher Programmierumgebung kommt man nicht an die Codes von Buchstaben?

[Pinoccio]

In welcher Programmierumgebung kommt man nicht an die Codes von Buchstaben?In einer theoretischen Aufgabe ^^.
Deine Idee mit einer Map ist gut, ist aber auch etwas absurd. Wer Maps hat sollte auch an die Codes Kommen oder sogar sowas wie String.toUpperCase() (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#toUpperCase()) bzw entsprechende.

Tip an P2oldi: switch (http://de.wikipedia.org/wiki/Verzweigung_%28Programmierung%29) mal anschauen!

mfg Sebastian

[Trap]

Hab noch eine primitive Möglichkeit vergessen:
c) binäre Suche über das Alphabet, damit braucht man nur 5 Zugriffe statt 26 pro Buchstabe

[P2oldi]

hallo zusammen :)

Umgebung ist Visual Age Generator der letztendlich heir Cobol-Code ausspuckt...

hab jetzt herausgefunden, wie ich an die Hex-Codes komme. Allerdings haben die *nichts* mit den ASCII-Hex Codes zu tun :( Liegen außerdem auch net in einer Reihe. Die Alphabete mit zugehörigen Hex-Codes sehen so aus:
a b c d e f g h i j k l m n o p q r s t u v w x y z ä ö ü
818283848586878889 919293949596979899 A2A3A4A5A6A7A8A9 43CCDC

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Ä Ö Ü
C1C2C3C4C5C6C7C8C9 D1D2D3D4D5D6D7D8D9 E2E3E4E5E6E7E8E9 63ECFC
grade Idee gehabt, und passt auch, das da oben in der Tabelle sind EBCDIC-Werte (http://www.asphelper.de/Referenz/EBCDIC.asp)! (ganz unten auf der Seite)

nützt also nicht wirklich was. Zumal diese dämlich Umgebung nicht in der Lage ist, mit hex-Werten zu rechnen bzw. sie in numerische Werte umzuwandeln...

eine andere Möglichkeit um die Laufzeit zu optimieren, könnte ein Quicksort-Ansatz sein.
ALso ich nehme den ersten Buchstaben, und statt das Array zu durchlaufen und genau zu gucken welcher es ist, frag ich direkt
if buchstabe > m
{
if buchstabe > t
{
if buchstabe > x
...
}
}
so würde ich auf jeden Fall in weniger als 26 Durchläufen den richtigen Buchstaben bekommen, und könnte ihn dann wegen der gleichen Indizierung direkt aus dem jeweils anderen Alphabet ersetzen?

@Pinoccio: die Umgebung unterstützt IF, ELSE und WHILE... also nix mit Switch leider :(

[Pinoccio]

Hab noch eine primitive Möglichkeit vergessen:
c) binäre Suche über das Alphabet, damit braucht man nur 5 Zugriffe statt 26 pro BuchstabeUnd wie machst du eine binäre Suche, wenn du keine Ordnung hast? (Hättets du eine Ordnung, könntest du dir dein Codes ja selber bauen).
/edit gard Poldis gelsen: Also Codes, ergo ne Ordnung hat man, dann gehts.
Daß es keinSiwtch gibt, naja ...

Handelt es sich um eine ernsthafte Anwenundg, die möglichst schnell laufen soll?

mfg Sebastian

[P2oldi]

Handelt es sich um eine ernsthafte Anwenundg, die möglichst schnell laufen soll?

Leider ja :(

[Pinoccio]

Leider ja :(Ok. Switch geht nicht, mit den Codes rechnen geht auch nicht.
Bleibt also die Variante mit ifs.
Wenn es also absolut um Geschwindigkeit geht, hiflt es, etwas über die betreffenden Daten zu wissen, speziell, wie sind sie verteilt: mehrheitlich großbuchstaben? "Natürliche" VErteilung oder gleichverteilt? etc. Damit könnte man den vorgeschlagenen Baum eventuell optimieren, weil zB e/E allein 17% macht in der deutschen Sprache.

(etwas OT: wird switch intern nicht eh in if-else kompiliert?)

mfg Sebastina

[Trap]

Kann man Buchstaben irgendwie als Index in eine Tabelle benutzen? Dann könntest du mit der langsamen Funktion die Ergebnisse vorberechnen und danach nurnoch in der Tabelle nachgucken.

[P2oldi]

danke Euch, das Problem hat sich gelöst :D
der Tip mit der Map war seeehr gut. Hab ja wie oben nachträglich verlinkt rausgefunden das es EBCDIC Werte sind, und die stehen auch schön in Tabellenform.
Hab mir also 2 Array gebaut, mit je 9 Zeilen und 3 Spalten.
#SPALTE1G = "ABCDEFGHI";
#SPALTE2G = "JKLMNOPQR";
#SPALTE3G = " STUVWXYZ";
und da ich ja den Hex-Code rausbekommen kann, prüfe ich mit Hilfe der ersten Stelle des Hex-Codes, in welche Zeile ich muß, die zweite Stelle des Hex-Codes ist dann die Spalte :) Und da ich die Hex-Codes der Kleinbuchstaben mit der Tabelle voller Großbuchstaben verknüpft habe, kann ich direkt an der Stelle dann den Großbuchstaben rausholen.

Sieht letztendlich jetzt so aus:
while $index < wortlaenge
{
if $hexwert[1] = Zeile1G
{
$ausgabefeld[$index] = Spalte1G[$hexwert[2]]
}
if $hexwert[1] = Zeile2G
{
$ausgabefeld[$index] = Spalte2G[$hexwert[2]]
}
if $hexwert[1] = Zeile3G
{
$ausgabefeld[$index] = Spalte3G[$hexwert[2]]
}
}

denke mal das müßte so auch ziemlich performant sein, auf jeden Fall aber massig schneller als die while-Idee, die ich zuerst hatte :)

Also vielen Dank nochmal für die Tips, falls Euch nochwas einfallen sollte, bin ja immer für weitere Verbesserungen offen :)