Possibly...but I think I've shown you can minimize that (what I was trying to demonstrate with that code at least) if you start with a limited number of tokens. I mean, we'll have to do it anyhow, might as well start now. Its up to you, but this approach will allow us to work together w/o stepping on each others toes....otherwise we'll continually have merge problems as I work on sections and you do.
Consider a "priority" property assigned to tokens that designates the order. Things with equal priority are ordered equally, things with higher priority are ordered higher. I think you're on the right track but I think you need to look at a bigger picture and yet work with a small set of tokens. I can see so far somethings you're doing that are probably not compatible with the end run of things...thats okay at this stage, but should be mimized. For instance. Parenthesis can be functions, but they can also be cosmetic. Excel supports both tokenized cosmetic parens and those that just designate what goes in a function. So the parenthesis in SUM(A1:A2) doesn't really get tokenized, SUM does. The parenthesis for 1+(3+4) would be tokenized. Its not necessary but is used for cosmetic purposes. This could easily be handled by the token implemented parser approach... but will produce exponential amounts of code in a monolithic approach. Not saying all this has to be implemented at once, but letting the tokens handle the conversion back and forth lets you seperate these concerns much more aptly. thanks, Andy Avik Sengupta wrote: >>existing code focuses mainly on RPN... Thats only 1/4 the problem. >> >true. I'm trying to focus just on that at the moment, i am sure i'll be swamped >if i try to be more ambitious to start with. > >Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > >>Avik Sengupta wrote: >> >>>Thanks Andy. >>> >>>I've finally figured the complete algorithm for infix to postfix conversion >>> >>.. >> >>>will code it in later tonight/early tomorrow. As promised, i should have a >>> >>>version of a formula parser that does integers and arbitrarily nested braces >>> >>by >> >>>this weekend. >>> >>okay. >> >>>About your code, andy, i was just wondering, if it would be better to have >>> >>>parsing done in a single class, or let each ptg do its own bit of parsing >>>(which is more object oriented, i suppose?). Still havent made up my mind on >>> >>>how to do it, but i feel the decision will be primarily based on how we do >>> >>>functions .. that will be the most difficult to parse, i think. What do u >>> >>think? >> >>Each class should. Here's why: there are 100 different (nearly >>precisely 100) PTGs. That would be a really big class. Second, your >>existing code focuses mainly on RPN... Thats only 1/4 the problem. >> >>1. convert from binary tokens to arabic notation (hex bytecodes to -> >>123+-etc) >>2. convert from arabic notation to binary tokens (1+2 -> hex bytecodes) >>3. convert from normal order to RPN >>4. convert from RPN to normal order >> >>Only its even worse... some PTGs have subtypes. Incorporating all the >>logic for SUM( must take into account that the same PTG handles AVG( and >>other functions as well. This would be one big honker of a class! >> Thats why it should be in each token and not in one class. >> >>-Andy >> >>>Cheers >>>- >>>avik >>> >> >> > > >
