Vorlage Diskussion:ZahlZelle

Theoretisch wäre es denkbar, dass z.B. eine NULL als 0, -0, +0, ±0, ≈0 eingegeben wird.

NULLEN
0	0
-0	-0
0	0 ohne Zahlzelle
≈ 0	≈0
++0	++0
0	+0
---0	--0
+-0	+-0
± 0	±0
O	Ooooh

Obwohl mathematisch gleichwertig (bis auf ≈0, dass ja auch 0,0001 oder - 0,01 sein könnte, aber sich einer sinnvollen Sortierung entzieht), wäre es möglicherweise hilfteich, wenn

1. +0 … 0 … -0 in einer sinnvollen Reihe stehen würden.
2. ggf. die Vorzeichen, die mitunter eine Bedeutung haben, darstellbar wären (ggf. per Zusatzparameter). Ich denke da z.B. an die Darstelumng von Listen mit einer Endsumme in der Fußzeile.
3. bei --0 knirscht es -- logisch, aber wenig dekorativ. Experten legen mir nahe, mögliche Fehler „abzufackeln“ (Autokorrektur, sinnvolle Fehlermeldung) mit ‚attempt to concatenate local 'r' (a nil value)‘ kann nur der Autor etwas anfangen
4. Komfortabel wäre ggf. eine rote Darstellung (paragesteuert) der Negativwerte

Wie bei mir üblich alles nur Anregungen und weder Kritik noch Forderung! --Klaus-Peter (ex und hopp) 09:27, 27. Apr. 2020 (CEST)

Danke für den Hinweis; diese Erweiterung war mir zwischenzeitlich beim Arbeiten im ANR auch schon aufgefallen und in BETA sind Teile der Anregung bereits programmiert. Auch der Syntaxfehler bei doppeltem Minuszeichen fiel schon auf und ist in der Erprobungsversion bereits behoben.

Weiterhin kennt Vorlage:DatumZelle bereits heute ein vorangestelltes von, ca. usw.; ich plane, hier analog ebenfalls ≈ als zulässigen vorangestellten nichtnumerischen Wert zu akzeptieren, das Zeichen aber bei Bildung des Sortierwerts wegzulassen. Mit ca. ist das etwas schwieriger, weil die Programmierung internationalisiert und deshalb sprachunabhängig ist; genauso könnte ich mir vorstellen, die bei Vorlage:DatumZelle#preAd genannten Schlüsselwörter einfach pauschal für sonstige Zahlen hinzunehmen. Ob das inhaltlich sinnvoll wäre, ist Sache der Autoren; aber ab etwa würde auch zu einer Zahlenangabe passen. Vermutlich werde ich jedoch einen unabhängigen Katalog ignorierter vorangestellter Ausdrücke einführen; weiß ich noch nicht endgültig; wegen Internationalisierung jedoch voraussichtlich eigenständig.

±0 ist Null und dort einzusortieren, ≈0 sortierungstechnisch ebenso gegenüber 5 oder 17 und wer das genauer weiß, der muss das für seinen Einzelfall halt auch genauer hinterlegen.

100±2 kann guten Gewissens bei 100 einsortiert werden; jedenfalls nicht hinter 987.

Wie ich ±12 sortieren soll weiß ich nicht; das müsste sich ein Autor im Einzelfall selbst überlegen.

Vorlage:DatumZelle legt unverständliche Datumsangaben in einer allgemeinen Wartungskategorie ab und meldet sichtbar einen Fehler; für ZahlZelle & Co. gibt es zurzeit noch keine Wartungskategorie und im selben Zusammenhang noch keine sichtbare Fehlermeldung. Perspektivisch sollen sich alle Vorlagen dieser Familie gleich verhalten, wo immer dies inhaltlich gerechtfertigt wäre.

VG --PerfektesChaos 09:49, 27. Apr. 2020 (CEST)

Danke für die Erläuterung. Da scheint es ja in der richtigen Spur zu sein. Als Liebhaber der eierlegenden Wollmilchsau könnte ich mir noch Vorstellen:

1. Kombination mit beliebigen Texten, die einfach durchgeschleppt und unverändert dargestellt werden, derweil der Zahlenwert perfekt formatiert wird. Ob nach Gesamtbegriff (Text, Zahl) oder nur numerisch sortiert wird, bleibt eine Gedankenübung.
2. Vorgabe der Vor-/Nachkommastellen, z.B. {{ZahlZelle|22,5|5,2}} ergäbe    22,50 (oder, je nach Definition 5 Zeichen, davon 2 Nachkomma:  22,50). Damit könnte man sich den ganzen Ausrichungszirkus mit den Nullen (Vorlage:0, Vorlage:00) sparen.
3. Theoretisch sehe ich auch keine Hürde, wenn statt Zahl einfache Rechenoperationen angegeben werden. Da es ohnehin via LUA geht, sollte das ein Klacks sein

