On Jun 19, 2007, at 5:33 PM, Brian, Geoff wrote:

From: Bruce Jackson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 19 June 2007 3:40 AM
To: Giovanni A. Cignoni
Cc: simstds@larc.nasa.gov
Subject: Re: Discrete interpolation attribute (was New version of
DAVEfunc DTD 1.9b3)

On Jun 18, 2007, at 1:28 PM, Giovanni A. Cignoni wrote:

The main change to the DTD is addition of 'discrete' as a supported
interpolation method for tabular data, yielding a stair- step
response  from such a function. This came from a suggestion from
Geoff Brian of  Australia's DSTO.

"Discrete" interpolation is the method also known as "nearest
Being x in [a, b], f(x) is f(a) or f(b) depending on x being nearer to

a or b. Correct?

Thanks in advance, ciao,
Giovanni Cignoni.

This is a good question, Giovanni. I see that we need to be much more
rigorous in our definition of 'discrete' as it applies to these tables.

I had assumed the interpretation would be as follows (I don't think this
is 'nearest-neighbor')...

In the case of a one-dimensional function, if the independentVarPts are
defined as

      [a, b, c, d]

and an arbitrary griddedTable points are defined as

      [8.5, 9.0, 9.5, 10.0]

the function f(x) would be evaluated as shown below:

f(x)   ^
10.0 - |                        o
        |                        |
        |                        |
  9.5 - |                 o------o
        |                 |
        |                 |
  9.0 - |          o------o
        |          |
        |          |
  8.5 - |   o------o
        |----------------------------------> X
            |      |      |      |
            a      b      c      d

so the independent values state where the function changes value.

Nearest-neighbor would put the transitions exactly between the
independent break points.

I'd appreciate any feedback on this topic, especially from Geoff Brian
who is apparently making use of this 'extension' to DAVE-ML.

-- Bruce

I also agree that this is a good question. There are times when
interrogating data where it is necessary to return either a truncated
value, as you describe Bruce, or the nearest neighbour. Thus a single
'discrete' attribute may not have been the best suggestion. This is
something we had overlooked in suggesting such an attribute. At the risk
of fattening the dtd with unnecessary options, having attributes for
both these cases would be useful.

At present, the data tables I am currently using the 'discrete'
attribute for are more akin to nearest-neighbour.


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.

What say the combined intelligence of artisans?

-- Bruce

Reply via email to