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.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to