IsNumeric Abfrage - zur Überprüfung

[BigPeter]

Irgendwie habe ich ein kleines Javascript Problem.

Erstmal der Code :

<form name="add" action="db/gallery_add.php" method="post" onsubmit="return add_check()">  
<table cellpadding="1" cellspacing="0" border="0">  
  <tr>  
    <td>Name</td>  
    <td><input type="text" size="30" maxlength="30" name="name"></td>  
  </tr>  
  <tr>  
    <td>Nummer</td>  
    <td><input type="text" size="4" maxlength="4" name="nr"></td>  
  </tr>  
  <tr>  
    <td>Auswahl</td>  
    <td><select size="1" name="auswahl">  
          <option value="0" selected>- auswählen -</option>  
          <option value="1">Auswahl A</option>  
          <option value="2">Auswahl B</option>  
          <option value="3">Auswahl C</option>  
    </select></td>  
  </tr>  
  <tr>  
    <td colspan="2"><input type="submit" value="hinzufügen"></td>  
  </tr>  
</table>  
</form>

function add_check() {  
 // Variablen vereinfachen  
 a = document.add;  
 // Überprüfen auf Eingaben  
 if(a.name.value == '') {alert('Bitte Namen angeben'); return false;}  
 if(a.nr.value   == '') {alert('Bitte Nummer angeben'); return false;}  
 if(IsNumeric(a.nr.value) == false) {alert('Bitte Zahlen eingeben'); return false;}  
 if(a.auswahl.value == '0') {alert('Bitte Marathon auswählen'); return false;}  
}

Wenn ich den "IsNumeric"-Term auskommentiere klappt alles tadellos.
Was mache ich falsch bei der IsNumeric Abfrage ? :/

Liebe Grüße

BIG PETE !

[Kai345]

[latex]Mae  govannen![/latex]

Wenn ich den "IsNumeric"-Term auskommentiere klappt alles tadellos.
Was mache ich falsch bei der IsNumeric Abfrage ? :/

Solange du uns nicht deine IsNumeric-Funktion zeigst, wird das wohl niemand genau sagen können.

Stur lächeln und winken, Männer!
Kai

[BigPeter]

Solange du uns nicht deine IsNumeric-Funktion zeigst, wird das wohl niemand genau sagen können.

vergessen ... ist nun angehängt D:"

[BigPeter]

function IsNumeric(value) {
    var bool = isNaN(+value));
    bool = bool || (value.indexOf('.') != -1);
    bool = bool || (value.indexOf(",") != -1);
    return !bool;
}

[Vinzenz Mai]

Hallo Peter,

es ist eine sehr gute Idee, seinen Code zu kommentieren.

» function IsNumeric(value) {  

>     var bool = isNaN(+value));  

// zähle die Klammern!  
  

>     bool = bool || (value.indexOf('.') != -1);  
>     bool = bool || (value.indexOf(",") != -1);  // in diesem Code überflüssig  
>     return !bool;  
> }

Obwohl der Code nicht umfangreich ist, verstehe ich nicht, was die Funktion tun *soll*. Ich kann nachvollziehen, was sie macht (wenn fehlerfrei) und verstehe daher die Implementierung nicht.

Freundliche Grüße

Vinzenz

[Gunnar Bittersmann]

@@Vinzenz Mai:

nuqneH

Obwohl der Code nicht umfangreich ist, verstehe ich nicht, was die Funktion tun *soll*.

Ich vermute, sie soll auf eine Ganzzahl prüfen. Dann sollte sie aber nicht verwirrenderweise IsNumeric heißen, sondern bswp. isInt.

Und ja, es ist Konvention, Funktionsnamen in JavaScript mit kleinem Buchstaben zu beginnen. Mit großem Buchstaben fangen Bezeichner von Objekt(kontruktor)en an.

Qapla'

[Vinzenz Mai]

Hallo Gunnar,

Ich vermute, sie soll auf eine Ganzzahl prüfen. Dann sollte sie aber nicht verwirrenderweise IsNumeric heißen, sondern bswp. isInt.

ja, sowas in der Richtung tut sie. Deswegen ist die Prüfung auf Komma überflüssig, weil mit isNaN() in der ersten Zeile erledigt.
Die Funktion mag übrigens keine Zahlen als Übergabeparameter, sondern hätte gern Zeichenketten. Nennen wir sie daher

isStringRepresentationOfInt() ;-)

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo,

function IsNumeric(value) {
    var bool = isNaN(+value));
    bool = bool || (value.indexOf('.') != -1);
    bool = bool || (value.indexOf(",") != -1);
    return !bool;
}

du arbeitest mit invertierter Logik, scheint mir. Deine Hilfsvariable bool hat zunächst die Bedeutung "IsNotNumeric", und du gibst zum Schluss den Komplementärwert zurück.

Also bedeutet dein Code:
 * value ist *nicht* numerisch, wenn isNaN() zutrifft
 * value ist *nicht* numerisch, wenn kein Punkt darin vorkommt
 * value ist *nicht* numerisch, wenn kein Komma darin vorkommt

