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
