Check, ob 1. Zeichen eines Strings eine Zahl ist

[duddle]

Ja, moin, den brauch ich ^^

Ich würd jetzt den String mit str_split($string) in ein Array aufsplitten und das beim ersten Arrayfeld mit is_numeric checken.

Weiß da jemand was eleganteres?

gruß
duddle

[Tobias Kloth]

Hallo duddle,

Ich würd jetzt den String mit str_split($string) in ein Array aufsplitten und das beim ersten Arrayfeld mit is_numeric checken.

Einfacher wäre wohl is_numeric($string{0})

Grüße aus Nürnberg
Tobias

[duddle]

hallo Tobias,

genau sowas hatte ich mir erhofft, danke!

gruß
duddle

[André Laugks]

Hallo!

Weiß da jemand was eleganteres?

$string = "6foobar";

if(preg_match('/^[1]/', $string)) {
   /* Zahl an erster Stelle */
}

André Laugks

---

1. 0-9 ↩︎

[André Laugks]

Besser ist:

$string = "6foobar";

if(preg_match('/^[1]/', $string)) {
   /* Zahl an erster Stelle */
}

$string = "6foobar";

if(preg_match('/^[2]/', trim($string))) {
   /* Zahl an erster Stelle */
}

André Laugks

---

1. 0-9 ↩︎

2. 0-9 ↩︎

[Tobias Kloth]

Hallo André,

$string = "6foobar";
if(preg_match('/^[1]/', trim($string))) {

naja - das ist aber sehr teuer für so eine einfache Prüfung ...

Grüße aus Nürnberg
Tobias

---

1. 0-9 ↩︎

[Christoph Zurnieden]

Hi,

$string = "6foobar";
if(preg_match('/^[1]/', trim($string))) {
naja - das ist aber sehr teuer für so eine einfache Prüfung ...

Ja, so ein kompletter regulärer Ausdruck erscheint auch mir da unangemessen ;-)

  
/*ASCII only!*/  
$string = "6foobar";  
if((ord($string{0})-48)<10&&(ord($string{0})-48)>=0){  
  /* et is einer */  
}  
/* et is keiner */  

trim() ist übrigens falsch, da es um das erste Zeichen ging und niemand behauptet hat, das es kein Leerzeichen sein darf.

so short

Christoph Zurnieden

---

1. 0-9 ↩︎

[André Laugks]

Hallo!

trim() ist übrigens falsch, da es um das erste Zeichen ging und niemand behauptet hat, das es kein Leerzeichen sein darf.

Ich enthalte mich hier...

André Laugks

[Christoph Zurnieden]

Hi,

Ich enthalte mich hier...

Das sei gar nicht gesund sagt C. G. Jung.

so short

Christoph Zurnieden

[duddle]

hallo Christoph,

Ja, so ein kompletter regulärer Ausdruck erscheint auch mir da unangemessen ;-)

/ASCII only!/
$string = "6foobar";
if((ord($string{0})-48)<10&&(ord($string{0})-48)>=0){
  /* et is einer /
}
/ et is keiner */

  
Daraus schließe ich, dass den Ziffern 0 bis 9 die ASCII-Werte 48 bis 57 zugeordnet sind?  
Und das ist jetzt eine weniger rechenleistungsaufwändigere Variante als die von André oder is\_numeric($string{0})?  
  

> trim() ist übrigens falsch, da es um das erste Zeichen ging und niemand behauptet hat, das es kein Leerzeichen sein darf.  
  
Da hast du Recht. Aber ich denke, die Wahrscheinlichkeit, dass das trim stört ist geringer als die Wahrscheinlichkeit, dass der Fragenstellende es benötigt, aber vergessen hat.  
Mein $string ist jedoch schon vorher getrimt. ;)  
  
gruß  
duddle

[André Laugks]

Hallo!

Daraus schließe ich, dass den Ziffern 0 bis 9 die ASCII-Werte 48 bis 57 zugeordnet sind?
Und das ist jetzt eine weniger rechenleistungsaufwändigere Variante als die von André oder is_numeric($string{0})?

