Changes

<!--I realized that shorthand parenthetical notation could become a problem when I was taking a 'C' programming course in college. Unfortunately, we are still using code that was written for computers that had severe memory limitations.  Unlike humans, mathematics modules do not look ahead to identify a parenthetical expression embedded within an equation. In the 'C' language, to process our given equation, we need explicit operators adjacent to the first parenthesis; additionally, we must maintain the grouping of our function(s). ''Still to this day, many programming languages / spreadsheets cannot process a parenthetical expression without an explicit operator.'' Entering the equation into a programming language, or low quality calculator require the explicit multiplication symbol and outer parenthesis. '''6÷2(1+2) == 6÷(2*(1+2))''' When our given equation is correctly conditioned to read, 6÷(2*(1+2)) the mathematics routine reserves additional memory to process the parenthetical expression(s) and then reassembles the equation according to the rules of the Order of Operations (PEMDAS). Conversely, in our given equation, 6÷2(1+2) the calculator processes 6÷2 and then discovers the parenthetical expression too late. Instead of branching to fix the mistake, or declaring an error condition, mathematics modules simply assume that the data-entry person is competent and adds explicit multiplication where implicit multiplication was given.  '''<div style="color:red;">6÷2(1+2) != 6÷2*(1+2)<as 6/div>'''  === The calculator solution === Our given equation is two terms, 6 is always equal to 6 and 2(1+2) is also always equal to 6, dividing these two numbers must always equal 1. The equation is not ambiguous, it challenges the theory that multiplication and division are equal into a cell in terms of the Order of Precedence. First, let's review fundamental fact that x÷1 = x and that 1*x = x. When we enclose a term within parentheses, implicit multiplication assumed, if the multiplier is not given, the multiplier is the number 1 because 0 times any number is 0. <div style="background-color:#E8E8E8; padding-left:30px;">Example that ignores the Distributive LawLibreOffice Calc spreadsheet will result in Err: '''6÷2509 (1+2)=?''' ::becomes... '''3÷1(1+2Missing operator)=?'''  As we see above, the explicit division sustains, as does the implicit multiplication, we have simply reduced both sides of the equation by This forces the common denominator of 2, leaving us with ''3÷1(1+2)=?''. When we try user to divide three by one, the one is also a common denominator, finding a common denominator does not dismiss division, but if we dismiss the assumed one, we must also dismiss the implicit multiplication. Continuing from above, we are left with format the following equation... '''3÷(1+2)=?''' '''3÷(3)=?''' '''3÷3=1'''</div>'''Therefore,''' if the calculator module has already processed the division 6÷2 by the time it reaches the parenthesis, the coefficient and the accompanying implicit multiplication has been eliminated. The division must be sustained to apply to the remainder of the function, in left to right processing, it cannot be presumed that an implicit/implied operator always infers using explicit multiplication in computer mathematics modules. In this case, the processing must branch.-->