Du hast also ein Logikproblem. Deine Funktion verlangt, dass isNaN() nicht zutrifft, gleichzeitig aber mindestens ein Punkt und ein Komma im String vorkommt.

So long,
 Martin

[Der Martin]

Hi,

bool = bool || (value.indexOf('.') != -1);
    bool = bool || (value.indexOf(",") != -1);

* value ist *nicht* numerisch, wenn kein Punkt darin vorkommt
* value ist *nicht* numerisch, wenn kein Komma darin vorkommt

ah, sorry, mein Fehler: Ich hatte das != in Gedanken als == gelesen.

Du hast also ein Logikproblem. Deine Funktion verlangt, dass isNaN() nicht zutrifft, gleichzeitig aber mindestens ein Punkt und ein Komma im String vorkommt.

Dann ist meine Schlussfolgerung natürlich falsch:  Deine Funktion verlangt, dass isNaN() nicht zutrifft und *kein* Punkt sowie *kein* Komma vorkommt. Also doch eher das, was Gunnar schon abgeleitet hat.
Übrigens: Eingaben wie 5E-3 (also 0.005) würden ungestreift durchgehen ...

Ciao,
 Martin

[Vinzenz Mai]

Hallo Martin,

Übrigens: Eingaben wie 5E-3 (also 0.005) würden ungestreift durchgehen ...

was bestimmt nicht gewollt ist.
Hier scheint in der Tat ein RegExp die einfachere Lösung zu sein: ein optionales Vorzeichen, gefolgt von beliebig vielen Ziffern (des Dezimalsystems).

Freundliche Grüße

Vinzenz

[Vinzenz Mai]

Hallo Martin,

function IsNumeric(value) {
    var bool = isNaN(+value));
    bool = bool || (value.indexOf('.') != -1);
    bool = bool || (value.indexOf(",") != -1);
    return !bool;
}

du arbeitest mit invertierter Logik, scheint mir.

und schafft es durch intensive Verwendung dieser Dich erfolgreich zu verwirren.

Deine Hilfsvariable bool hat zunächst die Bedeutung "IsNotNumeric", und du gibst zum Schluss den Komplementärwert zurück.

Also bedeutet dein Code:
* value ist *nicht* numerisch, wenn isNaN() zutrifft
* value ist *nicht* numerisch, wenn kein Punkt darin vorkommt

Du übersiehst hier die doppelte Verneinung innerhalb der invertierten Logik:
 * value bleibt *nicht* numerisch, wenn ein Punkt nicht nicht gefunden wird,
   d.h. wenn ein Punkt darin gefunden wird ...

* value ist *nicht* numerisch, wenn kein Komma darin vorkommt

* value bleibt *nicht* numerisch, wenn ein Komma darin vorkommt
     (nicht nicht gefunden wird).
   Weil isNaN false zurückliefert, wenn ein Komma im Wert vorkommt,
   ist diese Prüfung überflüssig.

Gunnar und ich vermuten, dass Peter ganze Zahlen erkennen will.

Freundliche Grüße

Vinzenz

[Der Martin]

Hi Vinzenz,

du arbeitest mit invertierter Logik, scheint mir.
und schafft es durch intensive Verwendung dieser Dich erfolgreich zu verwirren.

stimmt, ich hatte es eben selbst gemerkt.

Gunnar und ich vermuten, dass Peter ganze Zahlen erkennen will.

Ich schließe mich inzwischen dieser Meinung an, aber dafür ist die Prüfung auch ungenügend - und gleichzeitig unnötig kompliziert.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Ich schließe mich inzwischen dieser Meinung an, aber dafür ist die Prüfung auch ungenügend - und gleichzeitig unnötig kompliziert.

Sinnvoll ist es wohl, nicht einen String zu überprüfen, sondern den sich daraus ergebenden numerischen Wert:

function isInt(number)  
{  
  return number == Math.floor(number);  
}

Qapla'

[Vinzenz Mai]

Hallo Gunnar,

Sinnvoll ist es wohl, nicht einen String zu überprüfen, sondern den sich daraus ergebenden numerischen Wert:

function isInt(number)