Danke! :-)

Da hast du Recht. Aber ich denke, die Wahrscheinlichkeit, dass das trim stört ist geringer als die Wahrscheinlichkeit, dass der Fragenstellende es benötigt, aber vergessen hat.

Danke! :-)

André Laugks

[Christoph Zurnieden]

Hi,

Daraus schließe ich, dass den Ziffern 0 bis 9 die ASCII-Werte 48 bis 57 zugeordnet sind?

Wie kommst Du denn darauf? ;-)

Und das ist jetzt eine weniger rechenleistungsaufwändigere Variante als die von André

Ja.

oder is_numeric($string{0})?

Das ist eine gute Frage, ich nehme aber an das is_numeric() ebenfalls langsamer ist, da es erstens auch auf einen ganzen String angewandt werden kann und zweitens locale-abhängig ist.

Mein Codeschnippsel ist nichts anderes als das normale isdigit() aus ctypes.h. Kann man auch noch als Tabellenlookup ausführen, aber man kann's auch übertreiben.

Da hast du Recht. Aber ich denke, die Wahrscheinlichkeit, dass das trim stört ist geringer als die Wahrscheinlichkeit, dass der Fragenstellende es benötigt, aber vergessen hat.

Naja, es sollte aber doch der eherne Grundsatz gelten: nicht mehr als nötig.

BTW: verlangt wurde übrigens eine _elegante_ Lösung. Ich habe versucht eine zu liefern.

so short

Christoph Zurnieden

[duddle]

Hi,

Naja, es sollte aber doch der eherne Grundsatz gelten: nicht mehr als nötig.

Das Optimum wäre gewesen: Man schreibt es nicht schon in den Code, sondern gibt einen Hinweis, das trimmen nicht zuvergessen, falls es benötigt wird.

BTW: verlangt wurde übrigens eine _elegante_ Lösung. Ich habe versucht eine zu liefern.

Wenn du es schon so genau nimmst, dann bitte konsequent: Gefragt wurde nach einer _eleganteren_ Lösung - und eleganter als den ganzen String Buchstabe für Buchstabe in ein riesiges Array aufzusplitten um davon dann das erste Feld mit is_numeric zu checken, waren alle Lösungen! ;D

Aber danke für das Aufzeigen der verschiedenen Möglichkeiten!

gruß
duddle

[fastix®]

Moin!

und eleganter als den ganzen String Buchstabe für Buchstabe in ein riesiges Array aufzusplitten um davon dann das erste Feld mit is_numeric zu checken, waren alle Lösungen! ;D

if((ord($string{0})-48)<10&&(ord($string{0})-48)>=0){
  /* et is einer */
}

Hat er aber doch gar nicht gemacht. Es sind geschweifte Klammern.
$str{0} liefert genau das erste Zeichen des Strings in $str zurück.

Array? Nada!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[duddle]

Hallo fastix, ich meinte ja auch _meinen_ Ausgangspost!
gruß
duddle

[Christoph Zurnieden]

Hi,

Naja, es sollte aber doch der eherne Grundsatz gelten: nicht mehr als nötig.
Das Optimum wäre gewesen: Man schreibt es nicht schon in den Code, sondern gibt einen Hinweis, das trimmen nicht zuvergessen, falls es benötigt wird.

Wozu? Was hat ein trim() mit der Anforderung zu tun, das erste Zeichen eines Strings auf isdigit() zu prüfen? Rein gar nix, oder?
Ihr seid doch alle so hinter OOP her, warum haltet ihr euch dann nicht daran?

BTW: verlangt wurde übrigens eine _elegante_ Lösung. Ich habe versucht eine zu liefern.

Wenn du es schon so genau nimmst, dann bitte konsequent: Gefragt wurde nach einer _eleganteren_ Lösung

Nein, meine Wortwahl war durchaus beabsichtigt, ich hatte den Positiv nicht übersehen.
Denn:

