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 :)

Giovanni Cignoni.

Reply via email to