feldob / input Goto Github PK

When a parameter is defined relative to another parameter, next will not generate correct values for the dependent parameter. Expressions are evaluated as though all references are resolved to 0.

See referencesResolveToZero in
https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/AdvancedSingleRangeNextTest.java for details.

There is no way to make sense of a multi-range definition that has differing numbers of min and max limits. InPUT4j should check for this and throw an explicit exception (or take some other appropriate and decisive action).

Right now, missing min limits immediately cause an ArrayIndexOutOfBoundsException. While the error message isn't helpful, at least InPUT4j refuses to use the configuration and fails early. However, missing max limits fail late and completely at random. It is possible to use the configuration, but an (unhelpful) ArrayIndexOutOfBoundsException may or may not be thrown based on chance.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/MultiRangeMismatchTest.java for details.

A setter can be used both during initialization and when subsequently setting a new value. However, setters only work if the corresponding inner parameter was not initialized by the constructor. Setters cannot be used together with constructor initialization.

See customAccessorsDoNotWorkWhenUsingConstructorArg in https://github.com/finkn/InPUT/blob/master/Java/src/DocTest/src/se/miun/itm/input/model/design/CustomAccessorTest.java

When defining a multi-range using expressions, only the last range is used.

See multiRangesWithExpressionsOnlyUseLastRange in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/AdvancedMultiRangeNextTest.java defails.

The value of an inner parameter is kept in sync with the corresponding object field if and only if it was not initialized using the constructor.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/ValueConsistencyTest.java for details.

If a parameter is defined using expressions in such a way that the range is empty, the result is that min and max are swapped. This also interacts in surprising ways with exclusive limits. They end up extending the range rather than restricting it.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/AdvancedSingleRangeNextTest.java. Particularly limitsAreSwappedForEmptyInclusiveRange and emptyExclusiveRangeIsExtendedWhenSwapped.

Getters are never invoked.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/AccessorTest.java for details

Undesired behavior in InPUT4j IDesign.getValue:

Design design1, design2;
Design design1 = new Design("testDesign.xml");
Design design2 = design1.clone("clone");

// before reading value X= 8.0
design1.getValue("EA.EliteCount");
// after reading value X= 8

As a consequence, the two designs are not "same" anymore:
design1.same(design2) -> false

When defining multiple exclusive ranges, only the first range is used; the rest are ignored.

See multiExclExcl in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/SimpleMultiRangeNextTest.java for details.

When a multi-range is defined using inclusive limits, only values in the intersection of all the ranges are legal.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/RangeTest.java for details.

It is no surprise that equal absolute IDs can collide. Relative IDs in the same scope also have the same absolute IDs. So that's merely another interpretation of the same situation. However, relative IDs in different scopes can also collide. All collisions are silently ignored, but the effects can be quite serious.

These collisions explain the scoping problems that were observed in the past. Rather than outer parameters overshadowing inner parameters, the IDs are considered to be duplicates, even though the parameters have different absolute IDs, and the order in which the parameters occur in the configuration means that one parameter overrides the other.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/DuplicateIdTest.java for details.

Reminder to self:
A IoC constructor call in InPUT crashes the program, if a design contains entries such as:
<NParam id="unknown" value="anything"/>
that are unknown to the design space.

When element IDs collide, depending on the order in which the parameters occur in the configuration, elements may have an ID that is relative to a different parent ID.

For example, the first element of the array "A.1" can be assigned an ID of "A.A.1.1".

See duplicateElementsAddNewIds in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/DuplicateIdTest.java for details.

When inner parameters depend on each other such that a child of X depends on a child of Y, which has a child that depends on a child of X, but there is no cycle in the dependency graph, then parameters are not initialized properly.

Assume two structured parameters, X and Y. Each has two nested numeric parameters X.A, X.B and Y.C, Y.D. The following dependency graph has no cycles:
X.B -> Y.C -> X.A

If (X.A depends on Y.C) ⇒ (X depends on Y), then this should simply be a circular dependency that should trigger an exception. Otherwise there is no circularity, and parameters should be initialized as expected.

See chainedDependenciesAreInvalid in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/NestedDependencyTest.java for details.

Just like DesignSpace.next(), Design.setValue() ignores all ranges in a multi-range with exclusive limits, except the first range. So only values from the first range are legal.

Mixed inclusive/exclusive (multi-range) limits also cause setValue to throw an ArrayIndexOutOfBoundsException.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/SetValueTest.java for details.

For integer parameters, the maximum legal value is never generated, except when that is the only value.

See https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/SimpleSingleRangeNextTest.java for details.
singleInclIncl is one of the tests that show a missing value, while singleInclInclWithSingleValue demonstrates the exception for singleton ranges.

Received question:

"I just have a short question. When I have a parameter X, and I have a
structured parameter Point that has an inner parameter X ("Point.X"),
then constructor="X" will use the outer rather than the inner X, and the
initialization will not be consistent. Is this kind of scoping intentional?"

This is not intentional, scoping should be inside out.

When defining a floating point parameter with exclusive limits, those limits aren't actually excluded. DesignSpace.next() will generate them (when float, but not double), and Design.setValue() will accept them (whether float or double).

See exclusiveFloatIsInclusive in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/SimpleSingleRangeNextTest.java and https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/RangeTest.java for details.

The SChoiceType parameters are not exported, which can lead to failures in mappings. For instance, a type "P" is inherited in a design space by parameter "B.P". The code mapping is bound to "P", not to "B.P"; the rest InPUT takes care of. Now, if SChoiceType is not exported, the "P" mapping is unbound, and so are all parameters "B.P".

Defining multiple ranges with mixed inclusive/exclusive limits, next() throws an ArrayIndexOutOfBoundsException.

See multiInclExcl and multiExclIncl in https://github.com/finkn/InPUTspec/blob/master/main/src/net/finkn/inputspec/v050/SimpleMultiRangeNextTest.java for details.