Re: [Flightgear-devel] Textranslate Step and Scroll
On 08/16/2008 03:32 PM, Tim Moore wrote: Sport Model was last updated to CVS FlightGear over a year ago. Do you have any plans to update it to current CVS? On 08/16/2008 06:13 PM, I replied: I could be persuaded. Do you think it would be helpful? On 08/17/2008 08:28 AM, Tim Moore wrote: Yes, I do think it would be helpful to get your fixes and development merged in. It would be especially great to base your merges from CVS on the git mirrors at pigeond.net, as several of us use that. As of 08/18/2008 04:45 PM, I had done exactly what I was asked to do. These patches are relative to the latest and greatest source from Pigeon's git archive, current as of a few minutes ago. Was it in fact helpful? - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
John Denker wrote: On 08/16/2008 03:32 PM, Tim Moore wrote: Sport Model was last updated to CVS FlightGear over a year ago. Do you have any plans to update it to current CVS? On 08/16/2008 06:13 PM, I replied: I could be persuaded. Do you think it would be helpful? On 08/17/2008 08:28 AM, Tim Moore wrote: Yes, I do think it would be helpful to get your fixes and development merged in. It would be especially great to base your merges from CVS on the git mirrors at pigeond.net, as several of us use that. As of 08/18/2008 04:45 PM, I had done exactly what I was asked to do. I suppose I wasn't specific enough. I meant that would be helpful for the branches in your Sport Model repository to be rebased onto or merged with Pigeon's official ones. Unless I'm pointing at the wrong repos, I haven't seen any change there. These patches are relative to the latest and greatest source from Pigeon's git archive, current as of a few minutes ago. Was it in fact helpful? Of course, there's certainly more to talk about when a patch is based on the current code. I'm sorry I haven't joined in (or really processed) the recent discussion of textranslate; I've had my head down in other stuff. Tim - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
John Denker wrote: 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. If I understand this correctly I think FlightGear already provides a way to do that. I've recently attached a 2d-panel text animation to a 3d model to display all sorts of text information in an Data Entry Display (DED). See FlightGear/data/Aircraft/f16/Models/ded-display.xml for more details. If I remember correctly it would be easy to use a different font to render 7 (or more) segment led displays (I believe such a font is already in the base package). The only drawback is that one needs to define a background texture (in this case I had to use a transparent texture to remove it) A better approach would be to not use a background polygon when no background texture is defined). Erik - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
Erik Hofman wrote: If I understand this correctly I think FlightGear already provides a way to do that. I've recently attached a 2d-panel text animation to a 3d model to display all sorts of text information in an Data Entry Display (DED). See FlightGear/data/Aircraft/f16/Models/ded-display.xml for more details. If I remember correctly it would be easy to use a different font to render 7 (or more) segment led displays (I believe such a font is already in the base package). I just checked and both the led font and lcd font are already available indeed. Here is an image showing the Data Entry Display in action: http://home.telfort.nl/sp004798/emh/ded.jpg Erik - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On 19 Aug 2008, at 08:15, Erik Hofman wrote: I just checked and both the led font and lcd font are already available indeed. Here is an image showing the Data Entry Display in action: http://home.telfort.nl/sp004798/emh/ded.jpg Side note - this is interesting, I'm still musing on the best way to implement an FMS display, and re-implement the KLN-89 display. Both are quite similar to your DED, but use some extra characters (eg, to implement a CDI), and have some slightly complex layout options. (Ignoring the dreaded KLN-89 MAP mode for now) James - 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=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
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.9910.000 0.100 Old case 1: 12345.9921000 BAD My case 1: 12345.991 OK = Start of case 2:12345.9910.000 -1.000 Old case 2: 12345.991 OK My case 2: 12345.991 OK = Start of case 3:12345.9910.000 0.000 Old case 3: 12345.991 OK My case 3: 12345.991 OK = Start of case 4:12345.3000.000 0.100 Old case 4: 12345.310 BAD My case 4: 12345.300 OK = Start of case 5:12345.3000.000 -1.000 Old case 5: 12345.2099000 BAD My case 5: 12345.2099000 BAD = Start of case 6:12345.3000.000 0.000 Old case 6: 12345.2099000 BAD My case 6: 12345.300 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
Re: [Flightgear-devel] Textranslate Step and Scroll
On 08/17/2008 10:01 AM, Ron Jensen wrote: This particular patch was greatly discussed Yes, it was greatly discussed. and the decision was made not to include it in the main code base. There was no consensus on that point. The bias tag was added as the fix for this problem. There was no consensus that the bias tag made much sense. Here is a good summary of the discussion: On 03/09/2007 01:18 PM, Jim Wilson wrote: 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. I agree with Jim Wilson and Andy Ross that the bias tag doesn't make a whole lot of sense. If you want to use it, go ahead, but don't pretend it fixes the problem ... and don't use it as a pretext for derailing efforts to really fix the problem. The only thing that really makes sense is to implement a set of formatting directives that is actually suitable for digits. *) This will make the code for digit displays much much more compact. Writing the code will be less laborious and less error-prone. *) Then textranslate can be restricted to its intended purpose, namely tapes and drums. *) Beware that real instruments /round/ some things and then /truncate/ other things, so a one-size-fits-all approach will not work, as I pointed out a year and a half ago. The formatting directives will need to include some things that are documented to do rounding (such as sprintf) and some things that are documented to do truncation (such as substr). - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
John Denker wrote: On 08/17/2008 10:01 AM, Ron Jensen wrote: This particular patch was greatly discussed Yes, it was greatly discussed. and the decision was made not to include it in the main code base. There was no consensus on that point. That's my reading of the discussion, but in any event, I didn't mean to imply that this was a patch I would be committing straight away, just that it wouldn't merge with current CVS because the texture animation code has changed to use expressions. Tim The bias tag was added as the fix for this problem. There was no consensus that the bias tag made much sense. Here is a good summary of the discussion: On 03/09/2007 01:18 PM, Jim Wilson wrote: 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. I agree with Jim Wilson and Andy Ross that the bias tag doesn't make a whole lot of sense. If you want to use it, go ahead, but don't pretend it fixes the problem ... and don't use it as a pretext for derailing efforts to really fix the problem. The only thing that really makes sense is to implement a set of formatting directives that is actually suitable for digits. *) This will make the code for digit displays much much more compact. Writing the code will be less laborious and less error-prone. *) Then textranslate can be restricted to its intended purpose, namely tapes and drums. *) Beware that real instruments /round/ some things and then /truncate/ other things, so a one-size-fits-all approach will not work, as I pointed out a year and a half ago. The formatting directives will need to include some things that are documented to do rounding (such as sprintf) and some things that are documented to do truncation (such as substr). - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On Sun, 2008-08-17 at 12:11 -0700, John Denker wrote: On 08/17/2008 10:01 AM, Ron Jensen wrote: and the decision was made not to include it in the main code base. There was no consensus on that point. The fact that the code is not there speaks for itself. The bias tag was added as the fix for this problem. There was no consensus that the bias tag made much sense. Here is a good summary of the discussion: On 03/09/2007 01:18 PM, Jim Wilson wrote: 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. I agree with Jim Wilson and Andy Ross that the bias tag doesn't make a whole lot of sense. If you want to use it, go ahead, but don't pretend it fixes the problem ... and don't use it as a pretext for derailing efforts to really fix the problem. I have never disagreed that we are overloading the textranslate function into an area it wasn't designed for. That is why I implemented a tag as opposed to hard-coding a similar solution which is what is currently done in the _Sport Model_. Jim above gives his approval of it and Andy committed it. Even if they couldn't see a need, we now have functional 3D radio displays using this tag in several aircraft, and textranslate functions that worked with out it continue to work without it. The only thing that really makes sense is to implement a set of formatting directives that is actually suitable for digits. *) This will make the code for digit displays much much more compact. Writing the code will be less laborious and less error-prone. If this code is in the _Sport Model_ I am in favor of pulling it into CVS head. *) Then textranslate can be restricted to its intended purpose, namely tapes and drums. *) Beware that real instruments /round/ some things and then /truncate/ other things, so a one-size-fits-all approach will not work, as I pointed out a year and a half ago. The formatting directives will need to include some things that are documented to do rounding (such as sprintf) and some things that are documented to do truncation (such as substr). Thank you for another lesson in avionics and computer science 101. - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
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 bias0.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
Re: [Flightgear-devel] Textranslate Step and Scroll
On Fri, 2007-03-09 at 15:18 -0500, Jim Wilson wrote: 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 They are very cumbersome for alphanumerics, but they work. In the step animation, offset and factor are applied post-step. The bias act as a pre-step offset. So: (step(Property)+offset)*factor Becomes: (step(Property+bias)+offset)*factor I thought that might be a useful tag to have in the textranslate toolbag as well as solving an immediate problem I had. I also had in mind adding a pre-step factor tag as well, but never did... That reminds me, I need to update models-howto to add the bias tag... Thanks, Ron - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On Thu, 2007-02-08 at 18:55 -0500, John Denker wrote: On 02/07/2007 02:14 PM, Andy Ross wrote: So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a digit extractor animation instead. Good news: The /design/ is not as flawed as it looks. All evidence indicates that the primary problem with the step-and-scroll function was not the design; the primary problem had more to do with the implementation. The code was practically begging to get bit by roundoff errors. John, I stripped the apply_mod() function out into its own small program for analysis. In the first test, input to the program was a simulated property changing from 109.898999 to 109.88. The '8' marches one place to the right each run. Both algorithms were tested with and without bias, the original algorithm was also ran with a scroll value of 1e-6*step. In the second test, property was held constant and step was varied between 0.001 and 100. The test was ran again with a slightly larger property. This test shows the most common usage of the apply_mod function. My conclusions: - With bias set to 0.5 * (smallest expected step) both algorithms return a correctly rounded result. - With scroll set to 1e-6*step the original algorithm returns the same result as your algorithm. - With a very small error in property your algorithm returns a result which is close to desired however the exact result varies with the input error. While your algorithm returns acceptable results in the instant case I can not be certain it will not fail in different cases. - Your algorithm's output can be achieved with the current code, however you algorithm can not always reproduce the current code's output. Therefore I recommend we stay with the current code and add either a bias or scroll value to the xml files of the instruments which require it. V/r Ron **Test One** Original algorithm with bias: 109.89899867=109.9057 (delta=-0.00100190) with step=0.0100, scroll=0., bias=0.0050 109.89989882=109.9057 (delta=-0.00010175) with step=0.0100, scroll=0., bias=0.0050 109.89998883=109.9057 (delta=-0.1174) with step=0.0100, scroll=0., bias=0.0050 109.8840=109.9057 (delta=-0.01000117) with step=0.0100, scroll=0., bias=0.0050 109.89899832=109.9057 (delta=-0.00100225) with step=0.0100, scroll=0., bias=0.0050 109.89989835=109.9057 (delta=-0.00010221) with step=0.0100, scroll=0., bias=0.0050 109.89998878=109.9057 (delta=-0.1178) with step=0.0100, scroll=0., bias=0.0050 109.88999897=109.9057 (delta=-0.01000160) with step=0.0100, scroll=0., bias=0.0050 109.89899870=109.9057 (delta=-0.00100187) with step=0.0100, scroll=0., bias=0.0050 109.89989967=109.9057 (delta=-0.00010090) with step=0.0100, scroll=0., bias=0.0050 109.89998920=109.9057 (delta=-0.1137) with step=0.0100, scroll=0., bias=0.0050 109.8773=109.9057 (delta=-0.0284) with step=0.0100, scroll=0., bias=0.0050 Original algorithm without bias: 109.89899867=109.8906 (delta=0.00899861) with step=0.0100, scroll=0., bias=0. 109.89989882=109.8906 (delta=0.00989876) with step=0.0100, scroll=0., bias=0. 109.89998883=109.8906 (delta=0.00998877) with step=0.0100, scroll=0., bias=0. 109.8840=109.8906 (delta=0.00999834) with step=0.0100, scroll=0., bias=0. 109.89899832=109.8906 (delta=0.00899826) with step=0.0100, scroll=0., bias=0. 109.89989835=109.8906 (delta=0.00989830) with step=0.0100, scroll=0., bias=0. 109.89998878=109.8906 (delta=0.00998873) with step=0.0100, scroll=0., bias=0. 109.88999897=109.8906 (delta=0.009998999891) with step=0.0100, scroll=0., bias=0. 109.89899870=109.8906 (delta=0.00899865) with step=0.0100, scroll=0., bias=0. 109.89989967=109.8906 (delta=0.00989961) with step=0.0100, scroll=0., bias=0. 109.89998920=109.8906 (delta=0.00998914) with step=0.0100, scroll=0., bias=0. 109.8773=109.8906 (delta=0.00999767) with step=0.0100, scroll=0., bias=0. Original algorithm without bias, with scroll=0.0001: 109.89899867=109.8906 (delta=0.00899861) with step=0.0100, scroll=0., bias=0. 109.89989882=109.8906
Re: [Flightgear-devel] Textranslate Step and Scroll
On 02/09/2007 11:08 AM, Ron Jensen wrote: I stripped the apply_mod() function out into its own small program for analysis. The experimental analysis confirms that the code is numerically unstable. I don't think there is any way to make it numerically stable. The instability can be swept under the rug, so that it does not affect cases of interest ... but anybody who takes the trouble to look closely will always be able to find it. My conclusions: - With bias set to 0.5 * (smallest expected step) both algorithms return a correctly rounded result. - With scroll set to 1e-6*step the original algorithm returns the same result as your algorithm. - With a very small error in property your algorithm returns a result which is close to desired however the exact result varies with the input error. While your algorithm returns acceptable results in the instant case I can not be certain it will not fail in different cases. - Your algorithm's output can be achieved with the current code, however you algorithm can not always reproduce the current code's output. Therefore I recommend we stay with the current code and add either a bias or scroll value to the xml files of the instruments which require it. 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. 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. 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. 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. 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. 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. 7) In addition to the horrific roundoff-related bugs,
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 bias0.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.8999=109.8114 (delta=0.09899895) with step=0.1000, scroll=-1., bias=0. 29.9884=29.9021 (delta=0.0863) with step=0.1000, scroll=-1., bias=0. Your algorithm: 109.8999=109.8114 (delta=0.09899895) with step=0.1000, scroll=-1., bias=0. 29.9884=29.9021 (delta=0.0863) with step=0.1000, scroll=-1., bias=0. 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
Re: [Flightgear-devel] Textranslate Step and Scroll
On 02/09/2007 09:34 PM, Ron Jensen wrote: [250 lines of stuff we agree about] Except in your algorithm '0' can never be used as a scroll value. Well, I fixed that just now. New version: http://www.av8n.com/fly/fgfs/animation.diff Anybody who wants to set scroll0/scroll is now free to do exactly that. (There's more I could say about this, but it suffices to say that the new version is an improvement.) In most cases, a small positive scroll value is to be preferred to zero. There are now three ways to obtain that: -- You can specify your own value. -- You can leave the scroll value unset, which triggers default behavior. -- You can set the scroll value to -1, which also triggers default behavior. At the moment, the default is 1e-6 times the step size. This is not set in stone. == To summarize: 1) We should keep apply_mod() around to handle mechanical drum displays 2) We should have a sprintf-like facility for the 3D digital instruments ... something at least as nice as the facility provided to the 2D instruments. 3) There are two separate arguments leading to the conclusion that it would be advantageous for the radios to use an integer kHz representation, not just a fractional MHz representation. 4) It would be kinda nice to make apply_mod() work for fractional digital displays, but in light of points (2) and (3), this is not really a step on the road from here to where we want to be, so it is not worth a whole lot of effort. The main effort should be spent on (2) and (3). - 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On Saturday 10 February 2007 05:06, John Denker wrote: On 02/09/2007 09:34 PM, Ron Jensen wrote: [250 lines of stuff we agree about] :) Me too. I am still working on the osg 2d cockpit stuff to get that fast and reliable. But we have definitely stuff in the 2d panel code that should be factored out into something that could be used for the 2d panel stuff and the animations. Having 'animated text in the 3d models' is something on my todo list ... Greeting Mathias - 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On 02/07/2007 02:14 PM, Andy Ross wrote: So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a digit extractor animation instead. Good news: The /design/ is not as flawed as it looks. All evidence indicates that the primary problem with the step-and-scroll function was not the design; the primary problem had more to do with the implementation. The code was practically begging to get bit by roundoff errors. A patch to fix the code can be found at http://www.av8n.com/fly/fgfs/animation.patch It's a patch to animation.cxx (the latest CVS version thereof) providing a virtually complete rewrite of the apply_mods(...) function therein. Folks will need to -- apply the patch; -- recompile simgear and install the new version. -- re-link fgfs against the new simgear library. (The makefile will probably force a major recompile of flightgear, which really shouldn't be necessary, and can be prevented if you're clever, but that's a topic for another day.) I have done only limited testing, but it appears to successfully unbreak quite a few heretofore broken instruments. For example, the radios in the SenecaII-jsbsim were very broken, but they seem fine now. There are some tricky bits in the code, but I was careful not to add any detestable comments. The goal here is to fix all the step/scroll bugs, without any need to fool with bias or anything like that. Similarly there should be no need for fudge factors that are almost equal to unity to ensure correct formatting of the display. If this goal is not being met, please let me know. - 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textranslate Step and Scroll
While working on 3D cockpit instruments I keep hitting into issues with internal floating point representation and the textranslatestep tag. The step tag effectively truncates the property, 29.9199 becomes 29.91, so a (3D) readout reads off one number. The electronics technician in me says, but digital readouts are always +/- the last digit. But the craftsman in me wants the readout to read correctly. The tag I expected to use to fix this, offset, is applied after the step tag and therefore has no effect. I am proposing an new tag, bias, that will act like offset but be applied before step and scroll Example: animation typetextranslate/type object-namedigit5/object-name propertyautopilot/KAP140/settings/baro-setting-inhg/property factor10/factor step0.01/step bias0.005/bias axis x1/x y0/y z0/z /axis /animation I've hardcoded this into simgear and it works. If no one objects or has a better idea I will try to figure out how to add this tag. Thanks, 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On 02/07/2007 09:47 AM, Ron Jensen wrote: While working on 3D cockpit instruments I keep hitting into issues with internal floating point representation and the textranslatestep tag. The step tag effectively truncates the property, 29.9199 becomes 29.91, so a (3D) readout reads off one number. I am proposing an new tag, bias, that will act like offset but be applied before step and scroll While the bias tag seems reasonable enough, the *first* step should be to repair the step feature so that it performs rounding rather than truncation. This would greatly reduce the number of situations where bias would be required. It seems likely that this change to step would immediately unbreak a goodly number of currently-broken instruments, and unlikely that it would break any currently-working instruments. Leaving step the way it is would create a long-lasting trap for the unwary. Let me put it the other way: If there is any rationale for having step truncate rather than round, would somebody please explain what it is? - 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
On Wed, 2007-02-07 at 11:32 -0500, John Denker wrote: On 02/07/2007 09:47 AM, Ron Jensen wrote: While working on 3D cockpit instruments I keep hitting into issues with internal floating point representation and the textranslatestep tag. The step tag effectively truncates the property, 29.9199 becomes 29.91, so a (3D) readout reads off one number. I am proposing an new tag, bias, that will act like offset but be applied before step and scroll While the bias tag seems reasonable enough, the *first* step should be to repair the step feature so that it performs rounding rather than truncation. This would greatly reduce the number of situations where bias would be required. It seems likely that this change to step would immediately unbreak a goodly number of currently-broken instruments, and unlikely that it would break any currently-working instruments. Leaving step the way it is would create a long-lasting trap for the unwary. Let me put it the other way: If there is any rationale for having step truncate rather than round, would somebody please explain what it is? 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-digits2/significant-digits instead of: bias0.005/bias But the code for significant-digits2/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. 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
John Denker wrote:
Ron Jensen wrote:
The step tag effectively truncates the property, 29.9199
becomes 29.91, so a (3D) readout reads off one number.
I am proposing an new tag, bias, that will act like offset but be
applied before step and scroll
While the bias tag seems reasonable enough, the *first* step
should be to repair the step feature so that it performs
rounding rather than truncation.
This subject came up on the IRC channel (which increasingly seems like
the only contact I have with you guys -- I'm not dead, really!) and
Ron sent me his bias patch for commit.
The patch itself looks sane and easy. But I think I agree with John,
this is a workaround for a design flaw in the step animation that we
should just fix. Can someone (ideally people who, unlike me, know
where to look for lots of step animations) try this completely
untested patch to simgear/scene/model/animation.cxx? It just
rewrites apply_mods() to do rounding (and IMHO to be clearer and
simpler):
--- simgear/scene/model/animation.cxx 2 Feb 2007 07:00:54 - 1.63
+++ simgear/scene/model/animation.cxx 7 Feb 2007 18:18:32 -
@@ -107,27 +107,14 @@
static double
apply_mods(double property, double step, double scroll)
{
-
- double modprop;
- if(step 0) {
-double scrollval = 0.0;
-if(scroll 0) {
- // calculate scroll amount (for odometer like movement)
- double remainder = step - fmod(fabs(property), step);
- if (remainder scroll) {
-scrollval = (scroll - remainder) / scroll * step;
- }
-}
- // apply stepping of input value
- if(property 0)
- modprop = ((floor(property/step) * step) + scrollval);
- else
- modprop = ((ceil(property/step) * step) + scrollval);
- } else {
- modprop = property;
- }
- return modprop;
-
+if(step == 0)
+return property;
+double bias = (property 0) ? 0.5 : -0.5;
+double result = step * (int)(bias + (property / step));
+double diff = result - property;
+if(fabs(diff) scroll)
+result = property + step * (diff / scroll);
+return result;
}
-
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=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textranslate Step and Scroll
I wrote: The patch itself looks sane and easy. But I think I agree with John, this is a workaround for a design flaw in the step animation that we should just fix. Nope, it turns out we really do want truncation. The reason is that the input property to the animation, at least in Ron's case, isn't a single digit, it's the whole value. So you want to pass in the floating point value 29.92 and a step of 10 and get back 2, and *not* round up to 3. You want truncation for everything but the final digit, where rounding is more appropriate and the bias value is a useful workaround. So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a digit extractor animation instead. Andy - 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=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
