JSON Parser Update - Evaluation of Expressions vs. PEMDAS

[Love Zhaoying]

 

An update on the JSON Parser I have been working on.  This post was specific enough, that I created a separate thread.

For years, I had "vapor lock" (of the brain) trying to figure out a PEMDAS parser for LSL, to evaluate expressions. 

For non-math geeks: PEMDAS is an acronym for the "order of operation" most often used by humans when evaluating a mathematical expression: P- Parentheses, E- Exponents, M- Multiplication, D- Division, A- Addition, and S- Subtraction.

I sat down, wrote out an example..and figured out that my new JSON Parser handles pre-parsed PEMDAC expressions, in "natural reading order" that you would expect to see!

Example written mathematical formula:   

      a + b * c

      This should be evaluated as if it were:

      a + (b*c) -  because "*" has a higher precedence than "+" in the Order of Operations.

My JSON Parser works fine for any of the representations below.

This one matches most closely with how PEMDAS would be used to evaluate an expression): 

      { ["^@a", "^ADD", "^@b", ["^MUL", "^@c"] ] }

This would also work the same:

      { ["^@a", "^ADD", ["^@b", "^MUL", "^@c"] ] }

Or:

      { [ "^ADD", "^@a", "^@b", ["^MUL", "^@c"] ] }

Or:

      { [ "^ADD", "^@a", [ "^@b", "^MUL", "^@c"] ] }

Or:

      { [ "^ADD", "^@a", [ "^MUL", "^@b", "^@c"] ] }

etc. - there are more, but I really only showed variations so you can see that the placement of "^@" elements can go either way - before or after "^ADD" and "^MUL".

In the above examples:

- ^ADD is a function to "add" two numbers

- ^MUL is a function to "multiply" two numbers

- ^@a, ^@b, ^@c mean "get the value of variable a, b, or c respectively

- The result of the operations is put on a "Parameter stack" for some other operation to use, put in a variable, etc.

Now I can write an "interpreter" / "evaluator" to read formulas (or statements in standard LSL) - and have it convert them to my JSON Parser format!

P.S. The current generation of my JSON Parser:

1) Is iterative - NOT recursive!

2) It can work asynchronously.

3) It does not use "LSL Lists" at all, except as needed for llJson*() function parameters and other LSL calls.

Oh Em Gee!

 

Edited October 12, 2022 by Love Zhaoying

[Joeey Aura]

Another way of doing this which has been done for years is  changing the formula to postfix notation. then its completely easy to evaluate the expression.. the normal human way is called infix, which makes more sense to us. but postfix makes more sense to computers.  2+3 becomes 2 3 + in postfix. 

consider this example that has some order of operations

2*(4+4) becomes 2 4 4 + * 

to evaluate you use a stack.. (expressed in a list in LSL most likely)

• push 2 to the stack.
• push 4 to the stack
• push 4 to the stack

when you come upon an operator evaluate the last 2 numbers on the stack. 4+4 and push the result to the stack

now you have 2 8 on the stack. you come to another operator and you do 2*8.. push the result to the stack..

and there's nothing left so the value on the stack is your result.

with postfix notation every formula with complex order of operation becomes trivial to evaluate 

[Quistess Alpha]

2 hours ago, Joeey Aura said:

postfix notation

IMO prefix notation is slightly more human readable ( * + 4 4 2 -> the product of the sum of 4 and 4 and 2 ) but I'm a big fan of both.

[Love Zhaoying]

Yes but..since my solution is both prefix and postfix..well, it's hard to describe the benefits. It just works.