Prüfen, ob letztes Zeichen eine Ziffer ist

[Julia]

Hallo Leute,

hat jemand einen Tip, wie man prüfen kann, ob das letzte Zeichen in einer Variable eine Ziffer ist.

Beispiel:

$inhalt="Der Mann wird alt";
$inhalt2="Der Mann wird 50";

In so einem Fall will ich $inhalt2 aufgrund des letzten Zeichens unterscheiden können. Weiß leider nicht, wie ich das anders ausdrücken soll..

[Sven Rautenberg]

Moin!

hat jemand einen Tip, wie man prüfen kann, ob das letzte Zeichen in einer Variable eine Ziffer ist.

Erst extrahierst du das letzte Zeichen des Strings, und dann prüfst du, ob es eine Ziffer ist.

- Sven Rautenberg

[Felix Riesterer]

Lieber Sven,

Erst extrahierst du das letzte Zeichen des Strings, und dann prüfst du, ob es eine Ziffer ist.

ich finde Deine Antwort sehr gut. Vor allem im Hinblick auf die zu erwartenden Verständnismöglichkeiten des OP.

Ich löse soetwas aber so:

if (preg_match('~(?is)\d$~', $myString)) {  
    // Aha, letztes Zeichen eine Ziffer  
    reagiere_auf_ziffer();  
} else {  
    // letztes Zeichen keine Ziffer  
    reagiere_auf_nichtziffer();  
}

Liebe Grüße,

Felix Riesterer.

[Sven Rautenberg]

Moin!

Ich löse soetwas aber so:

Und erklärst es lieber nicht.

Deshalb meine Frage:

Wozu zum Teufel brauchst du hier case-insensitives Matching und das Matching des Punktes auch auf Newlines?

if (preg_match('~(?is)\d$~', $myString))

- Sven Rautenberg

[Felix Riesterer]

Lieber Sven,

Ich löse soetwas aber so:

Und erklärst es lieber nicht.

richtig. Was es tun soll, ist klar, wie es das tut, ist für den/die OP zunächst wahrscheinlich eh nicht so schnell nachvollziehbar (dafür war Deine Lösung gedacht).

Wozu zum Teufel

Tja, ebenselbiger steckt bekanntlich im Detail.

brauchst du hier case-insensitives Matching

Das ist inzwischen bei mir ein Automatismus, der hier keine gesonderte Wirkung hat und entfallen könnte/sollte/müsste.

und das Matching des Punktes auch auf Newlines?

Da ich den Teufel im Detail nicht kenne und deshalb nicht davon ausgehen kann, dass _keine_ Newlines im String enthalten sind, habe ich diese "Vorkehrung" getroffen. Auch ein Automatismus, den ich mir im Kontext meiner eigenen Scripte angewöhnt habe, da ich fast immer HTML-Quelltexte mit preg_xyz-Funktionen "durchleuchte".

Liebe Grüße,

Felix Riesterer.

[Der Martin]

Hallo Felix,

ich finde Deine Antwort sehr gut.

ich auch, weil sie zielstrebig und einfach ist - sowohl vom technischen Standpunkt, als auch vom Verständnis her.

Ich löse soetwas aber so:
if (preg_match('~(?is)\d$~', $myString))

Warum willst du die große Keule RegEx schwingen, wenn es nur darum geht, ein einziges Zeichen daraufhin zu prüfen, ob es in einem klar definierten Intervall (liegt? Das ist ja so, als wolltest du ein ganzes OP-Team zusammentrommeln, um dem Patienten ein Hühnerauge zu entfernen.

So long,
 Martin

[Klawischnigg]

Hi there,

Ich löse soetwas aber so:

if (preg_match('~(?is)\d$~', $myString)) {

// Aha, letztes Zeichen eine Ziffer
    reagiere_auf_ziffer();
} else {
    // letztes Zeichen keine Ziffer
    reagiere_auf_nichtziffer();
}

  
  
Wahrscheinlich schreibst Du Dir auch einen Plan, wenn Du einmal pinkeln gehst. Ich jedenfalls hätt' für so etwas keine Zeit...  
  
  

[Bademeister]

Hi Sven,

Erst extrahierst du das letzte Zeichen des Strings,

oder Du sprichst das letzte Zeichen direkt per "String access by character" an (PHP: Strings). Sein Offset ist ja mittels der Laenge des Strings leicht zu ermitteln.

Viele Gruesse,
der Bademeister

[dedlfix]

Hi!

Erst extrahierst du das letzte Zeichen des Strings,

substr($text, -1)

oder Du sprichst das letzte Zeichen direkt per "String access by character" an (PHP: Strings). Sein Offset ist ja mittels der Laenge des Strings leicht zu ermitteln.

$text[strlen($text) - 1]

Sven gewinnt :-)

$text[-1] geht ja nicht unter PHP.