{
  return number == Math.floor(number);
}

  
das sieht sehr gut aus. RegExp, [wie von mir vorgeschlagen](https://forum.selfhtml.org/?t=205596&m=1393959), ist wieder mal Overkill.  
  
  
Freundliche Grüße  
  
Vinzenz

[zehbaeh]

function isInt(number)

{
  return number == Math.floor(number);
}

>   
> das sieht sehr gut aus. RegExp, [wie von mir vorgeschlagen](https://forum.selfhtml.org/?t=205596&m=1393959), ist wieder mal Overkill.  
  
Nicht wirklich:  
isInt('1e3') => true  
isInt('') => true  
  
Aus dem Kontext heraus (Nummer ist/soll sein Marathon-Nummern)  
~~~javascript
  
function isMarathonNumber(value) {  
   return (0 != value) && (null === String(value).match(/[^0-9]/));  
}  

[Gunnar Bittersmann]

@@zehbaeh:

nuqneH

isInt('1e3') => true

Was nicht so schlimm wäre, da 1000 ganzzahlig ist.

isInt('') => true

Hm, wenn man nichts als 0 wertet, stimmt das auch. ;-)

Aber OK, der Parameter soll kein String sein. Da war doch was mit den Typen …

function isInt(number)
{
  return number === Math.floor(number);
}

Drei Kreuze – äh Gleichheitszeichen gemacht.

return (0 != value) && (null === String(value).match(/[^0-9]/));

Da waren sie wieder, die zwei Probleme.

Qapla'

[Vinzenz Mai]

Hallo Gunnar,

Aber OK, der Parameter soll kein String sein. Da war doch was mit den Typen …

wenn man sich den Verwendungszweck anschaut, soll der Parameter ein String sein. Ich gehe sogar weiter: es muss ein String sein.

» function isInt(number)  

> {  
>   return number === Math.floor(number);  
> }

Drei Kreuze – äh Gleichheitszeichen gemacht.

return (0 != value) && (null === String(value).match(/[^0-9]/));

Da waren sie wieder, die zwei Probleme.

eh ja: Startnummern mit führenden Nullen sind mir noch nie begegnet. Letztes Jahr hab' ich bei einem Lauf (kein Marathon :-)) Startnummer 1 getragen - der Organisator ist Arbeitskollege.
Führende Nullen gehen jedoch durch. 1E3 als Zahl übergeben auch :-)

Es ist beim Programmieren sehr wichtig, die Aufgabe und die Schnittstellen (Übergabeparameter, Rückgabe) einer Funktion präzise zu formulieren. Sonst kann man alles Mögliche in existierenden (vor allem "nicht funzenden") Code hineininterpretieren. Aber das sagte ich ja schon zu Beginn ...

Freundliche Grüße

Vinzenz

[Der Martin]

Hallo,

Aber OK, der Parameter soll kein String sein. Da war doch was mit den Typen …
wenn man sich den Verwendungszweck anschaut, soll der Parameter ein String sein. Ich gehe sogar weiter: es muss ein String sein.

nö, es soll eine Nummer sein. Und eine Nummer ist eine Zahl, kein String (wenn wir mal von hypothetischen alphanumerischen Startnummern absehen).

eh ja: Startnummern mit führenden Nullen sind mir noch nie begegnet.

Mir schon. Nicht beim Marathon, aber ...
Aber selbst wenn: Wen stört's, wenn jemand beim Zieleinlauf alle Startnummern mit führenden Nullen auf vier Stellen auffüllt? Hauptsache, später bei der Anzeige werden sie wieder wie gewünscht formatiert.

Führende Nullen gehen jedoch durch. 1E3 als Zahl übergeben auch :-)

Ja, und?

Es ist beim Programmieren sehr wichtig, die Aufgabe und die Schnittstellen (Übergabeparameter, Rückgabe) einer Funktion präzise zu formulieren.

Eben. Und dazu gehört IMHO auch die Trennung von Logik und Repräsentation.

Ciao,
 Martin

[Vinzenz Mai]

Hallo Martin,

Aber OK, der Parameter soll kein String sein. Da war doch was mit den Typen …
wenn man sich den Verwendungszweck anschaut, soll der Parameter ein String sein. Ich gehe sogar weiter: es muss ein String sein.

nö, es soll eine Nummer sein. Und eine Nummer ist eine Zahl, kein String (wenn wir mal von hypothetischen alphanumerischen Startnummern absehen).

nein, natürlich nicht. Der Verwendungszweck zeigt ganz eindeutig, dass die *benötigte* Funktion eine Zeichenkette erwartet und keine Zahl. Die Funktion soll den Inhalt eines Textfeldes überprüfen. Ich hatte daher einen anderen Namen empfohlen :-)

Und ja: Ich gehe davon aus, dass 1E3 keine zulässige Eingabe für 1000 ist. Im von zebaeh angegebenen Kontext [1] wäre auch ein Vorzeichen unzulässig, d.h. +1000 wäre ebenfalls nicht zulässig. Die Zulässigkeit von führenden Nullen könnte man über ein Flag steuern. :-)

Freundliche Grüße

Vinzenz

[1] BigPeters Anforderungen können anders sein.

[Der Martin]

Hallo,

nö, es soll eine Nummer sein. Und eine Nummer ist eine Zahl, kein String (wenn wir mal von hypothetischen alphanumerischen Startnummern absehen).
nein, natürlich nicht. Der Verwendungszweck zeigt ganz eindeutig, dass die *benötigte* Funktion eine Zeichenkette erwartet und keine Zahl. Die Funktion soll den Inhalt eines Textfeldes überprüfen.

ich hätte es anders formuliert: Sie soll überprüfen, ob der als Zahl interpretierte Wert des Eingabefelds im zulässigen Bereich liegt.

Ich hatte daher einen anderen Namen empfohlen :-)

Habe ich gesehen.