• und eleganter als den ganzen String Buchstabe für Buchstabe in ein riesiges Array aufzusplitten um davon dann das erste Feld mit is_numeric zu checken, waren alle Lösungen! ;D

is_numeric() ist für einen ganzen String vorgesehen (ähnlich strtol() und Anverwandte). Diese Funktion auf ein einzelnes Zeichen angewandt bedeutet mit Kanonen auf Spatzen zu schießen. Das ist nicht gerade eleganter geschweige denn überhaupt elegant.
Warum die ganzen Funktionen aus ctypes.h/wctype.h nicht in PHP gewandert sind wundert mich etwas, vielleicht war ich aber auch nur zu blöd sie zu finden.

Aber danke für das Aufzeigen der verschiedenen Möglichkeiten!

Die schnellste Möglichkeit (Tabellenlookup mit O(1)) hatte ich ja auch schon angerissen. Das war's dann aber auch schon, mehr gibt's nicht. (Es gibt noch die Möglichkeit des Bitschuppsens, aber das spart auf den verbreiteten Architekturen nichts und ist deshalb auch nicht eleganter)

so short

Christoph Zurnieden

[dedlfix]

echo $begrüßung;

Warum die ganzen Funktionen aus ctypes.h/wctype.h nicht in PHP gewandert sind wundert mich etwas, vielleicht war ich aber auch nur zu blöd sie zu finden.

Hier sind sie: http://de2.php.net/manual/en/ref.ctype.php

echo "$verabschiedung $name";

[Christoph Zurnieden]

Hi,

Warum die ganzen Funktionen aus ctypes.h/wctype.h nicht in PHP gewandert sind wundert mich etwas, vielleicht war ich aber auch nur zu blöd sie zu finden.

Hier sind sie: http://de2.php.net/manual/en/ref.ctype.php

Ah, spät (erst ab 4.3.0) und aus unerfindlichen Gründen ander benamst (wozu das "ctype_" Präfix anstatt(!) des "is"?) aber immerhin wenigstens die ctypes.h Funktionen. Fehlen noch die Unicodeäquvalente aus wtype.h.

Aber zumindest scheint es auch anderen so zu gehen, wie mir -- sie sind genau so blöd? --  denn der erste Satz im einzigem Kommentar lautet auch direkt:
"As noted above unfortunately many PHP developers are seemingly unaware of these functions and are still using less  efficient equivalents."

;-)

so short

Christoph Zurnieden

[dedlfix]

echo $begrüßung;

"As noted above unfortunately many PHP developers are seemingly unaware of these functions and are still using less  efficient equivalents."

Nun, ich kann keinen signifikanten Laufzeitunterschied zwischen is_numeric($s{0}) und ctype_digit($s{0}) feststellen. Im Gegenteil, mal war das eine schneller, mal das andere.

Versuchsaufbau: [*]

define('LOOP', 100000);  
$s = '42foobar';  
  
$start = microtime(true);  
for ($i= 0; $i < LOOP; $i++)  
  $a = is_numeric($s{0});  
$ende = microtime(true);  
  
printf('%19f', $ende - $start);  
echo '<br>';  
  
$start = microtime(true);  
for ($i= 0; $i < LOOP; $i++)  
  $a = ctype_digit($s{0});  
$ende = microtime(true);  
  
printf('%19f', $ende - $start);  

echo "$verabschiedung $name";

[*] Getestet mit PHP 5.0. Wer 4.x verwenden möchte, sollte microtime_float() aus Example 1 verwenden.

[Christoph Zurnieden]

Hi,

Nun, ich kann keinen signifikanten Laufzeitunterschied zwischen is_numeric($s{0}) und ctype_digit($s{0}) feststellen. Im Gegenteil, mal war das eine schneller, mal das andere.

Es geht hier nicht um Laufzeit sondern um Komplexität. Das kann man schlecht messen, das muß man schon berechnen.
"See the source, Luke!" ;-)

so short

Cjhristoph Zurnieden

[Christian Kruse]

你好 dedlfix,

