In java write expression evaluator left to right program

The requirements for the left to right evaluator are described in the file evaluatorassignment.pdf.

The required data is described in the file prog1.txt.

In class we discussed two uses of the minus sign: the binary subtraction operator (as in 5 - 2) and the

indicator of a negative number, as in 3 * (-4.22). There is a third use of a minus sign, the unary negation

operator, as in the expression -(5 + 3*(1+9)) and in 5 *( 3 + 17* (-(6+9/3+2) + 15). The unary negation

should appear in the input by using a minus sign followed immediately by (. The data with unary minus is

for extra credit. You can instead change these examples as follows: instead of -(5+3*(1+9)), use

0 - (5 +3*(1+9)) or (-1)* (5+3*(1+9)) (convert to binary subtraction or multiplication).

A file LR.java which has the code for the evaluator class, now called LR (not ExprEval).

A file LRTest.java which has the code for the main program class called LRTest (not ExprEvalatorTest).

A photo file with a screenshot of the output of a run with the required expressions.

For your assignment, you can use the right-to-left evaluator code as a starting point. Your evaluator class should have the following features: 1) permit spaces between numbers and operators. OK: 3.14 + 75 or ( 3.14+75 ) or 3.14 +75 or 3.14+ 75 etc. Not OK: 3 . 14 or 3 . 1 4 etc. You can decide on your own rules for spaces, but include these in the comments to the "user". 2) a negative number should have a minus sign followed immediately by a digit or a decimal point; further, negative numbers should usually be surrounded by parentheses. OK: 5 + (-13) or 5 -( -13) or 3+ (-.123) etc. If you want to permit -7 + 16, the code will need to be more complicated, so tell the "user" what is permitted. Not OK: 5 + -13 or 5 - -13 or 5 + (- 13) or - .7 + 16 etc. Indicating a negative number with (-x) is more natural than using _x, but it causes difficulties because we also use parentheses to enclose subexpressions, e.g. 3*(4+5). Without parentheses, this would compute (left to right) as17 instead of 27. But the dual role of parentheses requires extra attention. 3) Exponentiation should be permitted, with highest precedence. Use "a ^ b" to mean a to the power b. 4) Evaluation should be left to right. This is the main change. A) The formNum() method has to be rewritten so that it scans from left to right when it encounters the leftmost digit of a number or a leading decimal point. Of course, the method of building up the double value from the successive digits has to be adjusted since you are scanning from left to right- try some examples to discover the correct approach. B) The evaluator() method also has to be adjusted to scan from left to right. There are several changes: i) When a left parenthesis is encountered it is always pushed onto stack A unless it signals a negative number (as in 5+ (-13.4) +2). In that case, formNum() should be called to compute the negative number and push it as a double onto B, and the corresponding right parenthesis should be skipped over. ii) When a right parenthesis is encountered (but not the right end of a negative number) it triggers a call to evalDown() to evaluate the operations in a parenthesized subexpression until the corresponding left parenthesis is reached. The left parenthesis is also popped from A. iii) when the current token operator is equal in precedence to the operator at the top of the stack, do not push the token. Instead, perform the operation at the top of the A stack using eval(), and then compare the current token operator to the new top of the A stack. Example. Suppose we have 3.0 / 2.0 * 4.0 . We push 3 onto B , / onto A, and 2 onto B. If we (incorrectly) push * onto A (it has equal precedence with /), and then 4 onto B, we will compute 2 * 4 first and then 3/8.. Instead, we should compute 3./2 first and push 1.5, and later compute 1.5 * 4 = 6.0. (In right to left scanning, we always pushed the new operator if it had equal precedence with the top operator, now we do not push it.) iv) push a new token operator or left parenthesis (except one indicating a negative number) on top of a left parenthesis at the top of stack A. .

The assignment due date is given in the assignment section of the expression evaluation folder. Here is the input data for the expression evaluator program. The main program should repeatedly ask the user if there is expression to evaluate (y/n response). For each expression, the program should display the input expression and then display the value computed by the program. The main program should be rather short: whenever necessary, it should utilize the expression evaluator class, where most of the work is done. (See the Java files for the right-to-left evaluator for the idea: the file ExprEvaluatorTest is the main program, although in your program the input must be interactive, as described above.) For grading purposes, enter the following expressions in the order given: 1) 1+2*3+4 2) 1 + 2 * 3 + 4 In the rest of the examples, spacing is optional (within the limits described in the problem description, e.g., 3.145 is ok, but not 3 . 14 5, etc.) 3) 1+9/3-4 4) 121.75 + 3.25 5) 4+3*(1+2.*(6/(3+3.))-1)+2.0 6) 0.1*0.2 7) 0.011*.022 8) -(2-(-1)) (If you don't want to code the logic for -x (negation), where x is an expression, you can enter this as 0 -(2-(-1)), i.e., ordinary subtraction. Some extra credit if your program handles negation ( - as a unary operator). 9) 3.1415927^2 10) 3.14159^1+1 11) 2^(2*(2+3)) 12) (-3)^(-(3)) (or (-3)^(-3), whichever your program can do) 13) -(-(-(-1)))) (extra credit if you have coded negation (the unary -). Be sure to include the API (program interface which gives the purpose of the program and detailed directions to the person using the program as to the requirements and/or limitations concerning the input expressions (e.g., rules about spacing, about negative numbers, etc.). The program must also be clearly commented, with explanations about the purpose of various methods, etc.