## Forum archive 2000-2006

### D. Winslow - parsing of entries

by Arnold Pizer -
Number of replies: 0
 parsing of entries topic started 3/15/2005; 9:05:01 PMlast post 3/16/2005; 8:07:30 PM
 D. Winslow - parsing of entries  3/15/2005; 9:05:01 PM (reads: 978, responses: 2) We are presently using MapleTA for large lecture sections of a business calculus course. There is a Maple-maple mode option for certain problems in which the student entry is passed for grading as a text entry with no parsing. We have to use this for specific types of problems in which certain characters are not allowed as entries in other modes such as interval notation, set notation, etc. We then have routines that check these unparsed entries for correctness. There is now a need to write a parser for this mode that will parse formulas and numerical entries in this mode. In trying to model what MapleTA does in other modes, I found that the system is inconsistent in how exponentiation is handled. In strict text entry mode, x^y^z is parsed as (x^y)^z. There is also a symbol mode in which users are told that keystrokes as well as a symbol palette can be used in which the same entry is parsed as x^(y^z). I think there should be consistency between modes, and I thought that the former parsing was chosen in text mode to model how calculators interpret such entries, but it turns out that the parsing is not completely consistent with calculator interpretation either. I notice that WebWork interprets x^y^z as x^(y^z) and that probably should be the convention if there is to be one. My question is this: If parentheses are omitted prior to a function argument, opening parentheses are inserted and then closed prior to any operation in WebWork v1.9 (lnx+2->ln(x)+2,sinx^2->sin(x)^2). However sin-x^2->sin(-x^2), and I believe this probably should be the convention considering order of operations. Then shouldn't sin--x^2 be parsed the same as sinx^2 (it is not in WebWork v1.9), and if not is there a strong argument not to do so? It would be very easy to have a parser do this, and I saw some discussion of this being the general rule in more current versions of WebWork. How is this handled in the current WebWork release and can the parser be configured to accommodate either parsing convention? David <| Post or View Comments |>