Lo!

[Bademeister]

Hi dedlfix.

substr($text, -1)

ist aber *sehr* viel langsamer als

$text[strlen($text) - 1]

"Bademeister trifft in der Nachspielzeit zum 1:1-Ausgleich. Was fuer ein Spiel!"

;-)

Gruesse an alle,
der Bademeister

[dedlfix]

Hi!

substr($text, -1)

ist aber *sehr* viel langsamer als

$text[strlen($text) - 1]

In welcher Größenordnung? Und wieviele Ausführungen braucht es, um die Differenz spüren zu können?

Lo!

[Bademeister]

In welcher Größenordnung?

Hmmm, jetzt haste mich ueberredet, es mal zu testen: Ca. Faktor 10.

Und wieviele Ausführungen braucht es, um die Differenz spüren zu können?

Spueren? Das kommt ein bissi drauf an, wie ungeduldig Du bist ;-) Bei hundert Iterationen komm ich im Mittel ca. auf 0,02 vs. 0,002 Sekunden.

Viele Gruesse,
der Bademeister

[dedlfix]

Hi!

Und wieviele Ausführungen braucht es, um die Differenz spüren zu können?
Spueren? Das kommt ein bissi drauf an, wie ungeduldig Du bist ;-) Bei hundert Iterationen komm ich im Mittel ca. auf 0,02 vs. 0,002 Sekunden.

Das Übliche also. Bei Gebrauch in "handelsüblichen" Mengen ist es nichts als Mikrooptimierung ohne praktische Auswirkung.

Lo!

[Felix Riesterer]

Lieber dedlfix,

Das Übliche also. Bei Gebrauch in "handelsüblichen" Mengen ist es nichts als Mikrooptimierung ohne praktische Auswirkung.

mit einigermaßen weniger einfach zu lesendem Code. Nur um die Ausführung unwesentlich zu beschleunigen, wurde ein wesentlich komplexerer Code verwendet. Da tendiere ich dann doch auch zu Svens Lösung.

Liebe Grüße,

Felix Riesterer.

[Bademeister]

Das Übliche also. Bei Gebrauch in "handelsüblichen" Mengen ist es nichts als Mikrooptimierung ohne praktische Auswirkung.

Was hast Du denn jetzt erwartet? Wenn die Ausfuehrung von substr() ca. 0,2 Mikrosekunden dauert, koennte die andere Variante auch um den Faktor 5 Millionen schneller sein, ohne dass es zu merklichen Unterschieden kommt, wenn es wenige Iterationen sind. Und ich weiss nicht, was Du unter "handelsueblich" verstehst, aber m.E. kann es ganz schnell in Bereiche kommen, in denen es eine praktische Auswirkung hat - schon bei 1000 halte ich den Unterschied - 2 Zehntel gegen 2 Hundertstel - fuer signifikant.

Uebrigens: Die substr()-Loesung sieht ohne Zweifel huebscher aus. Aber ich z.B. haette vorher nicht auswendig gewusst, dass mir substr($string, -1) das letzte Zeichen liefert, waehrend die Array-Schreibweise selbsterklaerend ist. Daher koennte ich nicht behaupten, dass die substr()-Variante fuer Noobs wie mich lesbarer ist.

Aber ich will hier jetzt nicht dickkoepfig sein. Ein Pauschalurteil, welche Variante besser ist, halte ich fuer unsinnig und ich weiss selber nicht, welche Variante ich im Einzelfall nehmen wuerde. So oder so lohnt es sich, die Alternativen zu kennen.

Viele Gruesse,
der Bademeister

[flowh]

Hallo Bademeister.

Uebrigens: Die substr()-Loesung sieht ohne Zweifel huebscher aus. Aber ich z.B. haette vorher nicht auswendig gewusst, dass mir substr($string, -1) das letzte Zeichen liefert, waehrend die Array-Schreibweise selbsterklaerend ist. Daher koennte ich nicht behaupten, dass die substr()-Variante fuer Noobs wie mich lesbarer ist.

Das Problem an der $string[]-Schreibweise ist, dass sie im Gegensatz z.B. zu substr() nicht mit Multibyte-Kodierungen wie Unicode zurecht kommt.
Deswegen will ich sie nicht verwenden.

Servus,
Flo

[Sven Rautenberg]

Moin!

Das Problem an der $string[]-Schreibweise ist, dass sie im Gegensatz z.B. zu substr() nicht mit Multibyte-Kodierungen wie Unicode zurecht kommt.

Stimmt, das ist ein wichtiger Einwand, allerdings nicht vollständig zu Ende gebracht: Für Multibyte-Encodings ist mb_substr() zu verwenden - substr() scheitert auch.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Das Problem an der $string[]-Schreibweise ist, dass sie im Gegensatz z.B. zu substr() nicht mit Multibyte-Kodierungen wie Unicode zurecht kommt.

