Problem with radio gauge

[spokes2112 179]

Just go with "PVE's" response ( # 3 in this thread ) the "f" print format has been the same since I wasn't even a glint in my Pollack dads eyes. ( HINT.. The MS C version is the same, IBM 700, FORTRAN etc..... ) "f" print = "total digits" . "dot" "number of digits following, rounded appropriately"So go with the above ( PVE ) ,,,, no math,,,, just %!6.2f!% Regards from a Pollack,Roman

[Guest SIDDickDastardly]

Thanks for your continued patience in trying to explain the behaviour to me guys, but I still don't quite understand what's happening:Tom, I tried your formula i.e. (A:COM STANDBY FREQUENCY:1, MHz) 100 * near 100 / ...but I still get anomalous behaviour. For example when the frequency is 127.675 that formula gives 127.68, but when the frequency is 128.675, it displays 128.67. I understand your point about how extra digits to the right of the cut-off point could cause rounding errors, but the thing is there are no other digits - the value of the variable is always a multiple of 0.02500 (when drawn to 5 decimal places) i.e.xxx.00000, xxx.02500, xxx.05000, xxx.07500 ........etc to xxx.97500I don't understand how xxx.67500 can be rounded to xxx.68 for one value of xxx, but to xxx.67 for a different value of xxx. It's no big deal, as I've worked around the problem by just drawing the variable to 3 decimal places and masking the last digit, but it is a bit perplexing.More importantly, though, does anyone have any suggestions about the variables I'm trying to track down i.e. those which indicate nav1 failure, nav2 failure, adf failure, transponder failure, and which variable is currently adjustable with the + and - keys?Cheers,DDEdit: Sorry I missed your post, Roman. PVE's method also produces different results from the default stack e.g. it rounds xxx.025 down to xxx.02, but it rounds xxx.125 up to xxx.13. (In both cases, the default radio stack rounds down so it displays xxx.02 and xxx.12, respectively).

[taguilo 33]

I see you still don't get it. Let's try again :)"but the thing is there are no other digits - the value of the variable is always a multiple of 0.02500 (when drawn to 5 decimal places) i.e.xxx.00000, xxx.02500, xxx.05000, xxx.07500 ........etc to xxx.97500"Yes there are other digits, *masked* byt the !n.5f! function.123.0249999999998987957432 -> !3.5f! -> 123.02500 That's the reason you see 127.675 as 127.68 and 128.675 as 128.67. Instead of 'near' try using 'flr' which rounds to the lowest integer.But if I were you, I'll follow Paul (pve) and Roman (spokes112) advises and use !n.2f! or !n.3f! instead of all these maths...Tom

[Jim Robinson 122]

Played with this a bit and I see what you mean DD. I came up with this one which seems to work:((A:COM1 STANDBY FREQUENCY, KHz) 10 / flr 100 /)Why that would be any different than:((A:COM1 STANDBY FREQUENCY, MHz) 100 * flr 100 /)is beyond me, but MHz exibits the same rounding oddness.Jim

[Guest SIDDickDastardly]

>Yes there are other digits, *masked* by the !n.5f! function.>123.0249999999998987957432 -> !3.5f! -> 123.02500 Ah I finally see exactly what you mean - thanks for persevering m8 :). I'm still a bit baffled as to why the var would store a number such as the one in your example rather than just 123.025 exactly, but I can live with that degree of bafflement :).>But if I were you, I'll follow Paul (pve) and Roman> (spokes112) advises and use !n.2f! or !n.3f! instead of all>these maths...That's basically exactly what I did -I'm using just the frequency variable (formatted !n.3f!), with a mask image to eliminate the third digit after the decimal.Cheers,DDEDIT: Thanks for the tip with your KHz formula, Jim - I'll try that too.

[spokes2112 179]

DD & Others Plz show the whole string code.. blah blah Your "f" print probably is the source of multiple roundings, there should be no math involved.%!3.2f!% will not cut the mustard. go with %!6.2f!% Regards,Roman

[spokes2112 179]

Caught you on the last post..... NO MATH NECESSARY (stop) NO MASKING OF DIGITS NECESSARY (stop)It's the print format within the string that is causing the FUBAR. The print format can have alot of power ( rounding, pre, - post, zeros etc...) get the print format right and it's all good. Regards,Roman

[Jim Robinson 122]

Print format was %!6.2f!% . I forgot to mention in my last post that I'm using FS9, but the bottom line is ((A:COM1 STANDBY FREQUENCY, MHz))%!6.2f! doesn't give the expected result. Try it, tune to 123.12 and you'll see that it returns 123.13, for example, at least it does for me.Also, if you try something like (A:COM1 STANDBY FREQUENCY, number), you'll see that there's no such thing as a number like 123.0249999999998987957432 for radio frequencies. You'll get values like 123025000, 123050000, 123075000, etc.Incidentally:((A:COM1 STANDBY FREQUENCY, number) 10000 / flr 100 /)%!6.2f!also seems to work.Jim