Und ja: Ich gehe davon aus, dass 1E3 keine zulässige Eingabe für 1000 ist. Im von zebaeh angegebenen Kontext [1] wäre auch ein Vorzeichen unzulässig, d.h. +1000 wäre ebenfalls nicht zulässig.

Ich halte all diese Einschränkungen für falsch vom Standpunkt der Usability.

Normalerweise gehe ich davon aus, nein, *fordere* ich, dass eine Eingabe in jeder halbwegs plausiblen Notation akzeptiert wird (solange diese Notation eindeutig ist), der eingegebene Wert dann intern in einem zur Anwendung passenden Format (hier: Ganzzahl) gespeichert, und bei der Ausgabe wieder entsprechend der gewünschten Darstellung formatiert wird.
Bei der Eingabe schon ein ganz bestimmtes Format zu erzwingen, halte ich für eine unnötige und deshalb ärgerliche Bevormundung des Nutzers.

Ciao,
 Martin

[MudGuard]

Hi,

Ich halte all diese Einschränkungen für falsch vom Standpunkt der Usability.
Normalerweise gehe ich davon aus, nein, *fordere* ich, dass eine Eingabe in jeder halbwegs plausiblen Notation akzeptiert wird

Du läßt also bei Zahleneingaben sowas wie 'XLII' (siehe 'hageter ad galaxiam viatoris' ;-) ) zu?

cu,
Andreas

[Der Martin]

Hallo,

Ich halte all diese Einschränkungen für falsch vom Standpunkt der Usability.
Normalerweise gehe ich davon aus, nein, *fordere* ich, dass eine Eingabe in jeder halbwegs plausiblen Notation akzeptiert wird
Du läßt also bei Zahleneingaben sowas wie 'XLII' (siehe 'hageter ad galaxiam viatoris' ;-) ) zu?

wenn ich vermuten muss, dass ein Teil der Nutzer wohl römische Zahlen verwenden möchte - ja. Dass ich diese Zahlenformate dann selbst parsen muss, ist eine andere Geschichte.
Wenn Javascript (oder jede andere Programmiersprache bzw. deren Standardbibliothek) aber von Haus aus römische Zahlen unterstützen würde, dann würde ich das selbstverständlich zulassen, ebenso wie ich bei der Eingabe von Ganzzahlen "0x03E8" zulasse.

Ciao,
 Martin

[MudGuard]

Hi,

Du läßt also bei Zahleneingaben sowas wie 'XLII' (siehe 'hageter ad galaxiam viatoris' ;-) ) zu?

wenn ich vermuten muss, dass ein Teil der Nutzer wohl römische Zahlen verwenden möchte - ja. Dass ich diese Zahlenformate dann selbst parsen muss, ist eine andere Geschichte.

Tja, leider hat sich bisher 0rXLII noch nicht wirklich durchgesetzt ;-)

cu,
Andreas

[Auge]

Hallo

Und ja: Ich gehe davon aus, dass 1E3 keine zulässige Eingabe für 1000 ist. Im von zebaeh angegebenen Kontext [1] wäre auch ein Vorzeichen unzulässig, d.h. +1000 wäre ebenfalls nicht zulässig.

Ich halte all diese Einschränkungen für falsch vom Standpunkt der Usability.

Normalerweise gehe ich davon aus, nein, *fordere* ich, dass eine Eingabe in jeder halbwegs plausiblen Notation akzeptiert wird (solange diese Notation eindeutig ist), der eingegebene Wert dann intern in einem zur Anwendung passenden Format (hier: Ganzzahl) gespeichert, und bei der Ausgabe wieder entsprechend der gewünschten Darstellung formatiert wird.
Bei der Eingabe schon ein ganz bestimmtes Format zu erzwingen, halte ich füreine unnötige und deshalb ärgerliche Bevormundung des Nutzers.

Du scheinst mir über's Ziel hinauszuschießen. Wir reden hier (vermutlich [1]) über Startnummern für einen Marathonlauf. Allen Erfahrungen aus der realen Welt nach – ja, die gibt's auch noch ;-) – sind diese Startnummern postitive Ganzzahlen, ausgenommen spleenige Veranstalter, die Römische Zahlen benutzen. Von welchen unnötigen Einschränkungen redest du nun eigentlich, dammich nochma?

[1] Ob die Vermutung zutrifft, wissen wir nicht, da soch der OP nicht mehr äußert.

Tschö, Auge

[Der Martin]

Hi,

Bei der Eingabe schon ein ganz bestimmtes Format zu erzwingen, halte ich füreine unnötige und deshalb ärgerliche Bevormundung des Nutzers.
Du scheinst mir über's Ziel hinauszuschießen. Wir reden hier (vermutlich [1]) über Startnummern für einen Marathonlauf.

ja, und?

Allen Erfahrungen aus der realen Welt nach – ja, die gibt's auch noch ;-) – sind diese Startnummern postitive Ganzzahlen, ausgenommen spleenige Veranstalter, die Römische Zahlen benutzen. Von welchen unnötigen Einschränkungen redest du nun eigentlich, dammich nochma?