Nun, ich kann keinen signifikanten Laufzeitunterschied zwischen
is_numeric($s{0}) und ctype_digit($s{0}) feststellen.

Das liegt daran, dass die Eingabemenge nur ein Zeichen ist ;) Da fällt
das bei einer interpretierten Sprache nicht so sehr auf, dass da mehr
dahinter sitzt. Aber vertrau mir, ich habe im Source nachgeschaut,
is_nummeric() ist aufwändiger als ctype_digit().

再见,
 克里斯蒂安

[dedlfix]

echo $begrüßung;

Nun, ich kann keinen signifikanten Laufzeitunterschied zwischen
is_numeric($s{0}) und ctype_digit($s{0}) feststellen.

Das liegt daran, dass die Eingabemenge nur ein Zeichen ist ;)

Ich habe meinen Versuchsaufbau nochmal mit dem gesamten String (8 Zeichen) wiederholt und konnte nun eine geringfüging längere Laufzeit von is_numeric() feststellen. Bei 10.000 Schleifendurchläufen waren es durchschnittlich ungefähr anderthalb Mikrosekunden. Das ist meiner Meinung nach praktisch immer noch vernachlässigbar.

Da fällt das bei einer interpretierten Sprache nicht so sehr auf, dass da mehr dahinter sitzt.

PHP ist seit Version 4 keine interpretierte Sprache mehr. Es findet eine Bytecode-Kompilierung statt.

Aber vertrau mir, ich habe im Source nachgeschaut, is_nummeric() ist aufwändiger als ctype_digit().

Das tat ich auch (das Nachschauen). Jedoch bin ich des C nicht mächtig genug, deswegen schwieg ich darüber. Ich fand jedoch in beiden Funtionen einen Verweis auf das gleiche Makro (Z_TYPE_irgendwas, wenn ich mich recht erinnere (und das als Macro richtig erkannt habe)), das, so schien es mir die eigentliche Prüfung vornimmt.

echo "$verabschiedung $name";

[Christian Kruse]

你好 dedlfix,

Nun, ich kann keinen signifikanten Laufzeitunterschied zwischen
is_numeric($s{0}) und ctype_digit($s{0}) feststellen.

Das liegt daran, dass die Eingabemenge nur ein Zeichen ist ;)

Ich habe meinen Versuchsaufbau nochmal mit dem gesamten String (8
Zeichen) wiederholt und konnte nun eine geringfüging längere Laufzeit
von is_numeric() feststellen.

Das liegt daran, dass das umwandeln von 8 Zeichen in eine Zahl nunmal sehr
schnell geht auf heutigen Systemen ;) Sitzt ja auch nicht viel hinter.
Nichts desto trotz kann man einwandfrei ausrechnen, dass die Komplexität
von is_nummeric() höher ist. Das wirkt sich allerdings nicht immer auf
die Laufzeit aus, das hatte dir Christoph aber ja auch schon gesagt.

Da fällt das bei einer interpretierten Sprache nicht so sehr auf, dass
da mehr dahinter sitzt.

PHP ist seit Version 4 keine interpretierte Sprache mehr. Es findet eine
Bytecode-Kompilierung statt.

Eh, und warum sollte es keine interpretierte Sprache mehr sein? Nur weil
Bytecode durch eine VM geschickt wird? ;) Das ist auch eine Sprache und
die wird auch interpretiert. Nene, Kamerad, natürlich ist PHP auch
weiterhin eine interpretierte Sprache. :)

Aber vertrau mir, ich habe im Source nachgeschaut, is_nummeric() ist
aufwändiger als ctype_digit().

Das tat ich auch (das Nachschauen). Jedoch bin ich des C nicht mächtig
genug, deswegen schwieg ich darüber. Ich fand jedoch in beiden Funtionen
einen Verweis auf das gleiche Makro (Z_TYPE_irgendwas, wenn ich mich
recht erinnere (und das als Macro richtig erkannt habe)), das, so schien
es mir die eigentliche Prüfung vornimmt.

