Subjunctive Purpose vs Result Clause Checker
Audit independently established evidence for Subjunctive Purpose vs Result Clause Checker. Feature columns, independently annotated in order: purpose relation independently established, result relation independently established. Unknown evidence and compatible classes retained; not automated semantic, historical, identity, legal or safety determination.
Description
Purpose and result clauses describe different semantic relationships.
Purpose and result clauses describe different semantic relationships.1
This checker compares independently annotated features rather than reading a Latin sentence to infer its meaning. Use Subjunctive Purpose vs Result Clause Checker to compare independently annotated features with the fixed rules.
When to use Subjunctive Purpose vs Result Clause Checker
Use Subjunctive Purpose vs Result Clause Checker to compare independently annotated features with the fixed rules. Annotate the ordered features below independently; use separate binary arrays for observed presence and whether each feature is known.
How to use Subjunctive Purpose vs Result Clause Checker and understand its results
- Annotate the ordered features below independently; use separate binary arrays for observed presence and whether each feature is known.
- Enter Observed feature flags, Feature known flags using the field table and validation rules below, then run the tool.
- Read Compatible Classes, Witnessed Classes, Unknown Feature Indices in the Result object; interpret the units, signs, ordering and unknown-value placeholders described below.
- Correct reported input errors and rerun. Apply successful results according to their specific meanings and check the assumptions before using them in a decision.
| Input field | Meaning | Value type | Requirement |
|---|---|---|---|
| observedFeatureFlags | Observed feature flags | array of number | Required; constraints below |
| featureKnownFlags | Feature known flags | array of number | Required; constraints below |
Enter aligned binary observed-feature and known-feature arrays in the exact column order below. The array length must match the fixed rule width. In the rule table, 1 requires presence, 0 requires absence and −1 ignores that column. A known observation contradicting a required value excludes a class; an unknown observation leaves it compatible. A witnessed class requires all nonignored columns to be known and equal to their required values. Unknown-feature indices are zero based and lists preserve rule order. The tool does not annotate grammar, interpret a text or independently verify the historical evidence.
compatible = no known rule contradiction; witnessed = every nonignored rule known and matched Use the field order, units and branch conditions described above.
| Zero-based feature index | Independently annotated feature |
|---|---|
| 0 | purpose relation independently established |
| 1 | result relation independently established |
| Fixed class | Feature 0 | Feature 1 |
|---|---|---|
| purpose-candidate | 1 | 0 |
| result-candidate | 0 | 1 |
| Output field | Meaning | Value type |
|---|---|---|
| result | Object containing the named result fields below. | object |
| result.compatibleClasses | Fixed-rule classes with no known contradiction; compatibility can depend on unknown features. | array |
| result.witnessedClasses | Fixed-rule classes whose nonignored requirements are all known and matched. | array |
| result.unknownFeatureIndices | Zero-based indices marked unknown, irrespective of their observed-value placeholders. | array |
{
"input": {
"observedFeatureFlags": [
1,
1
],
"featureKnownFlags": [
1,
1
]
},
"output": {
"result": {
"compatibleClasses": [],
"witnessedClasses": [],
"unknownFeatureIndices": []
}
}
}Limitations and assumptions
This checker compares independently annotated features rather than reading a Latin sentence to infer its meaning. Apply the exact scope and assumptions explained above.
All listed fields require explicit values. Unexpected fields, incorrect types, nonfinite numbers and sparse arrays fail validation. Domain-specific bounds, alignments and supported tokens are explained above; extremely large inputs or outputs can also be rejected. Input errors differ from successful false results, empty match lists and unknown-evidence placeholders.
Alternative or Complementary methods
Use Greek Article Paradigm Agreement Checker for a related task: Article-noun agreement compares grammatical case, number and gender.
Use Gerundive Obligation Passive Periphrastic Checker for a related task: A passive periphrastic can express obligation through a gerundive construction.
References
Similar or alternative tools
- Greek Article Paradigm Agreement Checker
Article-noun agreement compares grammatical case, number and gender.
- Gerundive Obligation Passive Periphrastic Checker
A passive periphrastic can express obligation through a gerundive construction.