As I humbly ran into. I thought of '-a', and 'a' but hadn't thought too
far ahead. It covers enough ground to satisfy me for now though. Mixing
real precedence and unary operators is something I experimented with a
little a few months back and couldn't find anything good. This is my
first parse
On Monday 22 January 2007 22:29, Chris Hostetter wrote:
>
> : With my syntax you can get real precedence that mixes with how no
> : precedence (Lucene's unary operators) works. No precedence is created by
> : allowing you to make any operator resolve first...any operator that
> : resolves first co
: With my syntax you can get real precedence that mixes with how no
: precedence (Lucene's unary operators) works. No precedence is created by
: allowing you to make any operator resolve first...any operator that
: resolves first connected with another operator that resolves first will
: behave as
Chris Hostetter wrote:
: This exchange has caused me to reassess my syntax. It seems that
: QueryParser's handling of A B C -D -E is special because QueryParser
: does not have any operator precedence rules (unless the 1 rule is that
: all operators resolve with the same precedence ). What woul
: This exchange has caused me to reassess my syntax. It seems that
: QueryParser's handling of A B C -D -E is special because QueryParser
: does not have any operator precedence rules (unless the 1 rule is that
: all operators resolve with the same precedence ). What would appear
there are some pr
Chris Hostetter wrote:
: > so do you convert A ! B ! C into a three clause boolean query, or a two
: > clause BooleanQuery that contains another two clause BooleanQuery?
: >
: It becomes a three clause boolean query...would there be a difference in
: scoring? I assumed not and it used to make a b
: I will certainly start experimenting with this. For clarification
: though, you are telling me that the Lucene syntax query: 'Mark AND pig
: AND man' is different than the query: '(Mark AND pig) AND man', correct?
Ummm... because you are making all of the clauses required, the parens
*may* not
: This sounds troubling to me now :) I may need to clear up my
: understanding of this and rework the parser:
: "A | B | C ! D ! E" wold get parsed as allFields:a allFields:b
: (+allFields:c -allFields:d -allFields:e)
: This is because ! binds tighter than |...
: Sounds like I need to bone up on
Incidently, is field1(foo bar) a shortcut for field1(foo) field1(bar) like
in the regular QueryParser?
I believe I just or the queries together:
example = "field1,field2((search & old) ~3 horse)";
expected = "(+spanNear([field1:search, field1:horse], 3, false)
+spanNear([fie
Chris Hostetter wrote:
: I wasn't clear on this answer. The problem was not grammar ambiguity but
: from a user standpoint...I wanted to differentiate the proximity binary
: operator from the phrase distance operator...even though they are
: similar. Perhaps the differentiation is more confusin
: This sounds troubling to me now :) I may need to clear up my
: understanding of this and rework the parser:
: "A | B | C ! D ! E" wold get parsed as allFields:a allFields:b
: (+allFields:c -allFields:d -allFields:e)
: This is because ! binds tighter than |...
: Sounds like I need to bone up on h
: I wasn't clear on this answer. The problem was not grammar ambiguity but
: from a user standpoint...I wanted to differentiate the proximity binary
: operator from the phrase distance operator...even though they are
: similar. Perhaps the differentiation is more confusing then helpful.
it's not
you kind of lost me there ... i get that ~ is a binary operator, but in
both cases the intent is to say "these words must appear near eachother"
...s oi'm wondering why you cose to use "hard knocks dude":3 instead of
"hard knocks dude"~3 oh wiat, i think i get it ... was it to
eliminate amb
: > so do you convert A ! B ! C into a three clause boolean query, or a two
: > clause BooleanQuery that contains another two clause BooleanQuery?
: >
: It becomes a three clause boolean query...would there be a difference in
: scoring? I assumed not and it used to make a boolean that contained
: > so do you convert A ! B ! C into a three clause boolean query, or a two
: > clause BooleanQuery that contains another two clause BooleanQuery?
: >
: It becomes a three clause boolean query...would there be a difference in
: scoring? I assumed not and it used to make a boolean that contained
:
: It works like this: "A -B -C" would be expressed as "A ! B ! C"
: By binary, I mean that each operator must connect two clauses...in that
: case A is connected to B and C is connected to A ! B.
: I avoid the single prohibit clause issue, -query, by not really allowing
so do you convert A ! B
: It works like this: "A -B -C" would be expressed as "A ! B ! C"
: By binary, I mean that each operator must connect two clauses...in that
: case A is connected to B and C is connected to A ! B.
: I avoid the single prohibit clause issue, -query, by not really allowing
so do you convert A ! B !
Hey Hoss,
I didn't realize that I had left out the field stuff...I really am still
working on a lot with the parser's documentation and I apologize.
Mark: I only read your querysyntax.php and didnt' dig into the source, but
i'm curious about the "There are no unary operators in Qsol syntax"
st
: http://www.myhardshadow.com/qsol.php
Mark: I only read your querysyntax.php and didnt' dig into the source, but
i'm curious about the "There are no unary operators in Qsol syntax"
statement what is the Qsol equivilent of the QueryParser syntax: "A -B -C"
It's also not clear to me how diffe
I have released a Technology preview of my Lucene query parser Qsol.
This is the first official release. The purpose of this release is to
gather feedback for a 1.0 release.
If you have an interest in using this parser please lend a hand in
testing it out and making suggestions.
A recap of the
Looks like interesting stuff Mark, but why did you make everything so
configurable (syntax-wise)? IMO, there is a lot of value to
standards, and doing things like changing the precedence of operators
isn't necessarily a good thing :-)
I made it so configurable because I needed to implement a
On 12/5/06, Mark Miller <[EMAIL PROTECTED]> wrote:
I have finally delved back into the Lucene Query parser that I started a
few months back.
Looks like interesting stuff Mark, but why did you make everything so
configurable (syntax-wise)? IMO, there is a lot of value to
standards, and doing th
Hey Laurent,
I am actually pretty much ready for a beta/preview release right about
now. All of the features are in and I am pretty happy with most of the
work. Over the past month I have been squashing bugs and could certainly
use as much help as I can get making sure this thing is as perfect
Hi Mark
As said in a previous mail, I'm very interested in your Parser and I'm
happy to hear you made progress , and implemented
Paragraph/Sentence proximity search functionality. :)
This is the killer feature for me!
and if the execution of the resulting query ( a mix containing
SpanQuery 's
I have finally delved back into the Lucene Query parser that I started a
few months back. I am very closing to wrapping up it's initial
development. I am currently looking for anybody willing to help me out
with a little testing and maybe some design consultation (I am not happy
with the curren
25 matches
Mail list logo
