Hi Everybody,
Just to clarify, I wrote the textranslate and texrotate animations (they are animations) while doing the displays for the 747. They are for sliding and rotating texture mappings on an 3D object, and have nothing per se to do with digits. The first problem I was trying to solve was sliding the ASI and Altitude tapes on the PFD. Then it was the rose animation. The problem of producing the alpha and digital displays (it was never about "numbers") had been dogging me, and in the end I never got around to really solving the issue. It just so happend that I was able to use the texture translation for placing numeric values by creating a texture that had a bunch of digits and sliding it around. By adding the step parameter I was able to make it either scroll smoothly like the altitude value or just snap the digit in place as on most digital displays. IIRC the IAS display also has a sort of odometer "drum" behavior even though it is a flat electronic display. Note that the animations were also used for displaying some alphanumeric NAV data. Essentially, I'm saying that Andy was right. Also, there really was no intention to handle fractional numeric values or digits for that matter. It just happened that other modelers picked up on the technique, as there was no other method available, and it went quite a bit farther than was ever intended. In that context, the addition of the bias tag doesn't really make a whole lot of sense, but if it helps someone out, that's fine. These functions are a useful way to do all kinds of things with sliding and rotating textures, but they are a very cumbersome way of doing alphanumeric data displays. Best, Jim > -----Original Message----- > From: Ron Jensen <[EMAIL PROTECTED]> > Sent: Friday, 9. Feb 2007 21:34 -0500 > To: FlightGear developers discussions <flightgear-devel@lists.sourceforge.net> > Subject: Re: [Flightgear-devel] Textranslate Step and Scroll > > On Fri, 2007-02-09 at 14:00 -0500, John Denker wrote: > > > I come to slightly different conclusions. The main point of > > difference is that I think it would be better to change the > > code to establish a reasonable default <scroll> value, rather > > than rampaging through all the existing instruments to add > > <scroll> statements. > > > > Here's my reasoning, followed by my more-detailed conclusions: > > > > 1) First of all, the whole apply_mod() concept is delightful if > > we are trying to implement an analog "drum" type of readout, such > > as used on tach-hour meters, Hobbs-hour meters, and automobile > > odometers in the pre-electronic age. > > Agree. > > > 2) In contrast, the apply_mod() concept is conspicuously unhelpful > > for digital readouts. > > > > 2a) For one thing, for an N-digit readout, it requires the user to > > write nearly the same code N times in the .xml file. This is > > laborious and error-prone at coding time, and inefficient at > > runtime. > > Agree. > > > I doubt apply_mod() was ever intended for digital readouts. > > I suspect it was just pressed into service without much thought. > > Most particularly, I suspect it was never intended to be used > > with a zero <scroll> value. > > > > The <scroll> value is the answer to a question that should never > > get asked in the context of a digital display. > > > > Treating the kx165 display as an "animation" problem is absurd. > > You can "animate" a mechanical drum display. You don't "animate" > > the digits in a digital display. > > Agree. > > > 2b) Secondly, it would be very hard to make the apply_mod() code > > numerically stable, except for integers as noted below. > > > > The fundamental problem is that it makes decisions on individual > > digits in isolation. Rounding decisions concerning the Nth digit > > are made in ignorance of decisions concerning lower-order digits. > > This is a deep-seated problem in the design. > > This is the point of my introduction of a bias, or pre-apply_mod offset. > If offset and factor were applied before apply_mod this function would > be more user-friendly. It allows the designer to make the rounding > decision. It may not be in the familiar format of %0.2f but > <bias>0.005</bias>, but it acomplishes the same thing. > > > 3) The apply_mod() code works fine for integers. One way to make > > the currently-broken instruments work correctly would be to rewrite > > them to use integer kHz rather than fractional MHz. > > > > Note that 0.1 cannot be represented exactly in IEEE floating point. > > You are stuck with this fact; there is nothing you can do about > > it. According to my desk calculator, > > 1 - .1 - .1 - .1 - .1 - .1 - .1 - .1 - .1 - .1 - .1 = 1.38778e-16 > > > > In contrast, reasonable-sized integers can be represented exactly. > > > > 4) Converting a number to a decimal numeral is a "Comp Sci 101" > > homework problem. The solution in apply_mod() is emphatically not > > the textbook solution. > > I was going to lecture you on the issues with IEEE floating point > representation, but decided we both probably had some understanding of > the subject. > > > 5) I see no reason why folks designing digital instruments should be > > required to provide a <scroll> value or a <bias> value at all. Such > > a requirement just creates usability problems for everybody forever > > and ever. > > > > Although it is possible to choose a <bias> value that solves the > > problem, this requires users to understand more about the problem > > than they should be required to understand. > > > > Documenting the proper usage of the <bias> parameter would not be > > pleasant. Sure, for any /particular/ case it is possible to find > > a <bias> that works, but it really doesn't capture the semantics > > of the overwhelming majority of cases. In most cases, the relevant > > meaning is more a notion of <precision>, such that the property > > will be rounded to the nearest multiple of the quantum of <precision> > > before further processing. > > > > The existing <scroll> parameter approximately (not exactly) captures > > the idea of precision. Therefore one wonders whether implementing > > and documenting new parameters would be worth the trouble. > > > > > > 6) It was not the goal of the new apply_mod() code to reproduce > > the same range of outputs as the old code. The goal was to > > unbreak the currently-broken instruments, without very much > > per-instrument fiddling. > > > > OTOH if you are curious to see how the two pieces of code "line > > up", try passing in -1 as the <scroll> value. > > Original algorithm: > 109.8990000000000009=109.8000000000000114 (delta=0.0989999999999895) with > step=0.1000, scroll=-1.0000, bias=0.0000 > 29.9899999999999984=29.9000000000000021 (delta=0.0899999999999963) with > step=0.1000, scroll=-1.0000, bias=0.0000 > > > Your algorithm: > 109.8990000000000009=109.8000000000000114 (delta=0.0989999999999895) with > step=0.1000, scroll=-1.0000, bias=0.0000 > 29.9899999999999984=29.9000000000000021 (delta=0.0899999999999963) with > step=0.1000, scroll=-1.0000, bias=0.0000 > > > > > 7) In addition to the horrific roundoff-related bugs, there are > > more subtle bugs in the instruments that need to be dealt with > > at some point. In particular, in a real KX165, if you start > > with a frequency of 122.975 and add 25 kHz with the small knob, > > you get 122.000, not 123.000; that is, the small digits do > > not "carry" into the big digits. (This is presumably a legacy > > from the ancient mechanical tuning mechanisms.) > > > > Tangential remark: Yet another issue that needs to be addressed > > is the case where a user types in something like 122.97 into > > the radio-setting dialog box. This needs to be channelized to > > 122.975 before further processing. > > Noted. > > > ================= > > > > All in all, it seems to me that the reasonable options are: > > > > A) It would be nice to have some sort of sprintf facility, that > > would calculate N digits and put them on the display in one > > fell swoop. This would make the typical case much simpler and > > more convenient (compared to the current scheme that requires > > rewriting the same code for each digit). It would also be > > more numerically stable, allowing mutually-consistent roundoff > > decisions to be made for all digits. > > Yes, that would be nice. That is how 2d instruments work. > > > B) It should go without saying that we should keep apply_mod() > > around to handle the case of mechanical drum readouts. > > > > C) If people are desperate to preserve the existing <step> > > approach to encoding digits, rather than introducing a <bias> > > to solve the roundoff problem, the other options are: > > > > C1) It would make sense to recode everything to use integer > > kHz rather than fractional MHz. This would be no extra work, > > assuming we do it at the same time we address item (7) in the > > list above. This might require some extra code somewhere to > > convert kHz back to MHz, to interface with other code that is > > expecting frequencies in MHz ... but that would only need to > > be done in one place, not done N times for a N-digit readout. > > I was trying to avoid this, but it may prove neccessary in some cases. > > > C2) The <bias> idea is not the worst idea I've ever seen, but > > I see no evidence that it is necessary. AFAICT, all the > > existing broken instruments can be unbroken by choosing a > > suitable nonzero <scroll> value. > > Probably true, but I am trying to avoid hard-coding a value. > > > D) It is important to have reasonable defaults. A zero scroll > > value is not a reasonable default. If you don't like my expedient > > of setting the default scroll value to a millionth of the <step> > > size, another option would be to set it to 1e-6 in absolute units, > > in whatever units the <property> is being measured in. Either of > > these options suffices to unbreak the currently-existing broken > > instruments. > > > > In the future, anybody who comes up with an exceptional instrument > > for which the default doesn't work is free to pass in a non-default > > <scroll> value. > > Except in your algorithm '0' can never be used as a scroll value. > > Ron > > > > ------------------------------------------------------------------------- > 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 > -- Jim Wilson Kelco Industries PO Box 160 Milbridge, ME 04658 207-546-7989 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
