So now I'm considering the following, and would appreciate any
feedback from the community:
Instead of a single 'discrete' attribute, provide for three:
'nearest' which performs as Geoff described above (not how my diagram
is drawn)
'floor' which holds the previous dependent value until the next
breakpoint is reached (which matches my diagram above)
'ceiling' which rounds up the next dependent value upon passing each
breakpoint.
This seems to be the most flexible, but perhaps also the most complex
and may not be worth the effort.
From my perspective, first of all it's a matter of ambiguosness
of the modelling language. The really important thing is to agree
on the way the function is calculated.
A minimal solution is to allow just one attribute. If the way the
table is interpreted is clear for all users, the language is safe.
For instance, if the modeller first intention was to use a "nearest",
but the language features the "floor", then the modeller has to
arrange a little the table. The important thing is the modeller
being aware that the language offers "floor".
A little more work, but not an actual obstacle.
The proposed solution of three attributes is more friendly.
It costs a bit more because a fully compliant implementation of the
language must offers the three ways of discrete interpretation of
the table, but actually it doesn't seems a big costs - quadraticSpline
and cubicSpline options are more demanding for the implementor :)
Ciao,
Giovanni Cignoni.