Gut, da driften die Welten auseinander. Ich schreibe lieber Universalprogramme, Andere bevorzugen die puren Spezialanwendungen. So long --Klaus-Peter (ex und hopp) 10:42, 27. Apr. 2020 (CEST)

@Rundung: Modul:Sort/cellNum kennt bereits FormatNum = 15709679 in seiner sechsten Zeile, was auf d:Q15709679 als globales Fallback verweist. Dort ist die Rundungsfunktion implementiert und diese perspektivisch auch vorgesehen. Heißt: Sortierung exakt, Darstellung ggf. formatiert und gerundet.

@Padding: Nein, gemäß Hilfe:Tabellen/Sortierung #Obsolet sollen keinerlei unsichtbare Inhalte mehr irgendwo eingefügt werden. Also sollen auch keine versteckten Nullen am Anfang eingefügt werden; wenn dann vermutlich perspektivisch höchstens Weißraum hinter einer rechtsbündig auszurichtenden Zahl. Das geschützte Leerzeichen   ist in den meisten Schriftarten deutlich breiter als eine Null, während alle Ziffern meist etwa gleich breit wären (Tabellenziffern sogar exakt). Schon deshalb wäre   ungeeignet. Es würde jedoch auch beim C&P störend übertragen werden.

• Es gibt ohnehin berits einen Parameter pad=, der dies für alle Zellen einer Spalte mit einheitlichem Wert unterstützen kann; ganz nach Belieben. Für eine Einrückung links werden dabei keinerlei Inhalte erzeugt.

@Wörter: Nein, anderes als ein kontrolliertes Vokabular rund etwa ungefähr ca. usw. wird es nicht geben; es ist ansonsten unklar, welches Wort an welcher Stelle welchen Einfluss haben solle. Es gibt bereits zur expliziten Vorgabe einen Parameter pre=. Die normale Textsortierung berücksichtigt numerische Werte in der von dir erwähnten Form, allerdings nachrangig zum führenden Text.

• Es würde ansonsten jede Syntaxprüfung ad absurdum geführt werden, weil sonst alles immer erlaubt ist und zu einer im ersten Moment nicht vorhersehbaren Sortierwirkung führt. Erst wenn später an völlig anderer Stelle andere Zeilen hinzugefügt würden, kämen diese unbemerkt in einen fehlerhaften Bezug.

VG --PerfektesChaos 11:00, 27. Apr. 2020 (CEST)

NBSP hatte ich gerade nur zur allg. Demonstration der Leerstellen vorgegeben.
Na gut, ich würde ggf. per regex erlaubte Begriffe erkennen, den Zahlenwert extrahieren (ggf. berechnen) und formatieren (ggf. mit voranzustellendem sortkey) und den Rest durchreichen. Aber auch ohne mein Zutun wird die Vorlage ihre Freunde finden. Das sehe ich gelassen. VG --Klaus-Peter (ex und hopp) 11:21, 27. Apr. 2020 (CEST)

Alternativer Sortierwert

Hallo, ich bin auf der Suche nach einer Vorlage, dir mir einen Wunsch erfüllt, aber ich bin nicht so richtig fündig geworden und diese Vorlage hat 90% meines Wunsches enthalten. Ich habe eine sortierbare Tabelle, aber die Werte gehen über mehrere Grössenordnungen. Um die Übersichtlichkeit zu wahren, dachte ich ich packe 2 unterschiedliche Einheiten in dieselbe Spalte. Pro Zeile in der Tabelle kommt nur die eine, resp. die andere Einheit vor. Für die Sortierung möchte ich von der einen Einheit in die andere umrechnen (z.b. per #expr:*300.000), damit der "data-sort-value" stimmt und nachvollzogen werden kann, aber gleichzeitig auch ein für den menschlichen Leser einfach zu interpretierender Wert dasteht. Ich bräuchte also etwas wie einen optionalen Parameter "Sortierwert". Vielleicht gäbs dafür auch noch andere sinnvolle Anwendungen.--McBayne (Diskussion) 20:02, 29. Mai 2022 (CEST)

Naja, der Witz an der umseitigen Vorlage ist, dass du die Zahl direkt angeben kannst, und diese nach üblichen Regeln formatiert und erforderlichenfalls mit Sortierschlüssel dargestellt wird.

• Also die Zahl nur einmal.
• Du kannst jedoch per Hilfe:Tabellen/Sortierung #data-sort-value jeden beliebigen Sortierwert mit jeder beliebigen Darstellung kombinieren.
• Also sowas wie 2 GHz kombiniert mit 37 MHz in derselben Spalte.

VG --PerfektesChaos 20:57, 29. Mai 2022 (CEST)

Wie kann ich denn in deinem Gegenbeispiel sinnvoll sortieren? Das ist ja genau mein Problem. Die direkte Verwendung von "data-sort-value" scheitert, da ich den Sortierwert im Quelltext berechnen möchte. data-sort-value="0.037" scheitert. Spannende Frage, warum es im expliziten Beispiel ausserhalb der Tabelle funktioniert.--McBayne (Diskussion) 21:57, 29. Mai 2022 (CEST)

Ich vermute, du müsstest das Dezialtrennzeichen in deutschen Kontext bringen.

0.037 gilt hierzuwiki als Tausendertrennzeichen; 73.854 sind dreiundsiebzigtausend aber in den USA dreiundsiebzig und ein paar Zerquetschte. Dein 0.037 sind identisch 37.

formatnum

Deutsch
37/1000
1/1000000
½

VG --PerfektesChaos 00:40, 30. Mai 2022 (CEST)

Danke für den Input, aber wenn ich den berechneten Wert direkt eintragen, dann geht es.data-sort-value="0.037"

Sorry, ich habe Tomaten auf den Augen. Irgendwie macht das bei mir nur komische Sachen sobald ich Punkte, Kommas und Exponenten drin habe.

Wert
0,01
0,02
0,015
2E2
3.02e2
101
0,003

--McBayne (Diskussion) 01:33, 30. Mai 2022 (CEST)

Also, erstmal gilt es grundsätzlich zu unterscheiden:

• raw-Format, global verwendbar, Dezimalzeichen ist Punkt, sonst nix, Minuszeichen von der Tastatur.
  • Pflicht bei allen Eingaben in Berechnungen, namentlich: #expr
• Lokale Präsentation. Deutschsprachig: Dezimalzeichen ist Komma, Punkt ist Tausendergliederung, Minuszeichen gern typografisch (länger, anderes Zeichen).
  • Gewünscht bei der Sortierung, weil wenn das so in einer Tabellenzelle direkt steht, dann wird diese richtig einsortiert.
  • Nicht kompatibel mit Berechnungen.

Nun hast du geschrieben: #expr:200,1

• Das is nix. Muss ein Punkt sein.

Dann lässt du den Datentyp der Spalte automatisch erkennen.

• Das guckt sich von der ersten Handvoll nicht-leerer Zeilen das mutmaßliche Format an.
• Zahlen werden daran erkannt, dass dort nur Ziffern und Plus-/Minus-Zeichen und Punkte und Komma stehen.
• Bei dir steht 2E2 – das ist erstmal keine Zahl, sondern ein Text und könnte auch die Baureihe einer Dampflokomotive sein.
• Hilfe:Tabellen/Sortierung #Datentyp automatisch ermitteln
• Wenn du nicht eindeutige Werte in der Spalte hast, muss data-sort-type="number" gesetzt werden.

Du planst offenbar, die Konstruktionen mit #expr in enzyklopädischen Artikeln zu verwenden.

• Sowas ist absolut unerwünscht; was eigentlich meint: verboten.
• Grund ist, dass alle nachfolgenden Autoren deinen ganzen formatnum:#expr umständlich nachvollziehen müssen. Wenn du selbst das schon nicht packst und erst hier nachfragen musst, dann brauchen alle späteren Bearbeitenden auch eine Sonderbetreuung durch die Technik-Abteilung.
• Im gespeicherten Artikel darf nur der fertig ausgerechnete Sortierwert als Konstante stehen.
• Die Wikisyntax in enzyklopädischen Artikeln soll möglichst einfach und leicht nachvollziehbar sein.
• Du könntest mittels {{subst:formatnum:{{subst:#expr: gemäß Hilfe:Substitution die Berechnung ausführen lassen.
• Hinzu kommt, dass alle Berechnungen bei jedem Neuaufbau der Seite und jeder Vorschau erneut ausgeführt werden müssen; das möchten wir nicht, wenn das vielfach erforderlich ist, also in vielen Tabellenzellen.

Siehe auch Vorlage:ZahlExpZelle – Zahl in Exponentialdarstellung

Wert
0,01
0,02
0,015
2e2
3.02e2
101
0,003

Ein kleines Problem gibt es mit der Doku zu deiner neuen Vorlage Vorlage:NasaExoplanet.

• Das TemplateData ist nicht eine Tabelle des Abschnitts „Parameter“, sondern die Funktionsbeschreibung ist gleichzeitig der Einleitungsabschnitt und die Doku beginnt mit TemplateData so wie umseitig.

VG --PerfektesChaos 23:39, 30. Mai 2022 (CEST)

Besten Dank für die ausführliche Antwort. Meine Tabelle enthielt einfach alle verzweifelten Versuche, es "zum laufen" zu bringen aber mit deinen Korrekturen werde ich es mutmasslich nachvollziehen können. Bzgl. Nachvollziehbarkeit: daher habe ich ursprünglich für eine Zusatzparameter in der Vorlage angefragt, da es dann etwas weniger "kurios" aussieht im Quelltext als diese data-sort-value Übungen. Momentan bin ich noch konzeptionell am austüfteln wie das ganze aussehen könnte, aber Nachvollziehbarkeit ist mir ein grosses Anliegen und das gilt auch für die Berechnung, d.h. wenn das im Quelltext unübersichtlich wird, dann kommt halt nur das Resultat rein und die Berechnung muss ich irgendwie anders erklären..

Bgzl. deiner Bemerkung zu Vorlage:NasaExoplanet: ich habe die Doku mal verändert, aber weiss nicht ob ich deinen Input richtig verstanden habe.

Meine Grundanfrage für den zusätzlichen Parameter in Vorlage ZahlZelle bleibt bestehen, denn ausser diesem "number"-Kniff in der Kopfzeile würde das mit zusätzlichem Parameter nach allem was ich hier sehe bereits gut unterstützt und man müsste sich auch nicht mit so komischen "FormatNum" Fragen quälen. Auch wenn die Berechnung sicher kein Standardfall wäre, so könnte ich mir durchaus mehr Anwendungen für den extra Sortierwert vorstellen. Z.b. wenn in der Tabelle der Wert aus der Quelle stehen soll (meinetwegen in Inch), aber die Tabelle grundsätzlich nach Meter sortiert.--McBayne (Diskussion) 21:01, 31. Mai 2022 (CEST)

in der Tabelle der Wert aus der Quelle stehen soll (meinetwegen in Inch), aber die Tabelle grundsätzlich nach Meter sortiert

Sowas wäre prinzipiell unerwünscht, weil für das Publikum nicht mehr nachvollziehbar.

Entweder alle Zahlenwerte sind in Inch angegeben, dann kann ohne irgendwelche Maßnahmen diekt nach dem Inhalt der Zelle sortiert werden.

Oder es sind Einheiten gemischt; dann wäre es konfus wenn die 3 größer ist als die 7 aber 7 größer als 12, weil du Inch und Meter und Fuß durcheinander angibst.

Tausender in der Darstellung sind noch machbar; da steht halt m und km bei den Angaben dran, das ist noch zu überblicken.

Deine Umrechnungsformeln müssten übrigens selbsterklärend sein; für MHz brauchst du keine Umrechnungsformel in Hz anzugeben.

Alle anderen Leutchen haben das bei allen anderen Tabellen für Publikum und spätere Pflege verständlich hinbekommen, ohne große Klimmzüge.

VG --PerfektesChaos 21:22, 31. Mai 2022 (CEST)

Alle anderen Leutchen: naja leider mache ich häufiger die Erfahrung, dass da noch der alte Geist ohne Belegpflicht und besonders bei Tabellen wird das gerne mal ignoriert (auch weil es so mühsam ist). Zurück zum Thema: Ich gebe zu, dass mein Wunsch nach meinem derzeitigen Wissen ein Spezialfall ist und darum nur ein "Wunsch" und nichts, das ich zwingend brauche. Wollte einfach klarmachen, dass der Alternativvorschlag von dir gerne angenommen wird, aber mein Wunsch dennoch bleibt, da es eben in meinem Fall zu mehr Quelltextgebastel (dafür weniger Vorlagen) führen wird. Viele Grüsse--McBayne (Diskussion) 22:26, 31. Mai 2022 (CEST)