Ich rede doch nur davon, dass man die *Eingabe* dieser Nummern (oder Codes) nicht grundlos einschränken sollte. Wenn sich durch eine bestimmte Einschränkung ein Vorteil ergibt, meinetwegen. Sei es ein Vorteil für den Programmierer, oder die Vermeidung von Mehrdeutigkeiten.
Aber warum sollte man die arme Socke, die die "Nummern" eingibt, zwingen, die Ziffern Eins, Null, Null, Null, Null einzugeben, obwohl 1e4 schneller und bequemer wäre? Warum sollte man einen unverbesserlichen Pedanten zwingen, die führenden Nullen wegzulassen, obwohl sie nicht schaden und ohne Mehraufwand korrekt verarbeitet werden?

Einschränkungen sollte man nur machen, wenn es einen triftigen Grund dafür gibt. Finde ich jedenfalls. Und zwar in allen Lebensbereichen.

Ciao,
 Martin

[dedlfix]

Hi!

Aber warum sollte man die arme Socke, die die "Nummern" eingibt, zwingen, die Ziffern Eins, Null, Null, Null, Null einzugeben, obwohl 1e4 schneller und bequemer wäre?

Weil das außer dir niemand macht. Er werden gerade mal zwei Tastenbetätigungen eingespart und eine Taste ist auch noch am anderen Ende der Tastatur aufzusuchen (wieder mit Ausnahme von dir, der den Ziffernblock meidet). Und nächstes Jahr fällt der arme Eingeber damit auf die Nase, weil der Chef entscheidet, dass noch ein Buchstabe zur Startnummer hinzukommt und das numerische System für ein nichtnumerisches aber eben aus Ziffernzeichen bestehendes Datum nicht verwendet werden kann.

Lo!

[Vinzenz Mai]

Hallo Martin,

Und ja: Ich gehe davon aus, dass 1E3 keine zulässige Eingabe für 1000 ist. Im von zebaeh angegebenen Kontext [1] wäre auch ein Vorzeichen unzulässig, d.h. +1000 wäre ebenfalls nicht zulässig.

Ich halte all diese Einschränkungen für falsch vom Standpunkt der Usability.

Normalerweise gehe ich davon aus, nein, *fordere* ich, dass eine Eingabe in jeder halbwegs plausiblen Notation akzeptiert wird (solange diese Notation eindeutig ist), der eingegebene Wert dann intern in einem zur Anwendung passenden Format (hier: Ganzzahl) gespeichert, und bei der Ausgabe wieder entsprechend der gewünschten Darstellung formatiert wird.

Martin, Gunnar, BigPeter und Vinzenz starten beim Marathon. Der Veranstalter steht auf Startnummern mit führenden Nullen [1]. Martins Startnummer trägt die 1111, Gunnars die 0088, BigPeter hat die 0077, Vinzenz trägt die 0063. Wir nehmen weiterhin den Standardalgorithmus von parseInt():

Martin sucht sich mit seiner Startnummer, kein Problem,
Gunnar gibt die 0088 ein, auch er ist erfolgreich,
BigPeter gibt 0077 ein und findet Vinzenz statt sich selbst ...

"Ich hab's doch genauso gemacht wie Martin und Gunnar. Da kann nichts falsch sein."

Benutzerfreundlich ist es, wenn man das, was auf einem gedruckten Zettel steht, genauso verwenden kann :-) Deswegen darf man ruhig Einschränkungen vornehmen und muss gegebenenfalls seine eigene Umwandlungsroutine anstatt des Programmiersprachenstandards verwenden.

Ich halte 1E3 im vorliegenden Anwendungsfall für etwa so unwahrscheinlich wie MMM und hätte daher keine Bedenken, beide Schreibweisen nicht zu berücksichtigen.

Freundliche Grüße

Vinzenz

[1] Beim Laufen wirklich noch nie gesehen.

[Gunnar Bittersmann]

@@Vinzenz Mai:

nuqneH

[führende Nullen] Beim Laufen wirklich noch nie gesehen.

Du läufst ja auch immer hinten im Feld‽ ;-)

Qapla'

[Vinzenz Mai]

Hallo Gunnar,

[führende Nullen] Beim Laufen wirklich noch nie gesehen.
Du läufst ja auch immer hinten im Feld‽ ;-)

bei einer Wendepunktstrecke[1] ist es gleichgültig, wo man sich befindet.
Hauptsache man ist nicht selbst an der Spitze :-)

Freundliche Grüße

Vinzenz

[1] hat nichts mit dem Wendepunkt eines Funktionsgraphen zu tun.

[Der Martin]

Hallo,

Martin, Gunnar, BigPeter und Vinzenz starten beim Marathon. Der Veranstalter steht auf Startnummern mit führenden Nullen [1]. Martins Startnummer trägt die 1111, Gunnars die 0088, BigPeter hat die 0077, Vinzenz trägt die 0063. Wir nehmen weiterhin den Standardalgorithmus von parseInt():

