Mathematical expression translator - Printable Version +- Qbasicnews.com (http://qbasicnews.com/newforum) +-- Forum: QbasicNews.Com (http://qbasicnews.com/newforum/forum-3.html) +--- Forum: Challenges (http://qbasicnews.com/newforum/forum-10.html) +--- Thread: Mathematical expression translator (/thread-10109.html) |
Re: Mathematical expression translator - yetifoot - 05-07-2008 Hi all, stumbled across this challenge, it's right up my street! Something I would say, is the rules and goals are not as clear as I'd like, should we be implementing everything that is possible in a QB expression? What about things like / and \ which are different in C, you only have / and have to promote to float to cause an FP divide. Are some things left-right or right-left? etc. Anyway, that aside I put one together that seems to show most of what you want. I prototyped it in FB, but it seems to work OK in the QB I have too. It does the operator precedence (I hope..!, I'm not too sure on QB's exact precedence, and didn't fancy trial and erroring to find out, but i based it on FBs so it should be very close at least), has operators +, -, -(negate), /, \, *, ^, SQR, can deal with array or variables (arrays change to a[] syntax), it handles parenthesised sub expressions. It might do some other stuff i forgot, or there may be features I implemented by accident when I added bugs It is not optimal by a long shot, there are many things I could have done to it. I could cut down the size of the code by rolling parseaddsub, parsemuldiv and others into one function, and using a table to control the operators. I could have cut down on the strings. I could have built a tree/stack from the expression in order to make it easy to optimize constants (ie (3 + 4) would become (7). But I didn't. Anyway, here's the code. Code: DECLARE FUNCTION parsenegate$ () Re: Mathematical expression translator - Frontrunner - 05-08-2008 Hi Yetifoot, Thank you for your contribution! I can see you have done this before Regarding your questions: The language/compiler/interpreter/translator can be called anything as long as the syntax is close to qbasic so your code looks pretty fine to me. The type of parsing is free to choose from so left-right or right-left, bottom-up, top-down all are fine, as long as the output is correct. You have a good point regarding the float and integer division operators, the last one doesn't exists in C. Example: PRINT 11 - (4 * FIX(11 / 4)) PRINT 11 / 4 PRINT FIX(11 / 4) PRINT 9 / 3 PRINT FIX(9 / 3) PRINT 67 / -3 PRINT FIX(67 / -3) Result Qbasic 3 2.75 2 3 3 -22.3333 -22 Result Visual Basic and C 3 2 2 3 3 -22 -22 Actually the result is not different in C but it doesn't show the correct output unless you explicit tell to output in float format. I hope I explained things somewhat better now : I didn't yet look very attentively to your code but so far it looks good, well done! Cheers, Frontrunner Re: Mathematical expression translator - wildcard - 05-13-2008 I haven't forgotten about the challenge, just havent' had much time lately. Got a fair bit still to do to make a proper parser though, but am interested in finishing it as would like to have a go making a simple basic like scripting language. Re: Mathematical expression translator - Frontrunner - 06-02-2008 Hi Wildcard, I am still waiting for your submission It's good to see that this challenge has given you a push to create a scripting language, I am looking forward to see the result! Cheers, Frontrunner Re: Mathematical expression translator - wildcard - 06-04-2008 Frontrunner: I haven't forgotten about the challenge, I'm still working on my entry when time allows. Re: Mathematical expression translator - Agamemnus - 08-06-2008 (04-29-2008, 10:57 AM)LPG link Wrote:I tried this from QB > C. i made it do this: The way you described it won't work with the second example either. You did do the right thing by going left to right, I think. A few pointers of my own: * Instead of adding spaces you could instead remove them. It is less mess when you try to parse it later. * In the same manner, it's less trouble to parse later when you add ()s between the start and end of numbers that have ^ powers. So 5^2 would become (5)^2. GENERAL pointers: * You can either do an iterative parser or a recursive parser: a recursive parser would try to find whole power sets and recursive deeper for each new one, while an iterative parser would have to keep track of the "tree"... Find the end of the expression (in this case ")^"), then find its end. In either recursive or iterative case, you keep searching for either the start of the expression (a "(") or the "end" of a new one --")^". In either case you need to counting non-power ending parentheses and ignore a corresponding amount of starting parentheses. It gets just a little bit complicated but basically you want to be able to parse something like "(5*(5+2))^5"... |