Stimmt, das ist ein wichtiger Einwand, allerdings nicht vollständig zu Ende gebracht: Für Multibyte-Encodings ist mb_substr() zu verwenden - substr() scheitert auch.

Ok, außer man schaltet Function-Overloading an: http://de.php.net/manual/en/mbstring.overload.php - ist aber kein Default. Und auch nicht wirklich schön, weil es nicht alle Probleme löst.

- Sven Rautenberg

[flowh]

Hallo Sven.

Ok, außer man schaltet Function-Overloading an: http://de.php.net/manual/en/mbstring.overload.php - ist aber kein Default. Und auch nicht wirklich schön, weil es nicht alle Probleme löst.

Ah, danke – ich hatte mich nämlich gerade gewundert, warums mit substr() klappt.

Servus,
Flo

[dedlfix]

Hi!

Das Übliche also. Bei Gebrauch in "handelsüblichen" Mengen ist es nichts als Mikrooptimierung ohne praktische Auswirkung.
Was hast Du denn jetzt erwartet?

Ich selbst habe nichts anderes erwartet. Um nicht als argumentativer Verlierer dazustehen - so scheint es mir meist - kommt in solchen Situationen recht schnell und pauschal das Performance-Argument, ohne zu wissen, ob im konkreten Anwendungsfall der Gewinn einen Nutzen bringt. Denn oft ist es so wie beim Sportler, der seine eigene Bestleistung um zwei Zehntelsekunden unterboten hat. Er hat nun mehr Freizeit, aber was nutzt es letztlich?

Wenn die Ausfuehrung von substr() ca. 0,2 Mikrosekunden dauert, koennte die andere Variante auch um den Faktor 5 Millionen schneller sein, ohne dass es zu merklichen Unterschieden kommt, wenn es wenige Iterationen sind.

Genau, keiner merkt etwas davon. Aber der Programmierer hatte damit Arbeit. Wenn dann auch noch der entstandene Code schwerer als üblich oder notwendig verständlich ist, ...

Am Ende muss bei einer Optimierung eine signifikante Entlastung des gesamten Servers rauskommen, so dass er mehr Reserven für den Bedarfsfall (Stoßzeit) zur Verfügung hat. Wenn ein Hafen einen Liter Wasser mehr aufnehmen kann, reicht das selten für eine Sturmflut. Ebenso muss der Optimierungsaufwand gegengerechnet werden zu anderen Lösungen, wie Lastverteilung auf einen zweiten Server.

Und ich weiss nicht, was Du unter "handelsueblich" verstehst, aber m.E. kann es ganz schnell in Bereiche kommen, in denen es eine praktische Auswirkung hat - schon bei 1000 halte ich den Unterschied - 2 Zehntel gegen 2 Hundertstel - fuer signifikant.

"Haushaltsüblich" wäre wohl das passendere Wort gewesen. Damit meinte ich eine bis wenige Anwendungen pro Script. Bei Stringverarbeitung ist selten das Ergebnis irrelevant, so dass mit mehr Anwendungen auch mehr Daten entstehen, die beispielsweise weitertransportiert werden müssen. Die meiste Zeit geht prozentual bei diesen Vorgängen drauf, so dass das Optimieren beim Erzeugen/Berechnen das Kraut nicht fett macht.

Anders ist die Sachlage bei mathematischen Problemen wo viele Rechenschritte notwendig sind, um zu einem relativ kleinen Ergebnis zu kommen (Hashwert oder Apfelmännchen berechnen, um nur mal zwei zu nennen). So etwas in PHP lösen zu wollen, gehört mit langer Laufzeit bestraft.

Uebrigens: Die substr()-Loesung sieht ohne Zweifel huebscher aus. Aber ich z.B. haette vorher nicht auswendig gewusst, dass mir substr($string, -1) das letzte Zeichen liefert, waehrend die Array-Schreibweise selbsterklaerend ist. Daher koennte ich nicht behaupten, dass die substr()-Variante fuer Noobs wie mich lesbarer ist.

Ja, aber auch das Abziehen von 1 von der Stringlänge ist für einen, der das zum ersten Mal sieht, nicht unbedingt selbsterklärend.

So oder so lohnt es sich, die Alternativen zu kennen.

Das allerdings.

Lo!

[Bademeister]

Um nicht als argumentativer Verlierer dazustehen [...] kommt in solchen Situationen recht schnell und pauschal das Performance-Argument, [...]

Ich weiss sehr gut, was Du meinst. Aber hier gab es ueberhaupt keine gegenlaeufigen Argumentationen, bis Du(!) die verschiedenen Loesungsvorschlaege verglichen hast. Ich hatte zunaechst lediglich eine Alternative zu Svens Loesung gegeben, und ueberhaupt nicht bewertet, welche besser ist. Und dass auch mein letzter Beitrag keine Bewertung sein sollte, sondern im Gegenteil, dass eben diese Bewertung nur im individuellen Anwendungsfall geschehen kann, habe ich mit dem letzten Absatz ("Aber ich will hier jetzt nicht dickkoepfig sein") deutlich machen wollen.

