Sign in to follow this  
rcbarend

xml math question

Recommended Posts

Hallo,How do i read:(L:Var1,number) (L:Var2,number) - 5 / * (L:Var2,number) + (>L:Var3,number) Is that { (Var1-Var2)/5 * (Var1-Var2) } + Var2 = Var3 or{ (Var1-Var2)/5 * (Var1-Var2)/5 } + Var2 = Var3 or something else?Thanks, Jan"Beatus Ille Procul Negotiis"

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Something else...(Var1-Var2)/5 * whatever_there_was_on_stack_before + var2 => var3Arne Bartels

Share this post


Link to post
Share on other sites

>Thanks Arne,>>Thought about the same, but still looking for the "thing>b

Share this post


Link to post
Share on other sites

Ron,If i understand you correct, do you add a "c" while testing or always? (never tried myself)And if so, doesn't that interfere with the calculations?Is it an advice to do so and can you give a simple example?Jan"Beatus Ille Procul Negotiis"

Share this post


Link to post
Share on other sites

Hi Jan,If you have difficulty to understand how a stack-operation language (like RPN) works, try using a pile of papers :-)In essence a stack is nothing but a LastinFirstOut queue.Each time you "push" a value onto the stack, the stackpointer (stack[*]) is incremented; "popping" a value from the stack decrements the stackpointer. Just an example I gave someone else: If ((A >:( AND ((C > D) OR (E>F))) THEN .....Would be in XML:A B > C D > E F > || && if{ .... } Works as follows:- Stack[0] : becomes value A- Stack[1]: becomes value Bthe operator > takes the contents of Stack[0] and stack[1] and writes the value 0 (FALSE) or 1 (TRUE) on stack position stack[0] again. So value A and B are now lost on the stack- Stack[0]: result of A>B- Stack[1]: C- Stack[2]: D- Stack[1]: result of C>D- Stack[2]: E- Stack[3]: F- Stack[2]: result of E>F- Stack[1]: OR-result of stack[2] and stack[1]- Stack[0]: AND-result of stack[1] and stack[0] - And the IF operator now take the value of stack[0] to either do THEN or ELSE.A "c" operator just sets the stackpointer to zero.Now, in XML there's no real need to use the ClearStack command, since the validity of the stack is only limited to an .. section. I.o.w. the stack is automatically cleared if you exit the .ALthough of course the stack IS limited, I doubt you can find an algoritm that causes a stack-overflow :-).Unless you use Goto's ("g*" operators) and create an infinite loop of course.. Never tried that though. (since I hate using Goto's in ANY language)Cheers, Rob

Share this post


Link to post
Share on other sites

>Ron,>>If i understand you correct, do you add a "c" while testing or>always? (never tried myself)>And if so, doesn't that interfere with the calculations?>Is it an advice to do so and can you give a simple example?>Jan It clears everything on the stack. So, it would be appropriate to put a 'c' ahead of RPN code blocks you wanted to virginize. ..... c (A:some_var,number) > (L:my_var,number) ........ The A: variable puts that value on the stack. The ">" copies it to the L: variable. That also pops the stack. If the stack weren't empty before the 'c' instruction those variables would be on the stack. No problem unless one messes up later and accidently accesses such a variable. But, safer to start with a clean slate. BTW, if you want to keep (A:some_var,number) on the stack, add a 'd' (dup) before the ">". Or, do an 's1', then you can put a 'l1' in later lines if that variable is needed again. I suspect stack, s[tore], and l[oad] operations are faster than those using A: and L: variables. I program to use the former as far as feasible. Antother reason to use the c would be to keep the fragile MSFS XML/RPN from messing up. I think that's why I started using it, but am not sure it helped my problem. I know FS2K2 XML could only handle so many characters in a block of code. Add one character, and a later L: variable might not be calculated. FS9 improved on that, but who knows what kinks are left. "Good Programming" approaches reduce the change of running into difficult to find problems. Ron

Share this post


Link to post
Share on other sites

Ron and Rob,Thanks for your extensive info; it clears a lot!Jan"Beatus Ille Procul Negotiis"

Share this post


Link to post
Share on other sites

Hi Rob,I think the "c" command could be useful when working with nested macros inside a section. Going to give it a try.RegardsTom

Share this post


Link to post
Share on other sites

Hi Tom,Well, I am using nested macroes myself.But I still don't see a use for the "c" command :-)It's just good programming practice to make sure the stack is empty when to exit an Element without using the "c" command.A non-empty stack on exit might indicate an error somewhere in your code.Regards, Rob

Share this post


Link to post
Share on other sites

Rob,I thought it could help to make macros behave like functions. It didn't work though.:-( CheersTom

Share this post


Link to post
Share on other sites

Hi Tom,What do you mean by:""I thought it could help to make macros behave like functions.""???? Cheers, Rob

Share this post


Link to post
Share on other sites

Rob,As you know, a macro is different from a clasical function as its code is "inserted" literally in replacement of the calling name; and so you need to condider other things when using it inside a section (ie stack values) just to get the proper result.For example, you have these macros: 5 4 + 8 == if{ 10 } /Macro> 2 @Macro1 * 5 @Macro2 +And the element: @Macro3 5 + (>L:ViewTest,enum) ...etcAt first sight L:Viewtest should equal 10 ("function behavior")Instead,If you read @Macro1 directly, you get 0Reading @Macro2 returns 0 tooBut @Macro 3 returns 10 And L:ViewTest receives 15In short, replace macros' code and you have 5 2 5 4 + 8 == if{ 10 } * + 5 + (>L:ViewTest,enum) Where stack values interact to obtain the final valueHas this been clear? or maybe I messed it a bit :-) Still testing...RegardsTom

Share this post


Link to post
Share on other sites

Hi Tom, Yes, I get your point.On the other hand, with what I call "correct" programming you can emulate "classical functions" with "macros" operating on the stack perfecty (apart from things like visibility rules etc.) as long as you yourself guarantee that the stack remains balanced.In a programming language using "functions" the compiler just does that for you...In other words: each macro should keep the stack balanced.Using: 5 4 + 8 == if{ 10 } els{ 0 } /Macro>would have avoided this problem you mention.See my point ?Iow, if you ensure that:- "pushed" parameters by a calling macro are always "popped" by the called macro.- the "pushed" "return values" of a macro are always "popped" by the caller- within the macro, the stack remains balancedyou can perfectly emulate "functions" by "macros".Iow: it doesn't make any difference if you "call" a macro from whatever place in your entire code; the result is always the same.Of course, within the limitations of XML (like no "sharing" of macros between gauge)As a sidenote:with my background as an assembly-language programmer, I'm still of the opinion that you can do even real "object-oriented" programming in assembly language (or even XML); even things like "inheritance".The only thing is that it requires great discipline in programming and that there is no compiler to correct you, or making things impossible or hide things. After all, it all results in the same machine code. And if a compiler can generate it, I as a programmer can too.However cumbersome and unpractical :-)Cheers, Rob

Share this post


Link to post
Share on other sites

Hi Rob,I exposed that example ex-profeso (including the lack of els{} operator), first because it is easy to follow, and second ,if you put it directly like this 5 4 + 8 == if{ 10 } (>L:XXX,nn)You will get an expectable result, with no need to use the els{}, saving a bunch of code (again, take it as a simple example).In essence, I agree with you that macros can perfectly emulate functions; my point is you have to be very careful when working with some complex ones, in that you need to take care of the stack composition at any time, otherwise you'll end up with unpredictable values, sometimes being very difficult to debug. RegardsTom

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this