Closed digitalbricklayer closed 9 years ago
One proposal is to use something like the representation used in books, specifically in 'Constraint Satisfaction Problems' by Khaled Ghedira.
So a variable would be represented as <X>
, a domain by {1..10}
and a constraint (not sure about this one, not mentioned in the book) [X > 1]
.
Has the benefit that a syntax is available for values <X,1>
, for aggregate variables <X1,X2..X10>
where the number is presented as sub-script and aggregate values <X1,1>,<X2,2>..<X10,10>
.
This is a sketch of how things could look:
The directional connections are a major problem. I can never remember which way they are supposed to go, so I can't really expect anybody else to remember. Being able to connect either way would be a big improvement.
It may be that no connections are required. Constraints need to reference the variable(s) by name. That may well be sufficient. Same with shared domains. The variable can reference the shared domain by name.
The only major problem I can see is that the model may well look a lot like a programming language, which is very specifically something I don't want.
Having said that, a spreadsheet does not have connections between cells, it just has cell references by name. The spreadsheet then provides tools to make it easier to get those cell references through tools like cell selection and the auto sum feature. Perhaps something similar would be appropriate with dyna. The model would be built using variable and domain names, but tools would be provided to make acquiring the names easier.
Change the model representation to something that works better than the v0.1 representation. Ideally needs to support the extension to support aggregates.