ohne zu wissen, ob im konkreten Anwendungsfall der Gewinn einen Nutzen bringt.

Das verstehe ich nicht. Solange ich den konkreten Anwendungsfall nicht kenne, ist doch Performance durchaus ein Aspekt. Erst dann, wenn ich ihn kenne, kann ich entscheiden, dass er mich nicht interessiert, und ihn daher vernachlaessigen.

Genau, keiner merkt etwas davon. Aber der Programmierer hatte damit Arbeit. Wenn dann auch noch der entstandene Code schwerer als üblich oder notwendig verständlich ist, ...

Dann sage ich nochmals, aber wieder ohne dickkoepfig sein zu wollen ;-): Ich kann nicht nachvollziehen, dass der Code schwerer verstaendlich sein soll - ganz im Gegenteil. Aber das ist gar nicht so sehr mein Aspekt gewesen.

Insgesamt entnehme Deiner Argumentation, dass Du meine Erwaehnung der alternativen Moeglichkeit zur Loesung des Problems des OP fuer kontraproduktiv und daher nicht gerechtfertigt haeltst. Das kann ich ehrlich gesagt nicht nachvollziehen.

Viele Gruesse,
der Bademeister

[dedlfix]

Hi!

Um nicht als argumentativer Verlierer dazustehen [...] kommt in solchen Situationen recht schnell und pauschal das Performance-Argument, [...]

Ich weiss sehr gut, was Du meinst. Aber hier gab es ueberhaupt keine gegenlaeufigen Argumentationen, bis Du(!) die verschiedenen Loesungsvorschlaege verglichen hast. Ich hatte zunaechst lediglich eine Alternative zu Svens Loesung gegeben, und ueberhaupt nicht bewertet, welche besser ist. Und dass auch mein letzter Beitrag keine Bewertung sein sollte, sondern im Gegenteil, dass eben diese Bewertung nur im individuellen Anwendungsfall geschehen kann, habe ich mit dem letzten Absatz ("Aber ich will hier jetzt nicht dickkoepfig sein") deutlich machen wollen.

Es gibt da so einen Spruch: Wenn du zwei Lösungen zur Verfügung hast, nimm die einfachere. Solche Regeln gelten zwar nicht immer, aber ganz unwahr sind sie auch nicht. Die einfachere ist nicht unbedingt die mit der geringsten Tipparbeit, aber ein Funktionsaufruf erschien mir weniger komplex als Funktionsaufruf plus rechnen plus Teilstringzugriff.

ohne zu wissen, ob im konkreten Anwendungsfall der Gewinn einen Nutzen bringt.
Das verstehe ich nicht. Solange ich den konkreten Anwendungsfall nicht kenne, ist doch Performance durchaus ein Aspekt. Erst dann, wenn ich ihn kenne, kann ich entscheiden, dass er mich nicht interessiert, und ihn daher vernachlaessigen.

Gut, das kann man auch so herum argumentieren und es ist ebenfalls schlüssig. Doch solange nicht explizit Schnelligkeit verlangt wird, sehe ich diese Mikromaldifferenzen (man kann minimal steigern! :-) als irrelevant an, da sie in den meisten Fällen keine Punkte bringen. Was anderes ist es natürlich, wenn es um deutliche Zeitfresser geht, wie ungünstige Datenbankabfragen, also solche, bei denen schon bei einer Verwendung ein Unterschied besteht, der nicht im Grundrauschen untergeht.

Genau, keiner merkt etwas davon. Aber der Programmierer hatte damit Arbeit. Wenn dann auch noch der entstandene Code schwerer als üblich oder notwendig verständlich ist, ...
Dann sage ich nochmals, aber wieder ohne dickkoepfig sein zu wollen ;-): Ich kann nicht nachvollziehen, dass der Code schwerer verstaendlich sein soll - ganz im Gegenteil. Aber das ist gar nicht so sehr mein Aspekt gewesen.

Ich wollte das jetzt nicht speziell auf den Fall bezogen sehen, sondern generell.

Insgesamt entnehme Deiner Argumentation, dass Du meine Erwaehnung der alternativen Moeglichkeit zur Loesung des Problems des OP fuer kontraproduktiv und daher nicht gerechtfertigt haeltst. Das kann ich ehrlich gesagt nicht nachvollziehen.

Als kontraproduktiv sehe ich sie überhaupt nicht an, nur als die aufwendigere - für den Programmierer und Codeleser, intern scheint sie das ja deiner Messungen zufolge nicht zu sein.

Lo!