Nein, es ist etwas komplexer. Bei is_numeric() wird, sofern der interne
Datentyp nicht eh schon „Zahl“ ist, is_numeric_string() aufgerufen. Bei
ctype_digit() dagegen wird direkt isdigit() aufgerufen (CTYPE(isdigit), wobei das Makro CTYPE() nur noch ein paar Typechecks macht; bei einem
String wird dann halt zeichenweise durchgegangen und isdigit() auf jedes
Zeichen angewand). Zugegeben, es wird nicht viel Zeit gespart, aber doch
ein wenig, es entfällt die „* 10 + <nummer>“-Operation. Am deutlichsten
dürftest du es merken bei einer sehr langen Zahl, die an die Grenzen des
long-Bereichs gehen. Leichte Abänderung deines Codes:

  
<?php  
define('LOOP', 100000);  
$s = '489249237492384732947239429472394724';  
  
$start = microtime_float();  
for ($i= 0; $i < LOOP; $i++)  
  $a = is_numeric($s);  
$ende = microtime_float();  
  
printf('%19f', $ende - $start);  
echo '<br>';  
  
$start = microtime_float();  
for ($i= 0; $i < LOOP; $i++)  
  $a = ctype_digit($s);  
$ende = microtime_float();  
  
printf('%19f', $ende - $start);  
  
function microtime_float() {  
  list($usec, $sec) = explode(" ", microtime());  
  return ((float)$usec + (float)$sec);  
}  
?>  

Dabei solltest du sich deutlich unterscheidende Zeiten bekommen. Ich
bekomme für ctype_digit() etwas weniger als die Hälfte an Laufzeit wie
bei is_nummeric().

再见,
 克里斯蒂安

[dedlfix]

echo $begrüßung;

Dabei solltest du sich deutlich unterscheidende Zeiten bekommen. Ich
bekomme für ctype_digit() etwas weniger als die Hälfte an Laufzeit wie
bei is_nummeric().

Na gut, überredet. Wenn nach 2 Ziffern schon Buchstaben kommen, wie in meinem Teststring, dann bricht die Prüfung schon dort ab, und der Laufzeitunterschied ist noch nicht der Rede wert, egal wie lang der String hintenraus noch wird. Je mehr Ziffern am Anfang stehen, desto größer wird der Unterschied.

echo "$verabschiedung $name";

[Christian Kruse]

你好 dedlfix,

Dabei solltest du sich deutlich unterscheidende Zeiten bekommen. Ich
bekomme für ctype_digit() etwas weniger als die Hälfte an Laufzeit wie
bei is_nummeric().

Na gut, überredet. Wenn nach 2 Ziffern schon Buchstaben kommen, wie in
meinem Teststring, dann bricht die Prüfung schon dort ab, und der
Laufzeitunterschied ist noch nicht der Rede wert, egal wie lang der String
hintenraus noch wird. Je mehr Ziffern am Anfang stehen, desto größer wird
der Unterschied.

Jupp. Sagte ich ja ;) Die Komplexität von ctype_digit() ist geringer. Nicht
alle Theorie ist grau ;)

再见,
 克里斯蒂安

[dedlfix]

echo $begrüßung;

Nicht alle Theorie ist grau ;)

Ja, ja. Die Theoretiker wissen alles, können aber nichts. Die Praktiker können alles, wissen aber nicht warum das funktioniert. Und ich bin eine Mischung aus beiden. Ich krieg nichts zustande und weiß auch nicht woran das liegt.

Aber mal was ganz anderes. Hat sich die Forumssoftware nicht über dein ungünstiges Zitat-Anwort-Verhältnis beschwert? :-)

echo "$verabschiedung $name";

P.S. Wenn die Forumsbeschwerde einmal ignoriert wurde, kommt sie nie wieder, egal wie oft man korrigiert und vorschaut. Kannst du da noch ein Kästchen einbauen, dass diese Prüfung wieder einschaltet?

[Christian Kruse]

你好 dedlfix,

Aber mal was ganz anderes. Hat sich die Forumssoftware nicht über dein
ungünstiges Zitat-Anwort-Verhältnis beschwert? :-)