nun ja, ein von vornherein kaputtes Konzept macht natürlich alle rationalen Betrachtungen zunichte. Wer kommt auch auf so eine dämliche Idee, Zahlen mit einer führenden Null, aber sonst ohne eindeutige Kennzeichnung als Oktalzahlen zu interpretieren? - Möcht' nicht wissen, was die 68er da alles geraucht haben.
Konsequenterweise hätte man für Oktalzahlen das Präfix 0o festlegen müssen, entsprechend den Hexadezimalzahlen.

Benutzerfreundlich ist es, wenn man das, was auf einem gedruckten Zettel steht, genauso verwenden kann :-)

Richtig. Und wenn auf dem gedruckten Zettel "77" steht, und für die Eingabe vier Stellen vorgesehen sind, sollte sowohl "  77" als auch "77" als auch "0077" eindeutig erkannt werden. Dass "77" anders interpretiert wird als "077" oder "0077", widerspricht jeder Vernunft.

Ich halte 1E3 im vorliegenden Anwendungsfall für etwa so unwahrscheinlich

Zugegeben, die Exponentialschreibweise ist vermutlich eher ungewöhnlich. Führende Nullen allerdings nicht.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Vinzenz Mai:

nuqneH

Der Verwendungszweck zeigt ganz eindeutig, dass die *benötigte* Funktion eine Zeichenkette erwartet und keine Zahl. Die Funktion soll den Inhalt eines Textfeldes überprüfen.

Dazu wird gar keine JavaScript-Funktion benötigt (werden). <input type="number"/> und gut.

Qapla'

[dedlfix]

Hi!

eh ja: Startnummern mit führenden Nullen sind mir noch nie begegnet.
Mir schon. Nicht beim Marathon, aber ...

Nullen in führenden Positionen ... haufenweise.

Ansonsten, gibt es ja keine Norm, wie Startnummern aufzubauen sind.

Aber selbst wenn: Wen stört's, wenn jemand beim Zieleinlauf alle Startnummern mit führenden Nullen auf vier Stellen auffüllt? Hauptsache, später bei der Anzeige werden sie wieder wie gewünscht formatiert.

Wenn es nun mal nicht gewünscht ist.

Es ist beim Programmieren sehr wichtig, die Aufgabe und die Schnittstellen (Übergabeparameter, Rückgabe) einer Funktion präzise zu formulieren.

Eben. Und dazu gehört IMHO auch die Trennung von Logik und Repräsentation.

Es ist hier ähnlich wie bei Postleitzahlen. Es besteht keine Notwendigkeit, sie als Zahl zu behandeln. Im Gegenteil. Es wird nicht mit ihnen gerechnet und die führende Null ist keine Option sondern wichtiger Bestandteil, damit man sie nicht mit vierstelligen alten Postleitzahlen verwechselt. Es werden also lediglich die Ziffernzeichen verwendet, ansonsten ist es ein Stück Text. Genauso ist es bei den Startnummern. Das einzige Kriterium, das bei Startnummern von Zahlen genutzt werden kann, wäre die Inkrementierung zum Erzeugen unterschiedlicher Werte. Aber auch das muss nicht sein. Im Prinzip kann man sie per Zufall vergeben und muss nur die Eindeutigkeit sicherstellen.

Lo!

[Der Martin]

Hallo,

eh ja: Startnummern mit führenden Nullen sind mir noch nie begegnet.
Mir schon. Nicht beim Marathon, aber ...
Nullen in führenden Positionen ... haufenweise.

ja, in der Flugzeugtechnik ist es wie in der Politik: An allen wichtigen Stellen sitzen Nieten. ;-)

Eben. Und dazu gehört IMHO auch die Trennung von Logik und Repräsentation.
Es ist hier ähnlich wie bei Postleitzahlen. Es besteht keine Notwendigkeit, sie als Zahl zu behandeln.

Einverstanden. Dann sollte man aber auch so konsequent sein und diese Codes nicht als "Zahl" oder "Nummer" bezeichnen. Denn in dem Moment, wo sie so genannt werden, betrachte ich sie als numerisch und behandle sie auch so.

Genauso ist es bei den Startnummern. Das einzige Kriterium, das bei Startnummern von Zahlen genutzt werden kann, wäre die Inkrementierung zum Erzeugen unterschiedlicher Werte. Aber auch das muss nicht sein. Im Prinzip kann man sie per Zufall vergeben und muss nur die Eindeutigkeit sicherstellen.

Dann sollte man sie aber nicht "Nummer" nennen, sondern meinetwegen "Startcodes". Und wenn du schon so argumentierst, ergibt sich daraus für mich zwangsläufig, dass sie mit führenden Nullen geschrieben werden. Denn eine Reihe gleichartiger Angaben mit unterschiedlicher Länge ist verwirrend ist sollte vermieden werden.
Oder man gibt den Läufern Codes aus drei Buchstaben. Dann kommt man gar nicht erst auf die Idee, diese Codes als "Nummer" aufzufassen.

Ciao,
 Martin

[Vinzenz Mai]

Hallo Martin,

