On Wed, 23 Aug 2000, Quim Sanmarti wrote:
> > Yes, the boolean parser doesn't try to do more than n=2 right now.
> But it will, won't it?
Let's get the thing to parse correctly first! Then we can worry about
merging "a and b and c and d" into an n=4 node. Realistically speaking,
it's only an issue for AndParseTree nodes and maybe NotParseTree nodes
when those come in.
> > I left precedence for both to be the same, based on left to right
> parsing.
>
> Oh, but that is not compatible with the old syntax. Besides, don't you find
> strange that 'a or b and c' and 'b and c or a' give different results?
> Every nerd in the world will hate that. At least I confess I will.
Sigh. The problems of being a theorist--if you take a look at any
mathematical logic book, they'll tell you this is the correct way the
operators are defined. They should have the same precedence and work
left-to-right. (And it's the way *I* parse statements.) Some people decide
that AND->* and should thus have higher precedence than OR->+ (which is
your argument).
Linguistically speaking "a or b and c" means something different than "b
and c or a." The first means "(a or b) and c" and the latter means "(b and
c) or a." I'll let you write the truth tables, but I've never talked to
someone who treated them equivalently. And the nerds I know put parens in
where it's ambiguous.
I'll give you a written example if you want. But this is just the two of
us arguing. Other opinions?
> > I hope to commit a pile of cleanups tonight.
> You fast guy. :)
I never said I'd fix *everything*, just that I'd get some cleanups in. :-)
(Fast also depends on your reference--maybe in a 5K...)
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