Doch, hat sie ;)

P.S. Wenn die Forumsbeschwerde einmal ignoriert wurde, kommt sie nie
wieder, egal wie oft man korrigiert und vorschaut. Kannst du da noch ein
Kästchen einbauen, dass diese Prüfung wieder einschaltet?

Mal sehen. In nächster Zeit allerdings nicht, da werde ich erstmal Block
zuende bauen und mich auf die letzte Prüfung für dieses Semester vorbereiten.
Und das Self-Treffen ist ja auch noch… argh!

再见,
 克里斯蒂安

[duddle]

hallo,

mal ne nebensächliche Frage:

define('LOOP', 100000);

Warum benutzt ihr dieses tipp-aufwändigere define und schreibt nicht einfach $loop = 100000; und dann for ($i= 0; $i < $loop; $i++)?

Was bezweckt dieses definieren?

gruß
duddle

[Christian Kruse]

你好 duddle,

define('LOOP', 100000);

Warum benutzt ihr dieses tipp-aufwändigere define und schreibt nicht
einfach $loop = 100000; und dann for ($i= 0; $i < $loop; $i++)?

Es ist semantisch ein Unterschied. Sozusagen für Korinthenkacker, um es ganz
sauber[tm] zu machen ;) Semantisch ist an der Stelle nämlich eine Konstante,
keine Variable gemeint.

再见,
 克里斯蒂安

[dedlfix]

echo $begrüßung;

define('LOOP', 100000);
Warum benutzt ihr dieses tipp-aufwändigere define und schreibt nicht einfach $loop = 100000;
Was bezweckt dieses definieren?

Es ist ein feststehender Wert. Er ändert sich nicht während der Scriptlaufzeit und muss deshalb auch keine Variable sein.
Für mich ist es auch nicht tippaufwendig, da meine IDE mit <d><Leertaste> bereits ein define('|', ^); hinschreibt. | steht für die Cursorposition und ^ für eine mit einem Tastendruck erreichbare Sprungmarke.

Ein weiterer (hier nicht genutzter) Vorteil von Konstanten gegenüber Variablen ist, dass Konstanten immer global sind, sie stehen damit auch in Funktionen direkt zur Verfügung.

echo "$verabschiedung $name";

[Christian Kruse]

你好 Christoph,

[…] ich hatte den Positiv nicht übersehen […]

Du meinst, du hattest den Komparativ nicht übersehen ;) Der Positiv ist die
ungesteigerte Form. Positiv – Komparativ – Superlativ. Und die Formen, die
man nicht steigern kann, nennt man Elativ. Einzig ist ein beliebtes
Beispiel ;)

Aber danke für das Aufzeigen der verschiedenen Möglichkeiten!

Die schnellste Möglichkeit (Tabellenlookup mit O(1))

Naja, deine Lösung ist ja auch O(1) :) Allerdings ein vermutlich
langsameres O(1) als der Tabellen-Lookup. Aber man kann es wirklich
übertreiben ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

[…] ich hatte den Positiv nicht übersehen […]

Du meinst, du hattest den Komparativ nicht übersehen ;)

Ja, genau, und ich hatte den Positiv mit Absicht benutzt. So herum ist's natürlich richtig. Naja, kann passieren in der Eile.
Und außerdem: wer im Glashaus sitzt ... gelle? ;-)

Aber danke für das Aufzeigen der verschiedenen Möglichkeiten!

Die schnellste Möglichkeit (Tabellenlookup mit O(1))

Naja, deine Lösung ist ja auch O(1) :)

Ja, ich weiß, ich muß mir wirklich mal angewöhnen, die korrekten Bezeichnungen zu benutzen ;-)

Allerdings ein vermutlich
langsameres O(1) als der Tabellen-Lookup. Aber man kann es wirklich
übertreiben ;)

Mmh... ich glaube sogar, das die Tabelle langsamer ist, da sie ja erstmal geladen werden muß. Sie dürfte auch je nach Prozessor zu groß sein längere Zeit im L0 gehalten zu werden.
Aber jetzt wird's wirklich übertrieben ;-)

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