[Guest SIDDickDastardly]

Just tried Jim's KHz formula i.e. %((A:COM1 STANDBY FREQUENCY, KHz) 10 / flr 100 /)%!6.2f!...and it worked perfectly without the need for using ".3f" and a mask, which simplifies things so I'm a happy camper :). I don't know why almost the exact same formula but in MHz:%((A:COM1 STANDBY FREQUENCY, MHz) 100 * flr 100 /)%!6.2f!...produces different results but it certainly does, presumably FSX must be doing some kind of rounding when it converts from MHz to KHz.>Also, if you try something like (A:COM1 STANDBY FREQUENCY,>number), you'll see that there's no such thing as a number>like 123.0249999999998987957432 for radio frequencies. You'll>get values like 123025000, 123050000, 123075000, etc.It took me a while to get my head round this too, but I think that Tom must be right that the MHz values of the variable really do contain weird values like that -there's no other explanation for the variations in rounding.The thing to remember is that you're never seeing the full unrounded value. Even if you ask for the value to be displayed to 10 decimal places, you'll see 123.5000000000 but the real value might be 123.49999999999999999999999. It's a bit like Shrodinger's cat: by looking in the box, the waveform is collapsed so you never get to see the cat alive and dead at the same time. Hmmm perhaps a better description would have been "It's not much like Shrodinger's cat" :).When you ask for the variable in KHz FSX must do some kind of internal rounding on the weird MHz value as well as just multiplying by 1000 which is why the anomalies don't occur with the KHz version of your formula. I guess something similar must be happening when you're asking for it as a "number" too i.e. (A:COM1 STANDBY FREQUENCY, number).Cheers,DD

[Jim Robinson 122]

>The thing to remember is that you're never seeing the full>unrounded value. Even if you ask for the value to be displayed>to 10 decimal places, you'll see 123.5000000000 but the real>value might be 123.49999999999999999999999.Well, my understanding is that "number" returns the raw variable before any calculations or rounding take place. In this case it's a 9-digit whole number, simply "Hz".>When you ask for the variable in KHz FSX must do some kind of>internal rounding on the weird MHz value as well as just>multiplying by 1000 which is why the anomalies don't occur>with the KHz version of your formulaKHz isn't arrived at by multiplying MHz by 1000, it's arrived at by dividing Hz (or "number") by 1000. Likewise, MHz is arrived at by dividing Hz by 1 million. There's something screwy with the hard wired formula that converts Hz to MHz is what I think. Doesn't seem like there could be much go wrong with dividing it by 1000000 but computers don't think in "tens" so maybe in machine language it's actually 999999.999999999999999999999999 or something, who knows. KHz would halve that error, so maybe that's why we get away with using KHz but not MHz. Purely speculation of course.Glad you finally found a formula you like, I was really hating the mask :) .Jim

[taguilo 33]

Jim,"Well, my understanding is that "number" returns the raw variable before any calculations or rounding take place. In this case it's a 9-digit whole number, simply "Hz"This is true. The problem is that the only way you have to "see" this number is through the "infamous" format !n.nf!, which ALWAYS rounds the value. And this is unavoidable, otherwise one wouldn't be able to work with floating point variables/numbers.FP numbers like 123234.5000 don't exist as is but rather their aproximation 123234.49999999etc.Tom

[Jim Robinson 122]

Tom,I certainly have no problem with that theory when dealing with an infinitely changing variable like A:FUEL TANK LEFT MAIN QUANTITY, but it seems to be different in the case of COM frequencies. I think because there are exactly 720 different frequencies available there is simply no need for anything in between. I think this illustrates my point:((A:COM1 STANDBY FREQUENCY, number))%!10.0f! - returns a number like 123025000((A:COM1 STANDBY FREQUENCY, number))%!10.10f! - returns a number like 123025000.0000000000Jim

[WarpD 824]

Ok people... keep in mind you're talking about a CPU. Floating-point data in the CPU is not guaranteed to be 100% accurate down to the last decimal point. There are a huge slew of reasons why... but just take it for granted that if you're looking for a floating point value where only the 5 left-most digits are of significance... everything to the right of that is 100% suspect.

[taguilo 33]

Ok Jim, I accept that understanding floating point operations could be rather unintuitive :(So, to convince yourself, check this:%(123024999.99999999)%!10.10f!result = 123025000.0000000000As a general rule, FP exact values are unpredictable depending whether they come from direct input (storing), or as a result of a math operation. That's the reason to use format tags, as they help to obtain the "expected" data we all need to work with.Tom

[Jim Robinson 122]

I see what you're saying. I took it that you were suggesting that a frequency like 123.0125 MHz was possible.Jim