Dann sollte man sie aber nicht "Nummer" nennen, sondern meinetwegen "Startcodes". Und wenn du schon so argumentierst, ergibt sich daraus für mich zwangsläufig, dass sie mit führenden Nullen geschrieben werden. Denn eine Reihe gleichartiger Angaben mit unterschiedlicher Länge ist verwirrend ist sollte vermieden werden.
Oder man gibt den Läufern Codes aus drei Buchstaben. Dann kommt man gar nicht erst auf die Idee, diese Codes als "Nummer" aufzufassen.

nette Forderungen. Sie passen nur nicht zur Praxis der Laufszene.

Freundliche Grüße

Vinzenz
früher passionierter Langstreckenläufer

[Der Martin]

Hallo,

Dann sollte man sie aber nicht "Nummer" nennen, [...]
nette Forderungen. Sie passen nur nicht zur Praxis der Laufszene.

das ist aber nicht *mein* Problem. Ich will nur dem, der diese "Nummern" eingibt, maximale Flexibilität _an_bieten und so wenig wie möglich _ver_bieten.

Vinzenz
früher passionierter Langstreckenläufer

Heute pensionierter Langstreckenläufer? ;-)

Ciao,
 Martin

[Vinzenz Mai]

Hallo Martin,

früher passionierter Langstreckenläufer
Heute pensionierter Langstreckenläufer? ;-)

aus dem Vorruhestand zurück:
nach über 10 Jahren Pause hab' ich vor etwa zwei Jahren wieder mit Laufen angefangen und 2010 und 2011 auch den einen oder anderen Wettkampf bestritten. Mal schauen, ob es in ferner Zukunft wieder für einen Marathon reicht ...

Freundliche Grüße

Vinzenz

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Einverstanden. Dann sollte man aber auch so konsequent sein und diese Codes nicht als "Zahl" oder "Nummer" bezeichnen.

Im UK bspw. heißt es auch „postal _code_“ – aus gutem Grund.

[…] ergibt sich daraus für mich zwangsläufig, dass sie mit führenden Nullen geschrieben werden. Denn eine Reihe gleichartiger Angaben mit unterschiedlicher Länge ist verwirrend ist sollte vermieden werden.

Nein. Wenn die Start_nummern_ tatsächlich fortlaufende Nummern (Zahlen) sind, macht das keinen Sinn. Bei der Vergabe der ersten Startnummer müsste man ja schon im Voraus wissen, wieviele Teilnehmer sich anmelden werden.

Qapla'

[zehbaeh]

Nein. Wenn die Start_nummern_ tatsächlich fortlaufende Nummern (Zahlen) sind, macht das keinen Sinn. Bei der Vergabe der ersten Startnummer müsste man ja schon im Voraus wissen, wieviele Teilnehmer sich anmelden werden.

Das sollte sich durch die Angabe der max. erwarteten Teilnehmer im Rahmen der üblichen Anmeldepflichten für solche Events ergeben.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Nullen in führenden Positionen ... haufenweise.

VBG.

Es ist hier [bei Startnummern] ähnlich wie bei Postleitzahlen.

Es besteht ein Unterschied.

Postleitzahlen sind in Deutschland hierarchisch aufgebaut: '01237' ist also eher '0.1.2.3.7'.

Wobei auch die Reihenfolge eine Rolle spielt: i.d.R. aufsteigend entlang einer Schnecke entgegen dem Uhrzeigersinn (und das wie bei einem Fraktal im Großen wie im Kleinen).

die führende Null ist keine Option sondern wichtiger Bestandteil, damit man sie nicht mit vierstelligen alten Postleitzahlen verwechselt.

Nicht deshalb, sondern weil '0' eine Zone kennzeichnet.

Das einzige Kriterium, das bei Startnummern von Zahlen genutzt werden kann, wäre die Inkrementierung zum Erzeugen unterschiedlicher Werte. Aber auch das muss nicht sein. Im Prinzip kann man sie per Zufall vergeben und muss nur die Eindeutigkeit sicherstellen.

AFAIK wird das jetzt an Unis für Matrikelnummern so gemacht. Dann fliegt man als Langzeitstudent nicht gleich auf. ;-)

Qapla'

[Der Martin]

Hallo,

Postleitzahlen sind in Deutschland hierarchisch aufgebaut: '01237' ist also eher '0.1.2.3.7'.
Wobei auch die Reihenfolge eine Rolle spielt: i.d.R. aufsteigend entlang einer Schnecke entgegen dem Uhrzeigersinn (und das wie bei einem Fraktal im Großen wie im Kleinen).

hey, *das* Detail war mir noch nicht bekannt. Interessanter Hinweis, danke. Und zumindest an der ersten Stelle kann ich es nachvollziehen, die anderen glaube ich jetzt einfach mal. ;-)

Im Prinzip kann man sie per Zufall vergeben und muss nur die Eindeutigkeit sicherstellen.
AFAIK wird das jetzt an Unis für Matrikelnummern so gemacht. Dann fliegt man als Langzeitstudent nicht gleich auf. ;-)

