associativity, commutativity

[leesugil]

the previous update on fixing the -1 a b -1 -1 a b -1 a b -1 situation is a good temporary solution, but good a slightly different approach than the philosophy of the whole project. it was a hard-coded solution that only works for arithmetic properties of +, -, , /, and we want symbolic to be truly symbolic, understanding the properties of each operation and using it to solve problems, not relying on hard-coding for +, hard-coding for -, hard-coding for , hard-coding for /, etc.

[leesugil]

should be good:

• parseExpr
• evalExpr
• updateSymb

things to review

• updateExpr
• distExpr
• calcExpr

[leesugil]

the philosophy will be the eventual goal, but i want to assure that i ship a working solution for +, -, , /, ^, % first. i'm gonna focus on 2 x 3 not yielding 6 x for now.

[leesugil]

in calcExpr, 1) when facing x * 3 always take as 3 * x (not just on the surface but by switching left and right)

2) when facing 2 * 3 * x strtod or strtod2 will do the key job.

3) when facing 3 x \ 2 strtod will still tell us whether left was a pure-num or not.

4) when facing y * 3 * x if strtod says right has a number, then the number, the left, and the remaining right will do the job.

5) when facing 3 x \ y similar logic.

implementing the first item is the key. with that, strtod will do the rest of the job.

when facing left and right, use strtod to classify them into three cases:

1. a pure number
2. a pure symbol
3. composite with the number showing up front.

[leesugil]

from the above, 1) should be handled by distExpr as distExpr already handles re-structuring the whole expression tree.

the rest should be handled in calcExpr

[leesugil]

change of plan: instead of handling 1) in distExpr, do the basic commutative work in a new function commExpr, run it before calcExpr

[leesugil]

resolved