Re: [Flightgear-devel] Textranslate Step and Scroll

[John D. <js...@av...>]

On 08/17/2008 08:13 AM, Timothy Moore wrote:
> ....  the stepping 
> code has been moved to an SGStepExpression in 
> simgear/structure/SGExpression.hxx, but it should be easy to apply the same 
> change there.

Easy indeed.  Cut and paste.  See patches below.

But before we discuss the code in detail, let's be clear about what
problems we're trying to solve.  There are really two problems.

Here are some test cases, output from the test-driver program at
  http://www.av8n.com/fly/fgfs/step_scroll.c

    ===== Start of case 1:        12345.9910000            0.0000000            0.0000100
    Old case 1:   12345.9921000 BAD
    My  case 1:   12345.9910000 OK
    ===== Start of case 2:        12345.9910000            0.0000000           -1.0000000
    Old case 2:   12345.9910000 OK
    My  case 2:   12345.9910000 OK
    ===== Start of case 3:        12345.9910000            0.0000000            0.0000000
    Old case 3:   12345.9910000 OK
    My  case 3:   12345.9910000 OK
    ===== Start of case 4:        12345.3000000            0.0000000            0.0000100
    Old case 4:   12345.3100000 BAD
    My  case 4:   12345.3000000 OK
    ===== Start of case 5:        12345.3000000            0.0000000           -1.0000000
    Old case 5:   12345.2099000 BAD
    My  case 5:   12345.2099000 BAD
    ===== Start of case 6:        12345.3000000            0.0000000            0.0000000
    Old case 6:   12345.2099000 BAD
    My  case 6:   12345.3000000 OK

Preliminary discussion:

Old case 1 demonstrates the first problem:  /even if/ a positive <scroll> parameter is
specified, there are encoder glitches.  This is due to an easily-removable numerical
instability.  See patch #1.

My case 1 demonstrates that the new code makes this type of glitch go away.  Case 4
is another pattern that exhibits the same problem and the same solution.

Case 5 demonstrates the second problem:  with the old code or the new code, if you
do /not/ specify a positive <scroll> parameter, bad things are going to happen sometimes.
By way of contrast, case 2 demonstrates that the problem is pattern-sensitive;  sometimes
you can get away with no <scroll> even though it's not safe in general.

Case 6 demonstrates that the new code with the new default <scroll> behavior does
the right thing, and is sometimes helpful.  In contrast, case 3 shows that the
problem is pattern sensitive.

Further discussion:

1) The textranslate code was originally intended for use in drum or tape instruments
 connected to analog quantities such as altitude and airspeed ... and is commonly
 used for exactly that.

2a) There is no way that a <bias>  can get rid of encoder glitches in the context of
 analog quantities.  All it does is play whack-a-mole;  it just shifts the problem
 from one property value to another.

2b) OTOH for things like radio frequencies that have only a smallish number of discrete
 possibilities, it should be possible to find a <bias> value that conceals the numerical
 instability.  The downside is that this places an unnecessary burden on the community
 to come up with suitable <bias> statements, to document them, to maintain them, et cetera.

3a) Item (2a) seems like more than sufficient reason to fix the problem.

3b) Once the problem is fixed, there is no longer any upside to using <bias> to conceal
 these numerical instabilities.

4a) The code was probably never intended to operate without a positive <scroll> value.
 If we were meanies, we could make this an error condition, but since we are nice guys
 we provide a sensible default.  See patch #2, which is one-liner.

4b) If you happen to want bug-for-bug compatibility with the old no-<scroll> behavior,
 you can provide an explicit <scroll> value of -1, which will override the default and
 defeat all <scroll> processing.  This is primarily for testing, to demonstrate the
 value of the new code;  I cannot imagine any other purpose for this feature.

5) Using textranslate to implement the frequency digits on a digital radio is still a
 kludge.  The xml required to do this is long-winded, to say the least.  The patches
 presented here do not remove the pressure for a nicer api.  Some sort of sprintf and
 substr "expressions" seem like the obvious way to go.

===================

Patch #1:  Remove some of the numerical instability in textranslate step and scroll:
  http://www.av8n.com/fly/fgfs/step_scroll_1.diff

Patch #2:  Remove yet more numerical instability, by providing a default <scroll> value:
  http://www.av8n.com/fly/fgfs/step_scroll_2.diff

These patches are relative to the latest and greatest source from Pigeon's git
archive, current as of a few minutes ago.