On 02/07/2007 12:26 PM, Ron Jensen wrote:

> How would the step function know to round to the proper number of
> decimal places?  In the 2D instruments a printf-style statement is used,
> i.e. <format>%02.2f</format>.  However, we're not exactly printing in
> <textranslate>.
> 
> I thought about a "<significant-digits>" tag where we could tell <step>
> how to round.  So we could say:
>   <significant-digits>2</significant-digits>
> instead of:
>   <bias>0.005</bias>
> But the code for <significant-digits>2</significant-digits> would end up
> just adding 0.005 to the property anyway, and having the finer grain
> control in <bias> may prove useful in as-yet unthought of ways.

1) I repeat that <bias> is a reasonable thing.  I'm not arguing
  against it, not at all.

2) The correct behavior for instrument readouts is a _two step_
  process, as follows:

   2a) Round (not truncate, round) to the nearest exact channel.
    For example, assuming 25 kHz channel spacing, 120.374999 MHz
    rounds to 120.375, which is the *exact* center frequency of
    the channel.  [See note.]

    The following code works fine for this, without the need
    for biasing anything, since printf is documented to round,
    not truncate:
       chan  = sprintf("%7.3f", 120.37499);

    There are of course other perfectly fine ways of accomplishing
    the same goal, including dividing by the channel-spacing and
    then rounding to the nearest integer.

   2b) On some (not all) instruments, it may be desirable to
    truncate (not round, truncate) this to two decimal places.
    In our example, 120.375 may get truncated to 120.37, which is
    not an exact frequency, but a truncated shorthand expression.

    The following code works fine for this:
       chan  = sprintf("%7.3f", 120.37499);
       chanx = substr(chan, 0, 6);

    It must be emphasized that some instruments display the
    frequency out to the last kHz, i.e. 120.375 in our example.

3) It is tempting to search for schemes to collapse the two-step
  process into a one-step process, but all such schemes I've seen
  are ugly, risky, or both.

  In the existing flightgear instruments, one can find schemes
  involving fudge factors that are /nearly/ but not quite equal
  to unity, and offsets that are /nearly/ but not quite equal to
  zero.

  Schemes of that ilk are always less robust than simply saying
  what you mean, and meaning what you say.  If you mean to round
  off, round off (as in item 2a) ... and if you mean to truncate,
  truncate (as in item 2b).


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

Note:  In a previous msg it was suggested, presumably in jest, that
"digital readouts are always +/- the last digit."

In case anyone missed the point, this jest calls attention to a profound
absurdity.  A frequency specified as 121.5 does *not* mean 121.5 ± 0.1
or anything like that.  Similarly, if you read that there are 2.54
centimeters to the inch, that does *not* mean 2.54 ± 0.01 or anything
like that.  In fact there are exactly 2.54 centimeters to the inch,
i.e. 2.54 ± 0.

It is a widespread misconception that any number quoted to N
decimal places has been rounded off, and that the roundoff error
is the dominant contribution to the uncertainty.  Actually that's
two misconceptions in one.  You may have been /required/ to
learn these misconceptions in school, but they remain absurd
as the previous examples illustrate. For details on all of this,
see
   http://www.av8n.com/physics/uncertainty.htm


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to