From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Feb 06 2007 - 05:02:48 CST
From: <vunzndi@vfemail.net>
> PS my congratulations to anyone who can change (a+b/c+d)/(e/f+g)
> into reverse polish order in a less than five seconds in their head
I do agree that the reverse polish order is not easy to visualize if the operator is leading, but if you put the operator at end, it gets simpler for many programmers (at least those that use common languages like PostScript, or are trained with the assembly language and finite state machines with a stack, so yes I can read easily this one:
abc/+d+ef/g+/
(your expression rewritten with operators after their operands), rather than this one:
/++a/bcd+/efg
(your expression written with operators before their operands)
I did not want to send critics about your notations which are extremely clear; but the main interest of the "Polish" (or reversed Polish) notation is that it can be made by simple concatenation of its components, so it allows simple substring searches (no need to worry about operator priorities and possible parentheses. This may be useful in an input editor when looking for matching ideographs containing some radicals.
And the - operator proves to be useful when there are missing (still unencoded) basic radical (or strokes), and only a composite one is encoded.
Some other similar notations could be used to denote the overlapping composition of strokes on top of another ideograph, because such overlaps are not correctly represented with the current set of IDC symbols.
Also I suggested that the IDS could contain some informational diacritics to denote the fact that a basic radical or stroke is significantly altered from its base glyph form (notably when a ideograph is composed using justapositions like surrounding/enclosing: the surrounding or enclosing radical or stroke may often be altered to leave space for the central radicals or strokes.
This archive was generated by hypermail 2.1.5 : Tue Feb 06 2007 - 05:08:01 CST