LUMIERA.clone/tests/16parameter.tests

TESTING "Library Test Suite: parameters" ./test-suite --group=param


TEST "Parameter Values" Parameter_test <<END
return: 0
END


TEST "Parameter Domain Type" ParameterDomain_test << END
return: 0
END


PLANNED "Parameter Provision" ParameterProvision_test << END
return: 0
END


TEST "Parameter value scales" ParameterScale_test << END
return: 0
END


PLANNED "Enumeration domains" NomSet_test << END
return: 0
END
Parameters: start a design draft Parameters and Automation will certainly play a crucial role eventually. They will form a network of relationships to cover all further concerns that can not directly be conceptualised as arrangement or processing. A shift in the setup of the Job-Functor arguments necessitates to introduce a `Parameter` type — ''albeit just as placeholder'' 2026-07-01 01:50:26 +02:00			`TESTING "Library Test Suite: parameters" ./test-suite --group=param`



Parameters: simple testcase PASS (see #1431) Add value access implementation of the Provision interface by direct cast and access to the embedded value in `ParamData<VAL>`; obviously this is an indirect dispatch, based on the actual type `VAL` The test demonstrates the basic machinery built thus far - have an embedded container with inline storage - dispatch using type information encoded into the VTable 2026-09-02 01:48:51 +02:00			`TEST "Parameter Values" Parameter_test <<END`
Parameters: start a design draft Parameters and Automation will certainly play a crucial role eventually. They will form a network of relationships to cover all further concerns that can not directly be conceptualised as arrangement or processing. A shift in the setup of the Job-Functor arguments necessitates to introduce a `Parameter` type — ''albeit just as placeholder'' 2026-07-01 01:50:26 +02:00			`return: 0`
			`END`
Parameters: preliminary requirement analysis In the current stage, a design-draft is required that is sufficiently adequate to be used as code placeholder and to evolve into the full specification eventually. - we need a single parameter container type with value semantics - parameters must support a selection of basic value types, with conversions - the value range can be limited, and a parameter can be associated with a ''Scale'' (stepped, continuous, logarithmic) - a parameter can be linked to a functional source - parameters are (virtually) copyable 2026-07-03 19:55:55 +02:00

Parameters: look for a suitable arrangement of interfaces While the role of all the relevant interfaces has been determined, it still remains difficult to establish a sensible relationship. Which one is the most fundamental interface? After a lot of mulling, it seems that the `Provision` interface should be used as foundation, since it describes the very core of the parameter concept developed here -- even while the actual form of the operations must be ''somewhat cunningly reversed'', so that the knowledge regarding the underlying type can be kept an opaque implementation detail. The `Domain` interface would then be layered on top, and describes the capability to transfer values between buffers marked with different domains (which effectively requires a double-dispatch in the general case). 2026-08-31 23:17:32 +02:00			`TEST "Parameter Domain Type" ParameterDomain_test << END`
			`return: 0`
			`END`


			`PLANNED "Parameter Provision" ParameterProvision_test << END`
Parameters: preliminary requirement analysis In the current stage, a design-draft is required that is sufficiently adequate to be used as code placeholder and to evolve into the full specification eventually. - we need a single parameter container type with value semantics - parameters must support a selection of basic value types, with conversions - the value range can be limited, and a parameter can be associated with a ''Scale'' (stepped, continuous, logarithmic) - a parameter can be linked to a functional source - parameters are (virtually) copyable 2026-07-03 19:55:55 +02:00			`return: 0`
			`END`
Parameters: mapping out the next steps to draft ...I do ''not intend to go into a parameter deep-dive'' yet, but I want to set out the basic capabilities to be expected... 2026-09-05 18:08:51 +02:00

Parameters: resolve type precision problems with scale-joinig The selection of the intermediary working type, used for exponential and logarithmic functions when combining values from different scales, was implemented too simplistic. Following the example of the `NumberJoinType`, it seems preferrable to spell out the decision logic explicitly. This allows to pick `long doubl` as working type especially in cases where 64bit integral parameters are involved, either as source or destination. With these final tweaks, the `verify_valueJoining()` test is not complete, presumably with path coverage of the conversion functions. The Scale descriptor and operational logic is now defined to the point that it can be integrated into the general Parameter implementation machinery. 2026-09-22 18:39:09 +02:00			`TEST "Parameter value scales" ParameterScale_test << END`
Parameters: mapping out the next steps to draft ...I do ''not intend to go into a parameter deep-dive'' yet, but I want to set out the basic capabilities to be expected... 2026-09-05 18:08:51 +02:00			`return: 0`
			`END`
Parameters: consider what to conceptualise as a Scale It is clear by now that a `Scale` will act as a refinement of a full-domain value type. However, in order to develop the definition and builder notation for parameters, a much more detailed understanding of scales is necessary -- including the question where to draw a line between the complex structured `ParamSet` and a simple `Parameter` that is conceived to be number-value-like. 2026-09-08 23:53:44 +02:00

			`PLANNED "Enumeration domains" NomSet_test << END`
			`return: 0`
			`END`