
Algorithm Needed
Hey,<BR><BR>I am doing analysis for rewriting a module that we refer to as the "Math Editor". Basically, it looks like a calculator and is used to create a "Rule" to be used in a "Rules Engine". The expressions that can be created for the rule are special in the sense that the oprands can also include a field from a transaction record and/or some thing we refer to as a "Container Function".<BR><BR>A typical expression may look like:<BR>500 + (Table.Field * 100) / Container.Sum<BR><BR>The problem is this  the "rule" XML stores the expression as a data structure that mirrors Polish Notation [not Reverse Polish Notation]. It would be extremely easy for me to store the expression if the user would key the expression as if they were working in Polish Notation. However, I cannot convince the powers that be to train end users to do this. So....... I need an algorithm to take expressions that are keyed in sequence from left to right and track the expression so that I can either eventually or simultaneaously convert it to Polish Notation.<BR><BR>To get a better picture of the structure, look at the expression tree here: http://www7.brinkster.com/christophern/mdsve.htm<BR><BR>I posted this in the Advanced Forum because I doubt that anyone but Bill Wilkinson knows *** I am talking about. Thanks

RE: Algorithm Needed
So 500 + (Table.Field * 100) / Container.Sum should look like:<BR><BR>500 Container.Sum 100 Table.Field * / +<BR><BR>I guess you need to parse for "(" then ")" grabbing the in between. You will need to run 2 strings for the vars, and the operands. Then combine the strings, or just gen the XML.<BR><BR>HTH<BR><BR>__Stephen

RE: Algorithm Needed
That is the way it works now. We want to move away from parsing strings: the expressions can become fairly complex and heavily nested. It is hard to recognize operands, given the unusual nature or the viable operand types. What I really need is to track operands, operator, and sub expressions AS THEY ARE ENTERED, and not after the fact [an expression as a whole]. Thanks.

ATTN: Bill Wilkinson
Hey Bill,<BR><BR>I have heard you talk about RPN on here. Any ideas about my problem???

Well, if my handheld calculator...
...can do this, you *should* be able to do it.<BR><BR>But "forward" Polish Notation??? Ugh.<BR><BR>That's not efficient to process, let alone produce.<BR><BR>Hmmm...but I wonder...I've never played with forward Polish, but I wonder if you can just reverse Reverse Polish???<BR><BR>My brain hurts.<BR><BR>Actually, if you think about it, when you parse a string to convert it to RPN, you never backtrack, do you? So what's the difference between that and just parsing the stuff as it is entered? I don't see a logical difference here.<BR><BR>I gotta run for now...back later.<BR><BR>

How about a sample?
Of a few expressions that have been converted to forward Polish that is acceptable to that system?<BR><BR>I want a sanity check on my notion that we can simply reverse the RPN.<BR><BR>

RE: How about a sample?
Hey Bill,<BR><BR>I do not know if strict Polish Notation is what I am after, or some version thereof, of something that I am making up. Basically, I need to have expressions ordered as:<BR>Operator, Oprand1, Operand2, .... OperandN<BR>If any of the operands are a subexpression, then the process starts again. <BR><BR>For this expression:<BR>( Accrued Interest from the Financial (IP) Datasource * .05 )  Fee from the Financial (IP) Datasource<BR><BR>The end result will be an XML structure like this:<BR><DSV_EXPRESSION><BR><TYPE& #062;MATH</TYPE><BR><OPERATOR>MINUS</OPERATOR><BR><OPERANDS><BR><DS V_EXPRESSION><BR><TYPE>MATH</TYPE><BR><OPERATOR>TIMES</OPERATOR><BR><OPERANDS><BR><DS V><BR><DATASOURCE><BR><NAME� 62;Financial</NAME><BR><FIELD>accrued_interest� 60;/FIELD><BR></DATASOURCE><BR></DSV><BR><DSV><BR><LITERAL> ;<BR><DATA_TYPE>UNDEF</DATA_TYPE><BR><VALUE>.05</VALUE><BR></LITERAL><BR></DSV><BR></OPERANDS><BR></DSV_EXPRESSION><BR><DSV><BR><D ATASOURCE><BR><NAME>Financial</NAME><BR><FIELD>fee</FIELD><BR></DATASOURCE><BR></DSV><BR></OPERANDS><BR></DSV_EXPRESSION><BR>

Ugh. That's really ugly XML!
Just for example, it should be<BR><BR><DSV_EXPRESSION Type="MATH"><BR><OPERATOR Type="MINUS" /><BR>...<BR><DATASOURCE Name="Financial" Field="accrued_interest" /><BR><LITERAL Data_Type="UNDEF" Value="0.05" /><BR><BR>etc.<BR><BR>In fact, I wonder if <DSV> could be "folded in", as well.<BR><BR><BR>It's purely silly for OPERATOR and LITERAL to be done other than that, and I *suspect* that is true of DSV_EXPRESSION and DATASOURCE as well (can't tell from the limited example).<BR><BR>Let's see....<BR><BR>So in more readable notation, that becomes:<BR>  * [Financial.accrued_interest] [0.05] [Financial.fee]<BR><BR>And in RPN it would be<BR> [Financial.accrued_interest] [0.05] * [Financial.fee] <BR><BR>Ugh. So PN is not simply RPN reversed. Double ugh.<BR><BR>I've never written code to generate PN, I'm afraid. Not instantly clear to me how to do so.<BR><BR>This simple example makes it appear that you would simply prepend the operator to the front of the sequence, instead of dropping it "in place" as you do with RPN, but I'm not convinced that's true of more complex expressions.<BR><BR>Have anything reasonably complex that can give a better example?<BR><BR><BR><BR>
Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules

