Parameters: in-depth analysis regarding Scale parameters
Notably I considered how and to what extent we will need to represent ''nominal'' or ''ordinal scales''... In fact we should represent them, yet as cascaded delegate, since that is a relevant topic, yet not the primary use case -- and a topic with very deep complexity in itself.
This commit is contained in:
parent
59fbb8e6b0
commit
17c95a9b18
2 changed files with 529 additions and 129 deletions
|
|
@ -30,22 +30,42 @@
|
|||
|
||||
#include "lib/par/domain.hpp"
|
||||
|
||||
#include <optional>
|
||||
|
||||
|
||||
namespace lib {
|
||||
namespace par {
|
||||
|
||||
using std::optional;
|
||||
|
||||
|
||||
enum Metric {LIN ///< linear ordinary numeric scale
|
||||
,BIN ///< binary logarithm
|
||||
,NAT ///< natural logarithm
|
||||
,DEC ///< decibels (1/10 of 10-based log)
|
||||
,NOM ///< value encodes a nominal or ordinal scale
|
||||
};
|
||||
|
||||
/**
|
||||
* Interface: describe the properties of a value scale to use for parameters,
|
||||
* including range limits and metric (linear, logarithmic). The core operation
|
||||
* is to conform a value to this specific scale.
|
||||
* @todo not clear if we want a virtual interface here....?
|
||||
*/
|
||||
template<typename VAL>
|
||||
class Scale
|
||||
{
|
||||
public:
|
||||
virtual ~Scale(); ///< this is an interface
|
||||
Metric metric{LIN};
|
||||
/////////////////////////////OOO Quantiser?
|
||||
optional<VAL> minVal{};
|
||||
optional<VAL> maxVal{};
|
||||
optional<VAL> minUse{};
|
||||
optional<VAL> maxUse{};
|
||||
optional<VAL> neutral{};
|
||||
optional<VAL> defaultVal{};
|
||||
/////////////////////////////OOO »Sentinels« and nominal scales?
|
||||
bool zyclic{false};
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -82325,9 +82325,7 @@
|
|||
<node CREATED="1782951279208" ID="ID_854829576" LINK="https://en.wikipedia.org/wiki/Level_of_measurement#Chrisman's_typology_(1998)" MODIFIED="1782951313007" TEXT="aber offensichtlich nicht ausreichend und erschöpfend">
|
||||
<node CREATED="1788900130316" ID="ID_1794400222" LINK="https://www.researchgate.net/profile/Nicholas-Chrisman/publication/250016043_Rethinking_Levels_of_Measurement_for_Cartography/links/5a6a06e2a6fdccf88497c090/Rethinking-Levels-of-Measurement-for-Cartography.pdf?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6InB1YmxpY2F0aW9uIiwicGFnZSI6InB1YmxpY2F0aW9uIn19" MODIFIED="1788906073584" TEXT="Chrisman's Topology enthält hier relevante Skalen-Arten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<h2>
|
||||
Expanded list of levels of measurement
|
||||
|
|
@ -82436,17 +82434,14 @@
|
|||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788900156701" ID="ID_58657220" MODIFIED="1788900170890" TEXT="im Besonderen: die zyklische Skala">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1788900178434" ID="ID_792919762" MODIFIED="1788900555619" TEXT="dennoch nicht zielführend">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
alle diese Skalen-Arten sind auf die Perspektive einer Messung / Beobachtung und wissenschaftlichen Deskription festgelegt; diesen Ansatz halte ich für zu eng — einen entscheidenden Hinweis gibt mir hier die Existenz Verktor-wertiger Funktionen ⟹ generell können wir mehr als nur ein »zahlenwert-artiges« Objekt haben ⟹ ich weite sofort auf die dahinter liegende Domain-Ontology aus. Jeder Ansatz einer universellen Klassifikation aller Parameter-Typen ist von Vornherein zum Scheitern verurteilt, denn man muß immer etwas über die dahinterliegende Bedeutung wissen...
|
||||
|
|
@ -82455,8 +82450,7 @@
|
|||
Was wir hier höchstens erzielen können ist eine Standard-Codierung strukturierter Daten, deren Interpretation dann Hilfestellung benötigt durch Domain-spezifische Erweiterungen.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#cb051e" DESTINATION="ID_1110588547" ENDARROW="Default" ENDINCLINATION="-864;32;" ID="Arrow_ID_1562316330" STARTARROW="None" STARTINCLINATION="506;47;"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -84317,7 +84311,7 @@
|
|||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1788020250782" ID="ID_726206772" MODIFIED="1788020252329" TEXT="Domain">
|
||||
<node CREATED="1788020256597" ID="ID_1943514908" MODIFIED="1788915158752" TEXT="applyLimit(valBuff&) ⟵ zentral zur Anwendung der Scale">
|
||||
<arrowlink COLOR="#66299e" DESTINATION="ID_1913361537" ENDARROW="Default" ENDINCLINATION="-1137;-2314;" ID="Arrow_ID_1874303468" STARTARROW="None" STARTINCLINATION="-226;-24;"/>
|
||||
<arrowlink COLOR="#66299e" DESTINATION="ID_1913361537" ENDARROW="Default" ENDINCLINATION="-1137;-2314;" ID="Arrow_ID_1874303468" STARTARROW="None" STARTINCLINATION="-699;38;"/>
|
||||
</node>
|
||||
<node CREATED="1788020280703" ID="ID_1717784207" MODIFIED="1788020294892" TEXT="transferTo ⟵ generische Zuweisung"/>
|
||||
<node CREATED="1788020295960" ID="ID_903585085" MODIFIED="1788020320225" TEXT="TypeHandler<TY> ⟵ direkter Zugriff bei bekanntem Buffer_Typ"/>
|
||||
|
|
@ -85333,41 +85327,32 @@
|
|||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1788897245579" ID="ID_435216261" MODIFIED="1788897700193" TEXT="erwarte hier in Zukunft erhebliche Komplexitäten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Und zwar weil ich im Sinne flexibler Domain-Ontologien denke ⟶ wir brauchen »strukturierte Typen« (algebraische Datentypen) sowie diskrete symbolische Skalen, Summen- und Produkttypen. Die <i>erheblichen Komplexitäten</i> entstehen erwartungsgemäß dadurch, daß man das System dieser Skalen nicht a priori festlegen kann (denn dann hätte man sich implizit auf eine Domain-Ontologie festgelegt). Die Konsequenz ist, daß wir Skalen- und Strukturdefinitionen dynamisch, zur Laufzeit hinzufügen bzw. auf Projekt-Ebene festlegen müssen....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node CREATED="1788897701794" ID="ID_425709094" MODIFIED="1788898085454" TEXT="es wird so etwas wie ein »Schema« geben müssen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...das heißt, eine ebenfalls durch strukturierte Daten vorgegebene Konfiguration möglicher Strukturen, einschließlich der Typ-IDs.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788897715361" ID="ID_908037710" MODIFIED="1788898031718" TEXT="welches dann die Möglichkeit einer Codierung eröffnet">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...letztlich werden diese strukturierten Parameter und Daten immer in Form eines algebraischen Datentyps darstellbar sein, wobei allerdings die »Bedeutung« aus dem Schema mit herangezogen werden muß; genauer gesagt, die Semantik kann nur innerhalb einer im Hintergrund vorausgesetzten Domain-Ontologie formal definiert werden und dann in eine Codierung übersetzt — insofern die Domain-Ontologien <i>offen bleiben müssen,</i> sehe ich nur den Weg, bestimmte Arten von Anfragen jeweils in die Implementierung auf Basis einer Domain-Ontologie zu delegieren (konkret: in ein Plug-in, welches auf der Domain-Ontology aufbaut). Die insgesamt möglichen Arten von Anfragen, zusammen mit der jeweiligen Codierungs-Regel, ergibt zusammen das effektive Schema, welches formale Transformationen und manipulationen der Daten ermöglicht
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788900478144" ID="ID_1110588547" MODIFIED="1788900555619" TEXT="hier tut sich wieder das Problem der vorschnellen Univeral-Klassifikation auf">
|
||||
<linktarget COLOR="#cb051e" DESTINATION="ID_1110588547" ENDARROW="Default" ENDINCLINATION="-864;32;" ID="Arrow_ID_1562316330" SOURCE="ID_792919762" STARTARROW="None" STARTINCLINATION="506;47;"/>
|
||||
|
|
@ -85378,29 +85363,23 @@
|
|||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1788897268719" ID="ID_1742479107" MODIFIED="1788898332115" TEXT="Einschränkung des Wertebereichs innerhalb der Domain">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die Domain selber gibt den Basis-Datentyp vor; innerhalb dessen gibt es einen minimalen und maximalen Wert
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788897282565" ID="ID_340739677" MODIFIED="1788898377781" TEXT="einen Marker/Tag für die Metrik">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Im Grunde geht es hier um die Unterscheidung ob »linear«, »logarithmisch« oder »diskret«
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1788903390090" ID="ID_539998292" MODIFIED="1788903396165" TEXT="die Frage ist: wie einfach?">
|
||||
<icon BUILTIN="help"/>
|
||||
|
|
@ -85416,40 +85395,31 @@
|
|||
<node CREATED="1788903812798" ID="ID_1558113120" MODIFIED="1788903856765" TEXT="klassisches Beispiel ist der IEEE-Float (NaN, ±Inf, Denormal)"/>
|
||||
<node CREATED="1788903901070" ID="ID_33994468" MODIFIED="1788904064699" TEXT="effektiv bedeutet das: eine integrierte Nominal-Skala mit Fallunterscheidung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
wenn man dieses Muster streng nach den Regeln modelliert, dann wäre das ein algebraischer Datentyp mit einem Spezialfall-ENUM (Nominalskala), plus dem eigentlichen Zahlenwert, der aber nur bei bestimmten Nominal-Markern überhaupt betrachtet werden darf — also auch noch das Verhalten eines Summentyps
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788904066159" ID="ID_1394892717" MODIFIED="1788904309527">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die prinzipiell-korrekte Modellierung wäre aber eine <i>Verfehlung der Aufgabe</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Denn letztlich geht es darum, ein Zahlenwert-artiges, einfaches, unstrukturietes Objekt weiterzugeben und zu manipulieren — und zwar hinreichend effizient für den Rahmen von High-Performance-Code (heißt: nicht in der innersten Schleife, aber direkt daneben). Weder ist die Programmiersprache dafür gerüstet, algebraische Datentypen in diesem Kontext zu verarbeiten, noch sind die entsprechenden Mechanismen performant genug, um mit dem einfachen Normalfall einer »Zahl« mithalten zu können. Eine Modellierung dieses Musters als algebraischer Datentyp würde als unangemessene Prinzipienreiterei gewertet; das heißt, man muß schon verstehen, worauf es ankommt
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1788904412352" ID="ID_1436845505" MODIFIED="1788904424447" TEXT="ein ähnliches Verdikt gilt für zyklische Werte"/>
|
||||
|
|
@ -85460,26 +85430,36 @@
|
|||
<node CREATED="1788913085119" ID="ID_321653591" MODIFIED="1788913092162" TEXT="Zahlenwert-artige Skalen"/>
|
||||
<node CREATED="1788913092842" ID="ID_183664407" MODIFIED="1788913099119" TEXT="Nominal- und Ordinalskalen"/>
|
||||
<node CREATED="1788913108257" ID="ID_1978508484" MODIFIED="1788913129045" TEXT="sinnvolle Typisierung der Domäne"/>
|
||||
<node CREATED="1788913235538" ID="ID_1938858556" MODIFIED="1788913242333" TEXT="Klassifikation der Metrik"/>
|
||||
<node CREATED="1788913235538" ID="ID_1938858556" LINK="#ID_1393283991" MODIFIED="1789085352868" TEXT="Klassifikation der Metrik"/>
|
||||
<node CREATED="1788918860534" ID="ID_1509977565" MODIFIED="1788918873592" TEXT="optionale Quantisierung">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1788919824772" HGAP="50" ID="ID_1304551002" MODIFIED="1788920186012" TEXT="ein sehr komplexes Thema — Zusammenhang mit Zeit-Entitäten unklar" VSHIFT="1">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das hier ist wirklich eine partielle thematische Überschneidung; denn Quantisierung ist auch unabhängig von Zeitangaben sehr relevant für Parameter, denn es kann alle möglichen Arten von Grids geben, und auch der Rundungs- bzw. Quantisierungsmechanismus könnte variabel sein. Die <i>eigentliche Design-Frage</i> jedoch ist, ob das auf dieser Ebene dargestellt werden muß, oder ob man das Thema komplett in die Automations-Provision hineinnimmt. Dafür, das Thema hier mit einer generischen Schnittstelle zu bedenken, würde eine Betrachtung sprechen, welche die »Parameter« als eine Codierungs-Basis versteht, deren Bedeutung durch ein Schema und eine dahinter liegende Ontologie festgelegt wird
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#ea5e5f" DESTINATION="ID_768555857" ENDARROW="Default" ENDINCLINATION="2799;0;" ID="Arrow_ID_1670650996" STARTARROW="None" STARTINCLINATION="980;41;"/>
|
||||
<font NAME="SansSerif" SIZE="11"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1788913390558" ID="ID_1918141314" MODIFIED="1788913424326" TEXT="optionale Wertgrenzen"/>
|
||||
<node CREATED="1789072909948" ID="ID_1304391902" MODIFIED="1789072967720" TEXT="optionaler Nutzbereich">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1789072980930" HGAP="41" ID="ID_225529355" MODIFIED="1789073210521" TEXT="der regulärer Arbeitsbereich — wiewohl auch Werte außerhalb valide sind" VSHIFT="1">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Beispiel Sound-Fader-Gain: man arbeitet zwischen -80dB und 0dB ... aber alle positivien Werte und negative Werte bis -132dB sind valide und repräsentierbar — somit ist diese Angabe ein Richtwert für das UI, darf aber nicht gelampt werden
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<font NAME="SansSerif" SIZE="11"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1788913268654" ID="ID_743833460" MODIFIED="1788913275425" TEXT="optionaler Neutralwert"/>
|
||||
<node CREATED="1788913312056" ID="ID_919694201" MODIFIED="1788913316917" TEXT="optionaler Defaultwert"/>
|
||||
<node CREATED="1788913243384" ID="ID_217085587" MODIFIED="1788913345205" TEXT="optionale »Sentinels«"/>
|
||||
|
|
@ -85489,69 +85469,54 @@
|
|||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1788914733259" ID="ID_1024480560" MODIFIED="1788914744874" TEXT="Funktionalität definieren">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1788914766575" ID="ID_1913361537" MODIFIED="1788915158752" TEXT="Unterstützung der Domain-Operationen">
|
||||
<linktarget COLOR="#66299e" DESTINATION="ID_1913361537" ENDARROW="Default" ENDINCLINATION="-1137;-2314;" ID="Arrow_ID_1874303468" SOURCE="ID_1943514908" STARTARROW="None" STARTINCLINATION="-226;-24;"/>
|
||||
<linktarget COLOR="#66299e" DESTINATION="ID_1913361537" ENDARROW="Default" ENDINCLINATION="-1137;-2314;" ID="Arrow_ID_1874303468" SOURCE="ID_1943514908" STARTARROW="None" STARTINCLINATION="-699;38;"/>
|
||||
<node CREATED="1788915235881" ID="ID_1781182087" MODIFIED="1788915260680" TEXT="hier muß die Domain::applyLimit() speziell (delegierend) implementiert werden"/>
|
||||
<node CREATED="1788915261413" ID="ID_13399317" MODIFIED="1788915458135">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
zudem: muß sicherstellen daß <b>jede zuweisende Operation</b>  diese Methode anwendet
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Der Knackpunkt dabei sind die TypeHandler-Implementierungen, denn diese verwenden zunächst (nur) das lokal implementierte generische preClamp (was die Grenzen der BaseDomain durchsetzt und Bool-werte per Schwelle bildet)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node CREATED="1788915458123" ID="ID_257415193" MODIFIED="1788915772087" TEXT="TypeHandler kann man direkt anwenden (per Domain-Interface)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
TypeHandler bezieht sich aber auf einen explizit und separat gegebenen Buffer, und konditioniert diesen nur im Hinblick auf den direkt spezifizierten Basis-Typ — wiewohl hier durchaus eine Unschärfe im Aufbau der Interfaces vorliegt, da ja in der <font face="Monospaced">conform()</font> - Operation schon ein impliziter »Typ« angewendet wird, dessen Bedeutung nicht zweifelsfrei klar ist (man könnte geneigt sein, hier schon den vollständigen Parameter-Typ zu vermuten)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788915466090" ID="ID_704868487" MODIFIED="1788915846239" TEXT="aber relevant sind nur Operationen die den Parameter-Buffer berühren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...denn es geht um die Durchsetzung einer Invariante für alle Werte »im« Parameter: sie müssen stets zum Parameter-Typ konform sein
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788915850279" ID="ID_66483155" MODIFIED="1788915926006" TEXT="⟹ das betrifft also die Anwendung des Provision-Interfaces (auch dynamisch)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...also jeweils wenn man sich <i>einen Wert holt,</i> was auch den »pull« der Automationsfunktion einschließt
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -85561,9 +85526,7 @@
|
|||
<node CREATED="1788915984439" ID="ID_1687814760" MODIFIED="1788915994071" TEXT="diesen mit der Scale konform machen"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1788916016718" ID="ID_423001819" MODIFIED="1788917735339" TEXT="grundsätzlich kann das scheitern">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...was aber als ein seltener Grenzfall zu betrachten ist, und normalerweise durch die übergeordnete Konfiguration ausgeschlossen werden soll. Für die geläufigen Szenarien gibt es zudem stets eine Regel, nach der konditioniert werden kann...
|
||||
|
|
@ -85583,8 +85546,7 @@
|
|||
Somit bleiben eigentlich nur die Fälle einer speziellen Domain ohne Defaultwert — denn in diesem Fall gibt es keine übergeordnete Metrik, nach der <i>interpoliert</i> werden könnte, sondern ein Code, der nicht zur Skala gehört, ist ungültig und muß zurückgewiesen werden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -85593,24 +85555,19 @@
|
|||
<node CREATED="1788917819659" ID="ID_1748818920" MODIFIED="1788917847680" TEXT="wird benötigt um die Automations-Provision auf einen Basis-Wert anzuwenden"/>
|
||||
<node CREATED="1788917877107" ID="ID_665324760" MODIFIED="1788918801557" TEXT="hängt ab...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
hier muß ggfs. eine Logarithmus / Exponential-Konvertierung stattfinden, möglicherweise auch eine Quantisierung
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node CREATED="1788917882892" ID="ID_52090158" MODIFIED="1788917894364" TEXT="von der Metrik des Ergebnis-Parameters"/>
|
||||
<node CREATED="1788917904223" ID="ID_1099728874" MODIFIED="1788917932855" TEXT="ggfs von einer abweichenden Scale der Automations-Provision"/>
|
||||
</node>
|
||||
<node CREATED="1788918491304" ID="ID_991615591" MODIFIED="1788918753513" TEXT="Beschluß: hier Heuristik — keine eigene Taxonomie">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Grundsätzlich soll hier im Bereich der Scale nur <i>eine Codierung</i>  gehandhabt werden — es besteht die Gefahr, doch noch „durch die Hintertür“ eine universelle Wert-Ontologie einzuführen.
|
||||
|
|
@ -85624,11 +85581,452 @@
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1789002587495" ID="ID_509669988" MODIFIED="1789002595532" TEXT="Design nochmal reflektieren">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1789002597684" ID="ID_65698909" MODIFIED="1789072159474" TEXT="die Frage ist: wie sehr muß ich mich aktuell um die Nominal/Ordinal-Skalen kümmern?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1789072181799" ID="ID_961319455" MODIFIED="1789072203699" TEXT="konzeptionell sollten sie explizit in der Scale-Definition markiert sein"/>
|
||||
<node CREATED="1789072817738" ID="ID_621244531" MODIFIED="1789072844560" TEXT="man könnte »Scales« ins Zentrum stellen — oder als Rand-Thema betrachten"/>
|
||||
<node CREATED="1789073532638" ID="ID_1112609990" MODIFIED="1789073555185" TEXT="Eine Frage des »Navigierens« : was verbaut man sich und womit verspielt man sich"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789002615502" ID="ID_1161327543" LINK="https://claude.ai/share/784807f3-8fb3-4c1f-85c0-95355e79a9db" MODIFIED="1789082794573" TEXT="eine Design-Konversation mit Claude geführt">
|
||||
<icon BUILTIN="wizard"/>
|
||||
<node CREATED="1789002670195" ID="ID_1638903618" MODIFIED="1789074297728" TEXT="Schritt-1 : gebe ihm nur high-level Kontext">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...das, was er über Lumiera inferrieren kann, sowie das neue »Routing«-Dokument (design/model/Routing). Frage dann nach Möglichkeiten zur Repräsentation einer Nominal / Odinal-Skala...
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
<u>Hinweis</u>: hierzu ist bedeutsam, daß »Claude« und »Claude-Code« zwei getrennte Produkte sind, welche sich offensichtlich keinen gemeinsamen »Memory« teilen (ausnahme <i>könnte</i> sein, was ich über mich selber im Account hinterlegt habe). Das gilt schon allein deshalb, weil man den Memory von Claude-Code eigens als Dateien verwalten kann (und ich habe x-mal die Erfahrung gemacht, daß beide Tools nicht direkt miteinander kommunizieren). Das bedeutet, »Claude« (der Chatbot) hat nicht diese Mindmap mit den Entwürfen gelesen, aber ich gebe ihm das aus der damals gemachten Auswertung resultierende Dokument zum »Routing« als Website; insofern bekomme ich durch diese Konversation nochmal einen neuen Blickwinkel, bzw. Projektion der üblichen Betrachtungsweisen zum Thema
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-1"/>
|
||||
<node CREATED="1789002742811" ID="ID_1152416586" MODIFIED="1789072397833" TEXT="Claude inferriert eine ähnliche Implementierung wie ich sie auch gedacht hatte">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...eine Mapping-Tabelle, eine Registry um die Scale per ID zu greifen, ein leichtgewichtiges front-End
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789002797682" ID="ID_1195339501" MODIFIED="1789002819305" TEXT="Claude identifiziert ebenfalls die Disktinktion in geschlossene / offene Domain">
|
||||
<node CREATED="1789002841595" ID="ID_1949953740" MODIFIED="1789072414196" TEXT="Beispiel geschlossen: Mixing-Modes"/>
|
||||
<node CREATED="1789002820665" ID="ID_193308851" MODIFIED="1789072423145" TEXT="Beispiel offen: Output-Designations">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789002768534" ID="ID_1611770418" MODIFIED="1789002788215" TEXT="Hinweis auf Boost.Describe">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1789072470984" ID="ID_944709055" MODIFIED="1789072483349" TEXT="Ennumeratoren definieren »ohne Macros«"/>
|
||||
</node>
|
||||
<node CREATED="1789002877399" ID="ID_284558086" MODIFIED="1789002917150" TEXT="Vorschlag: sollte alle Manipulationen als Endomorphism-Transformationen darstellen">
|
||||
<node CREATED="1789002919164" ID="ID_1254888737" MODIFIED="1789002932494" TEXT="die Scale würde dann gültige Endomorphismen bestimmen"/>
|
||||
<node CREATED="1789002933232" ID="ID_1025941770" MODIFIED="1789002942386" TEXT="Funktionen können in einer Closure kombiniert werden"/>
|
||||
<node CREATED="1789002943029" ID="ID_701292718" MODIFIED="1789002962027" TEXT="der Builder sieht nur die Repräsentation + eine Transformations-Funktion"/>
|
||||
<node BACKGROUND_COLOR="#e0d8b0" COLOR="#2f0f69" CREATED="1789002963804" ID="ID_1683719946" MODIFIED="1789003003644" TEXT="freut mich: da bestätigt Claude meinen Design-Entwurf">
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789003040641" ID="ID_1955090392" MODIFIED="1789003058485" TEXT="Vorschlag: sollte eine compare-Funktion auf das Virtual-API legen">
|
||||
<node CREATED="1789003064974" ID="ID_1884556693" MODIFIED="1789003072083" TEXT="und die C++20 Orderings verwenden"/>
|
||||
<node CREATED="1789003072741" ID="ID_16804986" MODIFIED="1789003090213" TEXT="damit könnte man den Unterschied Ordinal / Nominal weitgehend abfedern"/>
|
||||
</node>
|
||||
<node CREATED="1789073367031" ID="ID_1377488929" MODIFIED="1789073433179" TEXT="Einsicht: man kann die ID-Labels und weitere Ebenen von der Engine fernhalten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die Engine bekommt stets nur die <i>Codierung</i> einer Scala zu sehen, und für Transformationen, Manipulationen und Automation bekommt sie einen Funktor, in denen die Scalen-Logik bereits eingelassen wurde.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789003099210" ID="ID_1821203922" MODIFIED="1789072879092" TEXT="Schritt-2 : Festlegungen jetzt / was ist Overengineering?">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Gebe nun Claude eine ganz kompakte Skizze meines Prototypen. Biete schon die Tendenz an, sich auf die numerischen Skalen zu fokussieren
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-2"/>
|
||||
<node CREATED="1789003174968" ID="ID_1732198976" MODIFIED="1789003277104" TEXT="wie erwartet, schwenkt Claude damit auf KISS und YAGNI ein">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...was ich aber gut finde, weil es zumindest die Konsistenz des Argumentations-Raumes aufzeigt (grade im Lichte des weiteren Kontexts, den ich im ersten Schritt ausgeleuchtet habe)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789003279513" ID="ID_704186035" MODIFIED="1789003298106" TEXT="Claude weist aber auf einige wichtige Fallen hin">
|
||||
<icon BUILTIN="wizard"/>
|
||||
<node CREATED="1789003361030" ID="ID_1530526074" MODIFIED="1789003373195" TEXT="Separate hard bounds from the control range">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<strong http-equiv="content-type" content="text/html; charset=utf-8">Separate hard bounds from the control range.</strong> These get conflated constantly and they are different things. A hard bound says values outside are illegal, and conform either clamps or errors. A control range says "this is the travel of the fader", and values outside are perfectly legal but unusual. Gain is the obvious case: the useful range is maybe −60 to +12 dB, but +30 dB is not an error. If you have one min/max pair it will silently become whichever of the two you happened to need first. Two pairs, or one pair plus a flag, costs almost nothing today.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789003389340" ID="ID_1859580346" MODIFIED="1789003427521" TEXT="Decide whether the stored value is in the metric's own units or in a canonical unit">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<strong http-equiv="content-type" content="text/html; charset=utf-8">Decide whether the stored value is in the metric's own units or in a canonical unit.</strong> This is the one place where your design page makes a claim that the implementation can quietly break. The page says combining is addition in a logarithmic scale and multiplication in a linear one, and that this is why scale belongs to the type. That's only true if the stored representation actually <em>is</em> in dB. If you store canonical linear and treat the metric as a display attribute, the joining operator becomes ambiguous again, and you're back to the thing the page argues against. My suggestion: store in the metric's units, so "the metric determines the join" is literally true rather than an interpretive claim.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789003443650" ID="ID_1920682421" MODIFIED="1789003456221" TEXT="Cyclic interacts with min/max">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
Cyclic interacts with min/max in a way you'll want to be explicit about: for a cyclic scale, min/max define the period rather than a bound, and conform wraps instead of clamping. That's cheap. What isn't cheap, and what you should defer, is cyclic
|
||||
|
||||
<p>
|
||||
<em http-equiv="content-type" content="text/html; charset=utf-8">interpolation</em>: shortest arc versus explicit winding for an automation curve crossing the seam. That belongs to the automation function, not to Scale.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1789004075031" ID="ID_621869035" MODIFIED="1789004131199" TEXT="Sentinels: distinquish use-cases">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<h3 http-equiv="content-type" content="text/html; charset=utf-8" dir="ltr">
|
||||
Sentinels
|
||||
</h3>
|
||||
<p dir="ltr">
|
||||
Worth separating two things that both look like sentinels.
|
||||
</p>
|
||||
<p dir="ltr">
|
||||
Some are genuine domain members. Minus-infinity gain, "off", the extremal end of a fader. These have a definite position in the ordering and definite algebraic behaviour: −∞ dB is the absorbing element for gain combination, 0 dB is the identity. They belong <em>in</em> the domain, and a log-metric numeric scale that can represent its own absorbing element is more useful than one that can't. IEEE gets this part right, and borrowing <code>-inf</code> for exactly this is reasonable.
|
||||
</p>
|
||||
<p dir="ltr">
|
||||
Others are not values at all. "Unset", "indeterminate", "multiple values selected in the GUI", "bypassed". These have no position in the ordering, no join behaviour, and every arithmetic operation on them is a bug. Putting them in-band is how you get NaN's contagion problem, plus a per-type encoding story (NaN payloads for float, <code>INT_MIN</code> for int, nothing sensible for bool). You have four 64-bit slots and only need one for the value. A small out-of-band state word in the container is uniform across every implementation type, costs you nothing, and keeps comparison honest.
|
||||
</p>
|
||||
<p dir="ltr">
|
||||
Then make <code>conform</code> the single choke point that recognises and resolves both kinds. Everything downstream gets to assume it's looking at a real value.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#c50711" DESTINATION="ID_621869035" ENDARROW="Default" ENDINCLINATION="108;0;" ID="Arrow_ID_191032855" SOURCE="ID_1491788669" STARTARROW="None" STARTINCLINATION="34;-37;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1789003479184" ID="ID_833220665" MODIFIED="1789003552060" TEXT="The two doors that actually close">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p http-equiv="content-type" content="text/html; charset=utf-8" dir="ltr">
|
||||
If you want a rule for where to stop, it's this: build now only what you couldn't add later without changing code you can't reach. Behind your vtable, everything is reachable. Two things are not.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<b>The persisted form</b>. The moment a session file records a parameter with a scale, the meaning of its qualifiers is frozen or needs migration. It's worth spending more thought on what a Scale looks like when written out than on what it looks like in memory.
|
||||
</li>
|
||||
<li>
|
||||
<b>Keeping Scale reducible to data</b>. You mention a possible connection to rules later. A rules system can only reason about a Scale if the Scale <em>is</em>  a small tuple of facts (metric, bounds, cyclic flag, domain-set id, default) with a fixed interpreter, rather than a polymorphic object whose behaviour exists only as C++. That constraint costs you nothing today, since your qualifier-based design already satisfies it. It's just worth adopting as a deliberate rule so that a future <code>conform()</code>  override doing something clever doesn't quietly break it.
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1789003555028" HGAP="31" ID="ID_1491788669" MODIFIED="1789004138542" TEXT="das hätte ich nicht so klar gesehen!" VSHIFT="6">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Diese zwei Askpekte waren es wert, diese ganze Konversation zu führen. Dadurch, daß ich den Fokus, rückwärts gehend auf "Overengineering" gelegt habe, und Claude da nach einer Grenze gefragt habe, sind diese beiden Aspekte hervorgetreten (sie überraschen mich nicht, aber in der Weise, wie ich in das ganze Design-Feld reingegangen bin, habe ich diese zwei Punkte nicht klar gesehen)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#c50711" DESTINATION="ID_621869035" ENDARROW="Default" ENDINCLINATION="108;0;" ID="Arrow_ID_191032855" STARTARROW="None" STARTINCLINATION="34;-37;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789003722969" ID="ID_130367743" MODIFIED="1789003743072" TEXT="spreche auch nochmal meine Sorgen wegen der Registrierung neuer Skalen an">
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789003749219" ID="ID_461550167" LINK="#ID_1480682856" MODIFIED="1789073942542" TEXT="Claude kommt unabhängig auf die gleiche Einschätzung wie ich">
|
||||
<icon BUILTIN="wizard"/>
|
||||
</node>
|
||||
<node CREATED="1789003763008" ID="ID_111187427" MODIFIED="1789003932761" TEXT="auch Claude sagt: einfach leaken lassen....">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Er argumentiert genauso, wie ich auch gedacht hatte (und Claude kann hier definitiv nicht meine Überlegungen kennen, denn die Mindmap habe ich nur in Claude-Code auslesen lassen): es sind höchstens ein paar hundert bis tausend.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node BACKGROUND_COLOR="#e0d8b0" COLOR="#2f0f69" CREATED="1789003936864" HGAP="28" ID="ID_1054751581" MODIFIED="1789004031590" STYLE="fork" TEXT="ich werte das als Bestätigung für den »allgemeinen Kompaß«" VSHIFT="1">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
es zeigt mir, daß meine Überlegungen sich hier im Rahmen einer allgemeinen Plausibilität des Faches bewegen, und nicht aus meinem eigenen Wunschdenken stammen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789003776080" ID="ID_1146377144" MODIFIED="1789003859523" TEXT="zusätzlicher Hinweis: man könnte es an »quiescence points« binden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Damit meint Claude, entweder eine gezielte Clean-up-Operation, oder die aktuelle Session schließen und aus dem Log neu öffnen. Damit kann man sich das ganze Thema "GC" sparen.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="wizard"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789077203159" ID="ID_1690518417" MODIFIED="1789077559609" TEXT="Nebenbei: Claude weist auf »interned Strings« hin">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Claude meint, wenn Lumiera bereits ein System für interned Strings hätte (er hat auch irgendwie lib::Symbol <i>entdeckt</i>), dann bestünde die Gefahr, diese Funktionalität zu duplizieren...
|
||||
</p>
|
||||
<p>
|
||||
Ich habe da <b>Zweifel bezüglich dieser Einschätzung</b>: inwiefern überlappt sich das überhaupt? Wenn ich hier etwas »interne«, dann eine ganze Mapping-Tabelle; nach meinem Verständniss kommt einzelnen Enumeratoren eben grade keine eigenständige symbolische Bedeutung zu (das literal gleiche Symbol kann in verschiedenen Skalen auftreten, und dort unterschiedliche Bedeutung haben). Der reine Aspekt der <i>Deduplikation</i> erscheint mir demgegenüber sekundär — und wenn man dann später <i>eben doch bestimmte Skalen aufräumt und verwirft,</i>  dann stünde dem eine Registrierung als Symbol-String sogar im Wege
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="wizard"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789074370284" ID="ID_1609743766" MODIFIED="1789074377700" TEXT="Schlußfolgerungen (am Tag danach)">
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1789077067749" ID="ID_1147548998" MODIFIED="1789077105470" TEXT="sollte mein Design wie geplant »durchziehen« und komplexere Themen offen lassen">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1789077645299" ID="ID_637242141" MODIFIED="1789077723437" TEXT="Design-Entscheidung für generische opaque »Parameter« widerspricht Nominalskalen">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1789077725381" ID="ID_1711703030" MODIFIED="1789077739820" TEXT="eine angemessene Behandlung derselben erfordert ein erweitertes API"/>
|
||||
<node CREATED="1789077740556" ID="ID_291550503" MODIFIED="1789077757288" TEXT="das läßt sich nicht auf ein generisches »Wert«-API reduzieren"/>
|
||||
<node CREATED="1789077798138" ID="ID_766455054" MODIFIED="1789077832416">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
⟹ Parameter <i>integrieren</i> lediglich die Behandlung von Nominal/Ordinalskalen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1789077840767" ID="ID_959573058" MODIFIED="1789078015922" TEXT="Bezüglich Typen ist hier ein Switch-on-Tag nicht zu vermeiden">
|
||||
<node CREATED="1789077860644" ID="ID_1647596990" MODIFIED="1789077875046" TEXT="und zwar insofern sich das GUI an einen Parameter anpaßt"/>
|
||||
<node CREATED="1789077886024" ID="ID_911258074" MODIFIED="1789077974436" TEXT="hierzu ist ein »Pattern-Match« inhaltlich nicht zu vermeiden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...also die gemeinhin problematische Struktur, daß eine Reihe von Kategorien an unabhängigen Stellen im System bekannt ist und jeweils nach Erkennen eines Markers verzweigt wird — wodurch die encapsulation gebrochen wird, und eine <i>verteilte Logik</i> entsteht
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789078035474" ID="ID_1133841636" MODIFIED="1789078084451" TEXT="eine Nominal-Symbol-Behandlung hängt hier als kaskadierender Sonderfall drin"/>
|
||||
</node>
|
||||
<node CREATED="1789078344270" ID="ID_1033159734" MODIFIED="1789078372907" TEXT="Parameter sind auf dieser Ebene ein »Toolkit«">
|
||||
<node CREATED="1789078374144" ID="ID_1445435993" MODIFIED="1789078383294" TEXT="einzelnen Nutzmöglichkeiten darf nicht vorgegriffen werden"/>
|
||||
<node CREATED="1789078384055" ID="ID_306251422" MODIFIED="1789078422220" TEXT="im Besonderen die Sentinels bedingen eine erweiterte Verknüpfungs-Logik"/>
|
||||
<node CREATED="1789078470649" ID="ID_1129204326" MODIFIED="1789078491346" TEXT="ein (Proto)Type kann optionale und falsche Werte einschließen — oder nicht"/>
|
||||
<node CREATED="1789078432864" ID="ID_969086554" MODIFIED="1789078448278" TEXT="die Interpretation verweist in einzelne Domain-Ontologien"/>
|
||||
<node CREATED="1789078504040" ID="ID_1032247841" MODIFIED="1789078529636" TEXT="das Thema kann nicht abschließend behandelt werden"/>
|
||||
</node>
|
||||
<node CREATED="1789079643596" ID="ID_1571313547" MODIFIED="1789079662309" TEXT="die Scale sollte rein symbolisch dargestellt werden">
|
||||
<node CREATED="1789079678938" ID="ID_311127403" MODIFIED="1789079685621" TEXT="als ein Satz algebraische Daten"/>
|
||||
<node CREATED="1789079686328" ID="ID_1110601241" MODIFIED="1789079697987" TEXT="ausgestattet mit Informationsfunktionen"/>
|
||||
<node CREATED="1789079698677" ID="ID_1651075832" MODIFIED="1789079705138" TEXT="jedoch ohne Operationalisierung"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1789082704022" ID="ID_1925473607" MODIFIED="1789082723794" TEXT="muß eine Registry bereits jetzt bauen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789082726792" ID="ID_383248634" MODIFIED="1789082813652" TEXT="Frage im bestehenden Chat nochmal nach — mit konkretem Implementierungs-Szenario">
|
||||
<icon BUILTIN="wizard"/>
|
||||
<node CREATED="1789082815287" ID="ID_104427970" MODIFIED="1789082927619" TEXT="beschreibe Registrierung des Scale-Desriptors">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<ul>
|
||||
<li>
|
||||
sitzt im Implementierungs-Objekt innnerhalb der Parameters
|
||||
</li>
|
||||
<li>
|
||||
die Scale greift in die Implementierung gewisser API-Methoden ein — join() und conform()
|
||||
</li>
|
||||
<li>
|
||||
dort gibt es einen IDRecord, der eine Scale-ID enthält
|
||||
</li>
|
||||
<li>
|
||||
per Scale-ID wird aus einer Registry der Scale-Descriptor geholt
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789082929328" ID="ID_155716301" MODIFIED="1789083093033" TEXT="stelle Zugriffs-Situation dar: Render-Worker ⟷ Update durch Builder">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Render-Worker verwenden bereits bekannte IDs; Builder-Lauf entdeckt neue Scales und belegt damit neue IDs, nach dem Builder-Lauf erfolgt ein commit + swap des Models ⟹ hier kann man release / acquire - barrier unterstellen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789082963820" ID="ID_1505010273" MODIFIED="1789083023010" TEXT="frage gezielt nach einer Deque-Storage">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Diese Frage nutze ich als Challenge, um das Argument in Gang zu setzen; Claude greift das wie erwartet auf
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789083098339" ID="ID_446858787" MODIFIED="1789083111206" TEXT="Claude zerlegt in zwei Teilprobleme">
|
||||
<icon BUILTIN="wizard"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1789083115404" ID="ID_564486206" MODIFIED="1789083136019" TEXT="Sichtbarkeit der neuen Scale-Definition ⟹ Argument stichhaltig">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1789083137852" ID="ID_1965196365" MODIFIED="1789083170965" TEXT="Interne Index-Organisation in der Deque ⟹ nicht durch das Argument gedeckt">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789083189238" ID="ID_735608493" MODIFIED="1789083464492" TEXT="Claude schlägt als Alternative eine globale Index-Tabelle vor, mit atomic-Slots für »Extents«">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<h3>
|
||||
The structure that removes the problem
|
||||
</h3>
|
||||
<p>
|
||||
Fixed top-level index, chunked storage, chunk pointers published
|
||||
atomically. The top-level array never reallocates, so the reader's
|
||||
address computation touches nothing a writer mutates.
|
||||
</p>
|
||||
<div>
|
||||
<div role="group" aria-label="cpp code" tabindex="0">
|
||||
<div>
|
||||
<div>
|
||||
<pre>
|
||||
<font size="2">class ScaleRegistry
|
||||
{
|
||||
static constexpr size_t CHUNK = 256;
|
||||
static constexpr size_t MAX = 256; // ≙ 65536 scales
|
||||
|
||||
struct Chunk { ScaleDescriptor slot[CHUNK]; };
|
||||
|
||||
std::array<std atomic="#DEFAULT" size="2"><chunk size="2">, MAX> chunk_{};
|
||||
std::mutex writeGuard_; // writers only
|
||||
size_t next_ {0}; // guarded
|
||||
|
||||
public:
|
||||
ScaleDescriptor const&
|
||||
operator[] (ScaleID id) const // lock-free, engine path
|
||||
{
|
||||
return chunk_[id / CHUNK].load (std::memory_order_acquire)
|
||||
->slot[id % CHUNK];
|
||||
}
|
||||
|
||||
ScaleID
|
||||
define (ScaleDescriptor def) // builder path
|
||||
{
|
||||
std::lock_guard lock{writeGuard_};
|
||||
size_t id = next_++;
|
||||
auto& head = chunk_[id / CHUNK];
|
||||
if (not head.load (std::memory_order_relaxed))
|
||||
head.store (new Chunk{}, std::memory_order_release);
|
||||
head.load (std::memory_order_relaxed)->slot[id % CHUNK] = std::move(def);
|
||||
return ScaleID{id};
|
||||
}
|
||||
};</font></pre>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
The reader does one acquire load and two integer operations. On x86 the
|
||||
acquire is free; on ARM it is a <code>ldar</code>. Nothing the writer does can
|
||||
move a chunk or rewrite the index.
|
||||
</p>
|
||||
<p>
|
||||
Note what this buys beyond correctness: the guarantee becomes <em>local</em>.
|
||||
You no longer have to reason about the whole build-publish pipeline to
|
||||
convince yourself the registry is sound. Slot contents still rely on
|
||||
your model-swap release, which is fine and correct, but the container no
|
||||
longer participates in that argument at all. Global correctness
|
||||
arguments that span subsystems are the ones that break silently when
|
||||
someone later adds a shortcut.
|
||||
</p>
|
||||
<p>
|
||||
If you would rather not have chunks at all, the degenerate version is a
|
||||
single reserved array with a capacity you decide is enough. Scale
|
||||
definitions arrive at human speed, so a few thousand is a lot. The
|
||||
chunked form costs about fifteen extra lines and removes the need to
|
||||
guess.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="wizard"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#accdc3" COLOR="#3f4015" CREATED="1789083492013" ID="ID_816421539" MODIFIED="1789083498973" TEXT="zwei weitere Vorschläge">
|
||||
<icon BUILTIN="wizard"/>
|
||||
<node CREATED="1789083500804" ID="ID_1926406999" MODIFIED="1789083769420" TEXT="der Builder soll den Zugriff »compilieren« in einen VTable-Zugriff">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das wäre nur dann möglich, wenn das gesamte mögliche Verhalten bereits zur Compiletime feststeht, und sich rein aus den Definitions-Daten im Scale-Descriptor ergibt (<font color="#3111d1">ist plausibel, und ist nach meinem derzeitigen Verständnis tatsächlich der Fall — </font><font color="#9b0221">könnte aber in Zukunft doch noch anders sein</font>). Dann soll der Builder bzw. die Konstruktion eines Paramers alles so einrichten, daß die Interpretation der Scale-Spec gar nicht mehr notwendig ist, sondern bereits in die relevanten (virtuellen) Zugriffs-Operationen konsolidiert wurde. Konsequenterweise mußte dann der Lese-Pfad (aus der Engine) überhaupt keinen ID-Index-Zugriff mehr machen, und das ganze Problem würde sich auflösen; man würde dann eine einfache Registry nehmen (meinetwegen eine Deque) und hinter ein Mutex stellen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1789083773352" ID="ID_276015612" MODIFIED="1789083855805" TEXT="nach Möglichkeit sollten die Scale-IDs einfach verbraucht werden — niemals »wiederverwendet«">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...wobei hier Claude mit 32-Bit argumentiert (ich weiß aber, daß ich die Zahl der Scales stärker limitiere, weil ich dort auch noch die Base-Domain und eine Parameter-ID unterbringen möchte). Das Argument als Solches aber bleibt valide
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1788134884746" ID="ID_195532610" MODIFIED="1788134888546" TEXT="Builder-Notation">
|
||||
|
|
@ -85917,9 +86315,7 @@
|
|||
</node>
|
||||
<node CREATED="1788919077662" ID="ID_768555857" MODIFIED="1788919903351" TEXT="wie gehen wir um mit Zeit-Entitäten als Parameterwerten?">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Da ist erst einmal das Problem daß hier eine separate Algebra definiert wurde; außerdem wird bei den Zeit-Entitäten auch eine Intention ausgedrückt (Offset, Duration, TimeSpan); und schließlich gilt es die Quantisierung und die Time-Codes zu beachten. Dieser Fall tritt <b>definitiv</b> auf und <b>ist sehr relevant</b>: es könnte einen animierbaren Delay geben, oder andere temporale Qualifikationen (Time-Trail, zeitliche Integration).
|
||||
|
|
@ -85939,8 +86335,7 @@
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#ea5e5f" DESTINATION="ID_768555857" ENDARROW="Default" ENDINCLINATION="2799;0;" ID="Arrow_ID_1670650996" SOURCE="ID_1304551002" STARTARROW="None" STARTINCLINATION="980;41;"/>
|
||||
</node>
|
||||
<node CREATED="1784672259758" ID="ID_1765265570" MODIFIED="1784673727205" TEXT="wie gehen wir mit Produkttypen um (Vektoren, Farben)?">
|
||||
|
|
@ -85985,42 +86380,33 @@
|
|||
<linktarget COLOR="#565978" DESTINATION="ID_788143596" ENDARROW="Default" ENDINCLINATION="446;-1047;" ID="Arrow_ID_1753071560" SOURCE="ID_222998203" STARTARROW="None" STARTINCLINATION="-558;35;"/>
|
||||
<node CREATED="1788902655996" ID="ID_214848012" MODIFIED="1788902873096" TEXT="es soll »alles Andere« handhaben (Farben, Vektoren, Masken)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Ganz ausdrücklich sollen hier auch komplex struktuierte Gebilde mit eingeschlossen sein, zu deren Interpretation eine Domain-Ontology mitwirken muß.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788902746760" ID="ID_653627897" MODIFIED="1788903101267" TEXT="es wird per Continuation-Funktor zugegriffen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Ich versuche dem Drang zu widerstehen, hier <i>doch noch ein allgemeines Schema</i> anzulegen; vielmehr wird konsequent die Handhabung der Daten per Callback-Funktor in den Nutz-Kontext zurück deflektiert. Der einzige zulässige Mechanismus ist die Bildung von »Prototypen« — wobei dann an die Stelle der <font face="Monospaced" color="#522e2e">Scale</font> (des einfachen Parameters) hier ein <i>Schema</i>  tritt
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1788902766485" ID="ID_599153391" MODIFIED="1788903238329" TEXT="Daten-Storage ist »woanders«">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das ParamSet-Objekt ist grundsätzlich nur ein front-End-Handle, das auf anderweitig <i>managed data</i> verweist.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1788902778804" ID="ID_382988116" MODIFIED="1788902784397" TEXT="future-work">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
|
|
@ -86028,9 +86414,7 @@
|
|||
</node>
|
||||
<node CREATED="1788903241758" ID="ID_28313284" MODIFIED="1788903369448" TEXT="beide sind generisch verwandt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Es ist sinnlos, beide unter einen gemeinsamen Typ zu subsumieren, aber der Schematismus für beide Fälle soll jeweils analog sein...
|
||||
|
|
@ -86047,8 +86431,7 @@
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1788902285068" ID="ID_631494622" MODIFIED="1788902387436" TEXT="Begriffliche Ordnung: Disposition, Typ, Domain, Scale, Provision">
|
||||
|
|
@ -86063,16 +86446,13 @@
|
|||
<node CREATED="1788902427946" ID="ID_1446859021" MODIFIED="1788902444362" TEXT="für den Zugriff liefert der Verwender die Typ-Information"/>
|
||||
<node CREATED="1788902445047" ID="ID_1698376937" MODIFIED="1788902555756" TEXT="es gibt einen optimierten Pfad (der implizit bleibt: bei Typ-Match)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Grundsätzlich gibt die jeweilige Verwendung einen Typ vor, und in diesen Typ wird transparent konvertiert; wenn aber »rein zufällig« der geforderte Typ dem nativen Typ entspricht, dann wird der optimierte Code-Pfad getriggert und der Zugriff geht an jedweder Indirektion vorbei
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue