> 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 > > > > >