Ich hatte damals in meinem Studium (1990+) schon den Eindruck, dass das so gemacht würde. Denn die Matrikelnummern meiner Kommilitonen, die mit mir gleichzeitig angefangen hatten, waren kreuz und quer über den Bereich sechsstelliger Werte verstreut. Vielleicht waren sie aber auch fortlaufend, und die Dezimalstellen wurden nur nach einem bestimmten Schema vertauscht, so dass die Reihenfolge nicht mehr klar erkennbar war.

Ciao,
 Martin

[Der Martin]

Hallo,

function isInt(number)

{
  return number == Math.floor(number);
}

> >   
> > das sieht sehr gut aus. RegExp, [wie von mir vorgeschlagen](https://forum.selfhtml.org/?t=205596&m=1393959), ist wieder mal Overkill.  
>   
> Nicht wirklich:  
> isInt('1e3') => true  
  
das wäre ja korrekt, denn 1000 ist sicher eine Ganzzahl.  
  

> isInt('') => true  
  
Würde ich auch gutheißen, denn eine "leere" Eingabe soll in vielen Fällen als 0 gelten, und 0 ist selbstverständlich auch eine Ganzzahl.  
  

> Aus dem Kontext heraus (Nummer ist/soll sein Marathon-Nummern)  
  
Was zum Geier sind Marathon-Nummern?  
  

> ~~~javascript

function isMarathonNumber(value) {  

>    return (0 != value) && (null === String(value).match(/[^0-9]/));  
> }

Also doch wieder ein RegEx - und warum willst du die 0 sowie negative Zahlen ausschließen?

Ciao,
 Martin

[Vinzenz Mai]

Hallo,

Würde ich auch gutheißen, denn eine "leere" Eingabe soll in vielen Fällen als 0 gelten, und 0 ist selbstverständlich auch eine Ganzzahl.

Aus dem Kontext heraus (Nummer ist/soll sein Marathon-Nummern)
Was zum Geier sind Marathon-Nummern?

naja, ich vermute Startnummern.

function isMarathonNumber(value) {

return (0 != value) && (null === String(value).match(/[^0-9]/));
}

>   
> Also doch wieder ein RegEx - und warum willst du die 0 sowie negative Zahlen ausschließen?  
  
negative Startnummern sind unüblich, die 0 auch :-)  
Startnummern sind üblicherweise Zeichenketten.  
Startnummern beginnen üblicherweise bei 1 (oder höheren Werten)  
Startnummern haben üblicherweise keine führenden Nullen.  
  
Falls RegExp, dann eher:  
  
~~~javascript
function isRacingNumber(value) {  
    // Vorbemerkungen:  
    //     Startnummer heißt auf englisch einfach nur Number  
    //     aber isNumber() war mir nicht spezifisch genug :-)  
    //     Sind die Rückgabewerte von typeof() einheitlich lowercase?  
    // ---------------------------------------------------------  
    // Wert muss eine Zeichenkette sein,  
    // das steht im Gegensatz zu [pref:t=205596;m=1393973@title=Gunnars Annahme],  
    // es sind nur Ziffern zugelassen,  
    // führende Nullen sind nicht zugelassen.  
    return (typeof(value) == 'string' && value.search(/^[1-9][0-9]*$/) > -1);  
}

Freundliche Grüße

Vinzenz

[Der Martin]

Hi,

Was zum Geier sind Marathon-Nummern?
naja, ich vermute Startnummern.

hmm ... so einfach? Ich hatte erfolglos nach diesem Spezialbegriff gesucht, hatte irgendeine mathematische Reihe oder eine Spielerei in der Art vermutet.

Also doch wieder ein RegEx - und warum willst du die 0 sowie negative Zahlen ausschließen?
negative Startnummern sind unüblich, die 0 auch :-)

In der Tat, ja. Das war für mich aus dem Startposting aber nicht wirklich klar.

Startnummern sind üblicherweise Zeichenketten.

Eigentlich Zahlen - unabhängig von ihrer Repräsentation. Ich halte es für semantisch nicht korrekt, sie als Strings zu behandeln.

Startnummern beginnen üblicherweise bei 1 (oder höheren Werten)

Ja.

Startnummern haben üblicherweise keine führenden Nullen.

Das ist wiederum eine Frage der Darstellung; die Formel 1 beispielsweise stellt ihre Startplätze 1..9 manchmal mit führenden Nullen dar. Nicht immer, aber ... ;-)

Und damit wäre die aus meiner Sicht richtige Prüfung:

function IsValidNumber(n)  
 { return (n==Math.floor(n) && n>0);  
 }

Ob diese numerisch als richtig erkannten Startnummern dann mit führenden Nullen, in hexadezimal oder mit römischen Zahlen angezeigt werden, hat IMO mit der Gültigkeitsprüfung nichts zu tun.

Ciao,
 Martin

[dedlfix]

Hi!

Wenn ich den "IsNumeric"-Term auskommentiere klappt alles tadellos.
Was mache ich falsch bei der IsNumeric Abfrage ? :/

Keine Ahnung. Was machst du überhaupt? Und wie reagiert diese Funktion allgemein auf welche Werte?

Lo!