FSXA Would like to understand random number code

#1
I need a random number generator for a gauge. In the wiki there are two examples. Both involve, among other things, taking absolute values of absolute time. Since absolute time is always positive, I don't understand the point of that step in the code. I'm sure the code works, but I prefer to understand what I'm using so I learn something from the process. Here is one (by Tom Aguilo) of the two examples:

Code:
<Macro Name="Rand31">
  (L:INSRandFact31,number) 0 ==
    if{
      (P:Absolute Time,seconds) abs 10 / int (>L:INSRandFact31,number)
    }
  767789427 (L:INSRandFact31,number) * 4711345623 + 2000000000 % d (>L:INSRandFact31,number)
  20000000000 / 1 % abs 10 *
</Macro>
I don't understand why "abs" is used in either instance as I can't see how what proceeds that expression can ever be negative.

Also, is the Absolute time P variable given by the sim in decimal seconds, and if so, to how many decimal places?
 

taguilo

Resource contributor
#2
The original author of that macro was Ron Freimuth, and he did it in the very first times of FS2004.

I'm really not sure why he used the abs operator, but I guess he could have thought (or tested?) that (P:Absolute Time,seconds) might be negative in the first cycle of a gauge.
Would be great that you try removing abs from the formula and see if it works as expected.

Regarding P:Absolute time, the variable is of type long because of the size of the number it must hold; then it's not possible to read as a number in XML; a string !s! format must be used intead.


Tom
 

JB3DG

Resource contributor
#3
Tom, I'm not sure about that. Keep in mind all XML L vars are doubles ie 64bit. A long will easily go into a double if we are talking C++. I have used P:ABSOLUTE TIME in L vars for various timing systems in XML (although I don't do much XML anymore).

That said, from my tests P:ABSOLUTE TIME does put out decimal seconds (not sure how many), while E:ABSOLUTE TIME puts out integer seconds.
 

taguilo

Resource contributor
#5
Tom, I'm not sure about that. Keep in mind all XML L vars are doubles ie 64bit. A long will easily go into a double if we are talking C++. I have used P:ABSOLUTE TIME in L vars for various timing systems in XML (although I don't do much XML anymore).
I didn't say P:ABSOLUTE TIME can't be assigned to L:Vars, what I said was it can't be displayed as a number either with !d! or !f! XML formats. But it can be displayed using !s! format, which shows a value with +e structure.

Tom
 
#7
Tom,

Do you remember this (FFDS Forum Oct 2007)? Your Reply #6 to my question in Reply #5.

Bob

[edit] relevant parts copied:

Question: And, we aren’t sure what’s up with E: or P:ABSOLUTE TIME. Display ABSOLUTE TIME in !12d! and you get something like -1097542699 which doesn’t make immediate sense but maybe now I see why the first operator in Tom’s (taguilo) recent Quasi-Random event post is ‘abs’ ( if{ @Time abs ….. ).

Answer: And P:ABSOLUTE TIME returns an inverse counter in sec, mins, hours, etc from a target date (value =0 ) which year is located near 2042, that's the reason for being negative.


I'm sure I was running FS9 in 2007 when I posted that, but I can't replicate it today in FSX. To display it in FSX, I need to divide by 1000 or use !s! as you say.

At any rate, perhaps this is the root of the use of the abs operator questioned by Michael2
 
Last edited:

taguilo

Resource contributor
#8
Bob,

Good catch. Honestly I didn't remember that thread at all. And I cannot recall whether that statement of mine was a product of my own tests or Ron's ones. Would be great that someone repeat it in FS2004 and post the result.

Now, in FSX the value is positive, giving -for year 2015-a number of ~ 6.354000e+10 which corresponds with seconds from 00:00Z Jan 01, 0000. Therefore abs, in this case, might be safely removed.

Tom
 
#10
Take a look at the middle screen shot here. That was running FS9 and (P:ABSOLUTE TIME, seconds) displayed as !13d!

[edit] I just fired up FS9 (FS2004 version 9.1 build 40901.01) and (P:ABSOLUTE TIME, seconds) is a negative number which counts upward towards zero, and points to time zero of 13 July, 2042.

Under the circumstances, I guess I would just leave the 'abs' operators in those random number generator scripts.

Bob

upload_2015-11-25_10-49-50.png
 
Last edited:
#11
Using this XML script:
Code:
1.  (P:ABSOLUTE TIME, seconds)
2.  (P:ABSOLUTE TIME, seconds) -1 * (>L:AbsTimeNegative, seconds)
3.  (P:ABSOLUTE TIME, seconds) 10 / (>L:AbsTimeDivide10, seconds)
4.  (P:ABSOLUTE TIME, seconds) 10 * (>L:AbsTimeMult10, number)
5.  (P:ABSOLUTE TIME, seconds) (>L:AbsTime, seconds)
6.  (P:ABSOLUTE TIME, number)
7.  (P:ABSOLUTE TIME, enum)
the following results:

upload_2015-11-25_22-58-6.png


Comments on the Blackbox display:
- "seconds" units are displayed as !12d!
- "number" units are displayed as !15.2f!
- "enum" units are displayed as !12d!
  • Line 1. ABSOLUTE TIME appears to be a negative number. It counts upward toward zero
  • Line 2. Multiplying ABSOLUTE TIME by -1 produces a positive number which counts upward
  • Line 3. Dividing by 10 produces an apparently larger number that doesn't appear to be a factor of 10 different than P:ABSOLUTE TIME. It is positive and counts upward
  • Line 4. Multiplying by 10 produces an apparently smaller number that doesn't appear to be a factor of 10 different than P:ABSOLUTE TIME. It is positive and counts upward
  • Line 5. Storing P:ABSOLUTE TIME in an L:Var with seconds units just replicates the number. It is negative and counts upward
  • Line 6. Displaying P:ABSOLUTE TIME using number units and displayed as !15.2f! (or any f format) causes loss of the integer portion of ABSOLUTE TIME. Only the decimal portion is displayed. It is positive and counts upward. However, it's interesting that Line 4, multiplying by 10 and displaying number units !15.2f!, displays both the integer and decimal portions of the number.
  • Line 7. ABSOLUTE TIME, enum is displayed using !12d! and replicates ABSOLUTE TIME, seconds
  • The string length, 'slen' of (P:ABSOLUTE TIME, seconds), (L:AbsTimeDivide10, seconds), and (L:AbsTimeMult10, number) is 11 for each one.

There may be an integer overflow issue involved that produces the negative values, but I don't understand the root cause.

Bob
 
Last edited:

taguilo

Resource contributor
#12
There may be an integer overflow issue involved that produces the negative values, but I don't understand the root cause.
Bob,

The negative value is indeed an overflow, as it seems there is no implicit conversion between long (or long long) and double in format specifiers (!d!, !f!). FSX returns garbage instead.

Tom
 
Top