Vorlage Diskussion:IstZahl

Alternative Implementation

Ich halte die momentane Implementation dieser Vorlage für problematisch. Sie schlägt fehl, wenn man sie mit geschickt konstruierten mathematischen Konstrukten füttert, die zufällig korrekt durch den Parser der #expr-Funktion laufen (Beispiele: „--123456789“, „2*3“ oder „1.0.0“). Für die Vorlage:Infobox Ort in Deutschland habe ich eine ähnliche Funktion mit #ifeq implementiert. Auf die Vorlage:IstZahl angewandt würde das wie folgt aussehen:

{{#ifeq: {{#expr: {{{1}}} }} | {{{1|}}} | {{{1|}}} | {{{2|}}} }}

Das hätte gleich noch einen Vorteil: Mit einem Konstrukt in der Art {{IstZahl| {{{Einwohner}}} | <div class="error">Fehler im Parameter Einwohner!<div> }} könnte man wahlweise eine Fehlermeldung ausgeben lassen. --TMg 16:48, 16. Okt. 2007 (CEST)

Danke für deinen Hinweis, im Groben hast du Recht, deine Implementierung ist die einfachere und die stabilere. Ich stimme dir auch zu, was die Diskrepanz zwischen dem Templatenamen und der ausgeführten Prüfung betrifft. Allerdings würde ich aus praktischen Erwägungen eine Prüfung auf weiter in #expr verwendbar denn eine strikte Prüfung auf IstZahl, wie der Name nahelegt, vorziehen. Schlussendlich geht es doch darum, Parameterfehler bei der Eingabe zu finden, und da ist 2*3 genau so gut wie 6 und richtig. Dann aber sollte die Vorlage Vorlage:IstNumerischerWert oder so ähnlich heißen, was nicht schön wäre. Da aber niemand bei der Anzahl Einwohner 1000+24 hinschreiben wird, und interne Berechnungen in Vorlagen (z.B. Höhendifferenzen) ohnehin ohne Prüfung oder mit vorhergehender Prüfung der Eingangsparameter erfolgen, lassen wir die Semantik bei Vorlage:IstZahl (im informatischen Sinn; ich kann mir nicht vorstellen, dass Mathematiker zwischen 1/2, 2^-1, 0.5 oder 10:5 viel Unterschied machen).

Die sonstige Semantik werde ich aber beibehalten. lg--Herzi Pinki 23:59, 16. Okt. 2007 (CEST)

Sch....

siehe auch Benutzer Diskussion:Herzi_Pinki#dem Geheimnis von #expr: auf der Spur:

#expr: liefert

• unterschiedliche Genauigkeiten in Abhängigkeit vom Server, auf dem die Seite aufbereitet wird.
• bei großen Zahlen implizite Konvertierung in Exponentialschreibweise

daher ist der Vergleich

{{#ifeq: {{#expr: {{{1}}} }} | {{{1|}}} | {{{1|}}} | <!--void--> }}

nicht zielführend.

Der Vergleich

{{#ifeq: {{#expr: {{{1}}}*0 }} | 0 | {{{1|}}} | <!--void--> }}

scheitert ebenfalls an Unzulänglichkeiten von #expr:, da dieser Fall mit multiplen Dezimalpunkten und mehrfachen monadischen Minus-Operatoren nicht korrekt umgeht.

val	#expr {{{1}}}		#expr {{{1}}}*0
0.123456789	0.123456789		0
0.123456789012345	0.12345678901234	Nein	0
99999999999999999999	1.0E+20		0
98765432109876543210	9.8765432109877E+19	Nein	0
22.12.2007	22.12		0	Nein
hugo

Rundung

Hallöchen, ich komme mit eurer Definition von Rundung nicht ganz klar: Dritter Parameter (optional): Test, ob der Wert auf eine bestimmte Weise gerundet wurde. Wie wollt ihr das feststellen? 3.1415 sieht man doch nicht an, dass es auf 4 Stellen gerundet wurde (genauer, auf 4 Stellen abgeschnitten, denn auf 4 Stellen gerundet wäre ja 3.1416). Auch einem Wert von 3.0000000 ({{IstZahl|3.0000000||0}} = 1 = {{IstZahl|3.0000000||7}} = 1) sieht man nicht an, ob er auf null Nachkommastellen gerundet wurde, oder auf 7. lg --Herzi Pinki 20:22, 27. Jun. 2008 (CEST)

«Test ob die Zahl mehr als x signifikante Stellen hat.» besser? -- visi-on 20:29, 27. Jun. 2008 (CEST)

Na ja, das würde aber nicht stimmen. "3.1416" hat 5 signifikante stellen, ist aber auf 4 Nachkommastellen gerundet. --Revolus Echo der Stille 21:07, 27. Jun. 2008 (CEST)

signifikante Nachkommastellen würde auch nicht helfen, da nicht bestimmbar ist, wie viele signifikante Nachkommastellen 3.0000000 hat, zumindest nicht mit dem derzeitigen Algorithmus. 3 ist nun mal nicht das gleiche wie 3.00 --Herzi Pinki 00:06, 28. Jun. 2008 (CEST)

ich würde einfach auf die Zielgenauigkeit runden, egal auf wie viele tausend Stellen der Wert angegeben ist. Wenn ich Höhe auf eine Dezimale für sinnvoll halte, dann runde ich den Rest weg. Detto bei Breitengraden. Oder Einwohnern. ME kann es nur darum gehen, Tippfehler aufzuspüren, als Beispiel vielleicht Einwohner, etwa 11.000 statt 11000, aber das würde auch nur bei 11.234 vs. 11234 funktionieren ( = 1, weil, siehe oben), nicht bei 11.000 vs 11000 (1 = 1). Um ehrlich zu sein, visi-on, ist mir nicht klar, wozu du das Feature mit dem Runden überhaupt verwendest. Ich bin nur über die etwas fragwürdige Definition gestolpert. --Herzi Pinki 00:06, 28. Jun. 2008 (CEST)

Weitere mögliche Optimierung

Vorschlag:

<onlyinclude>{{#iferror:{{#ifexpr:{{#switch:{{{2|}}}<!--
| R
|#default= -->
| R+ =  abs
| R- = -abs
| Z  = trunc
| Z+
| N  =  abs trunc
| Z- = -abs trunc}}({{{1}}}) = ({{{1}}}) {{#if:{{{3|}}} | round ({{{3}}}) }} | 1 }} }}</onlyinclude>
{{Dokumentation}}

Auswirkung (gemessen an einer ganz simplen Expansion, mit der Verwendungshäufigkeit multipliziert sich das natürlich):

Metrik	Vorher	Nachher	Limit
Preprocessor visited node count	16	14	1000000
Preprocessor generated node count	204	166	1500000
Post-expand include size	3	2	2048000 Byte
Highest expansion depth	6	5	40

Also nur Vorteile. Die Änderungen im Einzelnen:

• #ifeq und #expr zu einem #ifexpr zusammen gefasst. Das hat den größten Anteil, insbesondere bei der immer sehr kritischen Expansionstiefe. Die Expression selbst ändert sich dadurch wie man sieht nicht.
• Leere Parameter aus den Bedingungen entfernt, da das sowieso dem Standardverhalten entspricht. Das reduziert auch noch einmal einige Werte. Test: {{#ifexpr:0|1}} ergibt ›‹ und {{#iferror:{{#expr:x}}}} ergibt ›‹, also jeweils nichts, auch ohne abschließende |.
• Den Kommentar zu entfernen, würde den generated node count von 166 auf 162 reduzieren, zugunsten der Selbstdokumentation sollte er meiner Meinung nach aber stehen bleiben.
• Leerraum zu entfernen, ändert nichts.

Getestet habe ich beide Varianten ausführlich. Es gibt keinen Unterschied. --TMg 19:43, 4. Feb. 2013 (CET)

erledigt. Der Umherirrende 11:31, 10. Feb. 2013 (CET)

breaking change

@PerfektesChaos:, diese Änderung führt dazu, dass {{IstZahl|2*3}} nicht mehr funktioniert. Ist das so beabsichtigt? {{IstZahl|6}} funktioniert hingegen.

• {{IstZahl|2*3}} = 1{{#lst:Wikipedia:Lua/Modul/Expr/Test|NurWennZahl}}
• {{IstZahl|{{#expr:2*3}}}} = 1
• {{IstZahl|6}} = 1
• {{IstZahl|2a}} =
• {{IstZahl|{{#expr:2a}}}} =

Wenn das so beabsichtigt ist, dann hilft {{IstZahl|{{#expr:2*3}}}}, es sind halt alle Aufrufe dahingehend zu überprüfen. [1] - ich finde grad > 1800 Aufrufe. Lässt sich die Änderung so gestalten, dass numerische Ausdrücke auch true | 1 ergeben, damit die Vorlage aufwärtskompatibel bleibt? lg --Herzi Pinki (Diskussion) 15:44, 5. Sep. 2022 (CEST)

Nein, ist nicht beabsichtigt.

Du könntest so nett sein und die nachfolgenden beiden auf Sichter-Bearbeitung runtersetzen:

• Vorlage:IstZahl
• Vorlage:NurWennZahl

Natürlich soll sie perspektivisch (praktisch) vollkompatibel sein und noch viel viel mehr können, aber gerade dieser Vollschutz hatte mich in diesem Fall daran gehindert, vorher das Spektrum zu erforschen, weil ich meine gefürchteten Schnüffelkats auch nicht einbauen konnte.

Neue Herausforderungen sind die Abfrage in Verbindung mit Vorlagen-Ausfüll-Formularen (VisualEditor), die grad keine solchen Ausdrücke erlauben würden, und der gleichberechtigte Umgang mit „normalem“ deutschen Zahlenformat (dreikommazwo).

Danke im Voraus --PerfektesChaos 16:27, 5. Sep. 2022 (CEST)

@PerfektesChaos: habe dir die zwei Vorlagen freigegeben, melde dich bitte, wenn du fertig bist. lg --Herzi Pinki (Diskussion) 18:15, 5. Sep. 2022 (CEST)

Ich denk mal, Ende des Monats werde ich das auf dem üblichen Dienstweg abgeschlossen haben.

Die umseitige habe ich soeben gerollbacked. Erstmal, bis die Tage.

Die neue Lua-Programmierung steht bereits auf WP:BETA. Ich muss da aber noch ein halbes Hundert Testfälle backen.

Der Wizard sowie unser guter alter Vorlagenmeister meckern bereits heute, wenn der Datentyp „Zahl“ angefordert ist, und akzeptieren keine sonstigen Zeichenketten. Der VisualEditor und der entsprechende „Wikitexteditor 2017“ sollen das auch irgendwann mal tun.

Insofern werden Vorlagen, die einen arithmetischen Ausdruck als Parameter akzeptieren, anders dokumentiert werden müssen, und die umseitige Vorlage wird dort auch etwas anders eingesetzt werden.

„trailing blank“, wie auf Vorlage:IstZahl/Test benannt, ignorieren wir heutzutage grundsätzlich. Das hatte man vor anderthalb Jahrzehnten bei unbenannten mal anders gehandhabt oder überhaupt nicht abgekonnt; inzwischen wollen wir aber auch gefälligen Zeilenumbruch des Quelltextes und lassen deshalb Leerzeichen und sogar Zeilenumbruch immer zu.

Außerdem sollte umseitig genau analog paramtrisiert sein wie Vorlage:NurWennZahl – das hatte mich zusätzlich aus der Bahn geworfen, und wohl deshalb hatte ich die Chose wieder vergessen, nachdem ich mir das vor Monaten mal alles angeschaut hatte. Während umseitig ggf. eine 1 liefern soll, was heute global die Bedeutung „ja“ hat, soll Vorlage:NurWennZahl dann eben ihre Aktivität ausführen usw.

VG --PerfektesChaos 18:38, 5. Sep. 2022 (CEST)

@Herzi Pinki: Auf Vorlage:NurWennZahl findest du bereits relativ ähnlich das, wie umseitig auch aussehen soll.

• Nur den dortigen Parameter 2 gibt es umseitig nicht. Da käme dann „1“ oder „nichts“ raus.
• Weil drei Optionen, sind diese auch benannt. Unbenannte Optionsparameter sind nicht gut.
• Umseitig gibt es einen Parameter 3, der in keiner Seite verwendet wird und völlig unverständlich dokumentiert wurde; er wird entfallen.
• Ein Migrationsprozess ist allerdings erforderlich, wo Ausdrücke zulässig und erwartet sind und wo nur echte Zahlen als Parameter erwartet werden. Diese detektiere ich aber bereits und werde sie so nach und nach auf die Umstellung vorbereiten.

VG --PerfektesChaos 17:07, 8. Sep. 2022 (CEST)

@PerfektesChaos:Meine ursprüngliche Implementierung aus 2007 kannte nur einen Parameter. Ich tendiere zu schlanken Interfaces. Das fette Interface mit Parametern 2 und 3 wurde durch Vorlagenhijacking implementiert. Ich brauche die Parameter nicht. Was ich aber brauche, ist, dass Ausdrücke mit Zahlergebnis als Zahlen betrachtet werden ({{IstZahl|2*3}}). Und dass solche als Zahl erkannten Werte an Vorlagen weitergereicht werden können, die Zahlen in englischer / IT Schreibweise mit Dezimalpunkt erwarten (z.B. {{Höhe}}). Insoferne bin ich gespannt auf {{IstZahl|2,3}}=. lg --Herzi Pinki (Diskussion) 17:38, 8. Sep. 2022 (CEST)