[… Positiv vs. Komparativ …]
Und außerdem: wer im Glashaus sitzt ... gelle? ;-)

Hehe, jajajaja. Schon gut, schon gut, ich sag nix mehr *g*

再见,
 克里斯蒂安

[Gunnar Bittersmann]

Christian,

Und die Formen, die man nicht steigern kann, nennt man Elativ. Einzig ist ein beliebtes Beispiel ;)

Aber nicht das einzigste. ;-) SCNR.

Live long and prosper,
Gunnar

[Christian Kruse]

你好 Christoph,

oder is_numeric($string{0})?

Das ist eine gute Frage, ich nehme aber an das is_numeric() ebenfalls
langsamer ist, […]

Ja, aber aus anderen Gründen als du vermutest ;)

[…] da es erstens auch auf einen ganzen String angewandt werden kann und
zweitens locale-abhängig ist.

Es ist nicht locale-abhängig, aber es versucht den String umzuwandeln in
eine Zahl (mittels is_nummeric_string() aus Zend/zend_operators.h). Es
beachtet dabei allerdings auch Hex-Zahlen, das tut deine Lösung nicht ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Ja, aber aus anderen Gründen als du vermutest ;)

Oh, ich habe Recht, nur nicht in den Gründen? Ach, was scheren mich die Gründe, hauptsache ich habe Recht! ;-)

[…] da es erstens auch auf einen ganzen String angewandt werden kann und
zweitens locale-abhängig ist.

Es ist nicht locale-abhängig,

Sagt doch php.net? Ah, nein, da habe ich mich vertan, sorry.

aber es versucht den String umzuwandeln in
eine Zahl (mittels is_nummeric_string() aus Zend/zend_operators.h).

Gut, wenn man in die Quellen schaut ist's natürlich einfach! ;-)

Es
beachtet dabei allerdings auch Hex-Zahlen, das tut deine Lösung nicht ;)

War weder verlangt noch bezahlt und wird auch freiwillig nicht geliefert.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Ja, aber aus anderen Gründen als du vermutest ;)

Oh, ich habe Recht, nur nicht in den Gründen? Ach, was scheren mich die
Gründe, hauptsache ich habe Recht! ;-)

Hehe, schon klar ;-))

aber es versucht den String umzuwandeln in
eine Zahl (mittels is_nummeric_string() aus Zend/zend_operators.h).

Gut, wenn man in die Quellen schaut ist's natürlich einfach! ;-)

Nur wenn man in den Code guckt, kann man sicher sein ;)

Es
beachtet dabei allerdings auch Hex-Zahlen, das tut deine Lösung nicht ;)

War weder verlangt noch bezahlt und wird auch freiwillig nicht geliefert.

Stimmt – war auch nur ein harmloser Einwurf ;-)

再见,
 克里斯蒂安

[André Laugks]

Hallo!

naja - das ist aber sehr teuer für so eine einfache Prüfung ...

Ohje, aber ein nicht so kleiner regulärer Ausdruck!

André Laugks

[Tobias Kloth]

Hallo André,

naja - das ist aber sehr teuer für so eine einfache Prüfung ...
Ohje, aber ein nicht so kleiner regulärer Ausdruck!

Ob groß oder klein ist relativ egal - die "Maschine" zum Auswerten des regulären Ausdrucks muss so und so angeworfen werden.

Grüße aus Nürnberg
Tobias

[Christoph Zurnieden]

Hi,

Ob groß oder klein ist relativ egal - die "Maschine" zum Auswerten des regulären Ausdrucks muss so und so angeworfen werden.

Ist die RegEx-Maschine von PHP denn derart schlecht? Wird da nicht optimiert? Ist der Overhead des Automatengenerators so riesig? Nein, das glaube ich einfach nicht.
Oder etwa doch? >;->

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Ob groß oder klein ist relativ egal - die "Maschine" zum Auswerten des
regulären Ausdrucks muss so und so angeworfen werden.

Ist die RegEx-Maschine von PHP denn derart schlecht? Wird da nicht
optimiert? Ist der Overhead des Automatengenerators so riesig?

Hehe ;-) Müsste man meinen, gelle? ;-) Aber PHP benutzt in diesem Fall nur
externe Bibliotheken. ereg_* benutzt die POSIX-Regexe aus der glibc und
preg_* benutzt die PCRE aus der libpcre – während die PCRE-Engine recht
gut optimiert ist, ist die glibc-Engine häufig buggy und lahmarschig ;)
Auf amd64-Maschinen gibt z. B. „^/?abc“ einen Endlos-Loop.

Aber trotzdem ist ein einfaches if(is_nummeric($str{0})) do_something(); viel schneller ;)

再见,
 克里斯蒂安

[Vinzenz Mai]

Hi Christian,

if(is_nummeric($str{0})) do_something();

^
------------|

ist PHP nun auf die neue deutsche Rechtschreibung hin optimiert? *fg*

Freundliche Grüße

Vinzenz

[Christian Kruse]

你好 Vinzenz,

if(is_nummeric($str{0})) do_something();
            ^
------------|

ist PHP nun auf die neue deutsche Rechtschreibung hin optimiert? *fg*

Hehe, was ein Faux Pax ;)

再见,
 克里斯蒂安

[dedlfix]

echo $begrüßung;

Hehe, was ein Faux Pax ;)

Hehe, das auch ;)

echo "$verabschiedung $name";

[Christian Kruse]

你好 dedlfix,

Hehe, was ein Faux Pax ;)

Hehe, das auch ;)

Ich sage jetzt gar nichts mehr! ;-)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Au Mann, da dachte ich, es wäre Wochenende und dann geh ich blöden Hund doch noch an's Telephon
*sigh*
;-}

Aber PHP benutzt in diesem Fall nur
externe Bibliotheken. ereg_* benutzt die POSIX-Regexe aus der glibc und
preg_* benutzt die PCRE aus der libpcre

Aha, gut zu wissen.

– während die PCRE-Engine recht
gut optimiert ist, ist die glibc-Engine häufig buggy und lahmarschig ;)

Nä Du, das "häufig" kannst Du getrost streichen (Zumindest habe ich jedesmal Malesse damit, ich weiß gar nicht, warum ich das immer noch versuche). Da fummeln die schon Jahre rum und ich bezweifele ernsthaft, das das jemals etwas wird.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Au Mann, da dachte ich, es wäre Wochenende und dann geh ich blöden Hund
doch noch an's Telephon

Den Fehler _nicht_ zu machen lernt man doch in den ersten 14 Tagen *g*

– während die PCRE-Engine recht
gut optimiert ist, ist die glibc-Engine häufig buggy und lahmarschig ;)

Nä Du, das "häufig" kannst Du getrost streichen (Zumindest habe ich
jedesmal Malesse damit, ich weiß gar nicht, warum ich das immer noch
versuche). Da fummeln die schon Jahre rum und ich bezweifele ernsthaft,
das das jemals etwas wird.

Ja, das bezweifle ich inzwischen auch. Spätestens seitdem die
Endlosschleifen auf AMD64-Systemen aufgetreten sind (weswegen ich etwa
zwei Stunden lang nach dem Fehler gesucht habe, beim Apache, habe mich da
mit gdb dahinter hängen müssen) ist die Engine wirklich in meiner
Wertachtung gesunken ;)

再见,
 克里斯蒂安

[André Laugks]

Hallo!

Ob groß oder klein ist relativ egal - [...]

War nicht ganz so ernst gemeint!

[...] - die "Maschine" zum Auswerten des regulären Ausdrucks muss so und so angeworfen werden.

Du tust so, als ob das 80% der CPU und RAM beansprucht.

Schön mit Stringfunktionen arbeiten um Rechnerpower einzusparen, aber dafür tonnenweise SQL-Statements abfeuern. Schon 1000mal gesehen...

André Laugks