I wonder why your explains are so brief, mine looks like <str> 0.4500489 = (MATCH) weight(text:inc in 17) [DefaultSimilarity], result of: 0.4500489 = fieldWeight in 17, product of: 1.0 = tf(freq=1.0), with freq of: 1.0 = termFreq=1.0 2.880313 = idf(docFreq=8, maxDocs=59) 0.15625 = fieldNorm(doc=17)</str> <str> 0.4500489 = (MATCH) weight(text:inc in 27) [DefaultSimilarity], result of: 0.4500489 = fieldWeight in 27, product of: 1.0 = tf(freq=1.0), with freq of: 1.0 = termFreq=1.0 2.880313 = idf(docFreq=8, maxDocs=59) 0.15625 = fieldNorm(doc=27)</str>
here we can see fieldNorm factors. These two docs are rather different, however norm factors are equal. > Also I am not exactly clear on what needs to be looked in the API ? Because you can see how exactly how it looses precision when stores float field norm in the byte. On Tue, Dec 9, 2014 at 1:22 PM, S.L <simpleliving...@gmail.com> wrote: > Hi , > > Mikhail Thanks , I looked at the explain and this is what I see for the two > different documents in questions, they have identical scores even though > the document 2 has a shorter productName field, I do not see any lenghtNorm > related information in the explain. > > Also I am not exactly clear on what needs to be looked in the API ? > > *Search Query* : q=iphone+4s+16gb&qf= productName&mm=1&pf= > productName&ps=1&pf2= productName&pf3= > productName&stopwords=true&lowercaseOperators=true > > *productName Details about Apple iPhone 4s 16GB Smartphone AT&T Factory > Unlocked * > > > - *100%* 10.649221 sum of the following: > - *10.58%* 1.1270299 sum of the following: > - *2.1%* 0.22383358 productName:iphon > - *3.47%* 0.36922288 productName:"4 s" > - *5.01%* 0.53397346 productName:"16 gb" > - *30.81%* 3.2814684 productName:"iphon 4 s 16 gb"~1 > - *27.79%* 2.959255 sum of the following: > - *10.97%* 1.1680154 productName:"iphon 4 s"~1 > - *16.82%* 1.7912396 productName:"4 s 16 gb"~1 > - *30.81%* 3.2814684 productName:"iphon 4 s 16 gb"~1 > > > *productName Apple iPhone 4S 16GB for Net10, No Contract, White* > > > - *100%* 10.649221 sum of the following: > - *10.58%* 1.1270299 sum of the following: > - *2.1%* 0.22383358 productName:iphon > - *3.47%* 0.36922288 productName:"4 s" > - *5.01%* 0.53397346 productName:"16 gb" > - *30.81%* 3.2814684 productName:"iphon 4 s 16 gb"~1 > - *27.79%* 2.959255 sum of the following: > - *10.97%* 1.1680154 productName:"iphon 4 s"~1 > - *16.82%* 1.7912396 productName:"4 s 16 gb"~1 > - *30.81%* 3.2814684 productName:"iphon 4 s 16 gb"~1 > > > > > On Mon, Dec 8, 2014 at 10:25 AM, Mikhail Khludnev < > mkhlud...@griddynamics.com> wrote: > > > It's worth to look into <explain> to check particular scoring values. But > > for most suspect is the reducing precision when float norms are stored in > > byte vals. See javadoc for DefaultSimilarity.encodeNormValue(float) > > > > > > On Mon, Dec 8, 2014 at 5:49 PM, S.L <simpleliving...@gmail.com> wrote: > > > > > I have two documents doc1 and doc2 and each one of those has a field > > called > > > phoneName. > > > > > > doc1:phoneName:"Details about Apple iPhone 4s - 16GB - White (Verizon) > > > Smartphone Factory Unlocked" > > > > > > doc2:phoneName:"Apple iPhone 4S 16GB for Net10, No Contract, White" > > > > > > Here if I search for > > > > > > > > > q=iphone+4s+16gb&qf=phoneName&mm=1&pf=phoneName&ps=1&pf2=phoneName&pf3=phoneName&stopwords=true&lowercaseOperators=true > > > > > > Doc1 and Doc2 both have the same identical score , but since the field > > > phoneName in the doc2 has shorter length I would expect it to have a > > higher > > > score , but both have an identical score of 9.961212. > > > > > > The phoneName filed is defined as follows.As we can see no where am I > > > specifying omitNorms=True, still the behavior seems to be that the > length > > > norm is not functioning at all. Can some one let me know whats the > issue > > > here ? > > > > > > <field name="phoneName" type="text_en_splitting" indexed="true" > > > stored="true" required="true" /> > > > <fieldType name="text_en_splitting" class="solr.TextField" > > > positionIncrementGap="100" > autoGeneratePhraseQueries="true"> > > > <analyzer type="index"> > > > <tokenizer class="solr.WhitespaceTokenizerFactory" /> > > > <!-- in this example, we will only use synonyms at > query > > > time <filter > > > class="solr.SynonymFilterFactory" > > > synonyms="index_synonyms.txt" ignoreCase="true" > > > expand="false"/> --> > > > <!-- Case insensitive stop word removal. add > > > enablePositionIncrements=true > > > in both the index and query analyzers to leave a > > 'gap' > > > for more accurate > > > phrase queries. --> > > > <filter class="solr.StopFilterFactory" > ignoreCase="true" > > > words="lang/stopwords_en.txt" > > > enablePositionIncrements="true" /> > > > <filter class="solr.WordDelimiterFilterFactory" > > > generateWordParts="1" generateNumberParts="1" > > > catenateWords="1" > > > catenateNumbers="1" catenateAll="0" > > > splitOnCaseChange="1" /> > > > <filter class="solr.LowerCaseFilterFactory" /> > > > <filter class="solr.KeywordMarkerFilterFactory" > > > protected="protwords.txt" /> > > > <filter class="solr.PorterStemFilterFactory" /> > > > </analyzer> > > > <analyzer type="query"> > > > <tokenizer class="solr.WhitespaceTokenizerFactory" /> > > > <filter class="solr.SynonymFilterFactory" > > > synonyms="synonyms.txt" > > > ignoreCase="true" expand="true" /> > > > <filter class="solr.StopFilterFactory" > ignoreCase="true" > > > words="lang/stopwords_en.txt" > > > enablePositionIncrements="true" /> > > > <filter class="solr.WordDelimiterFilterFactory" > > > generateWordParts="1" generateNumberParts="1" > > > catenateWords="0" > > > catenateNumbers="0" catenateAll="0" > > > splitOnCaseChange="1" /> > > > <filter class="solr.LowerCaseFilterFactory" /> > > > <filter class="solr.KeywordMarkerFilterFactory" > > > protected="protwords.txt" /> > > > <filter class="solr.PorterStemFilterFactory" /> > > > </analyzer> > > > </fieldType> > > > > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > > Principal Engineer, > > Grid Dynamics > > > > <http://www.griddynamics.com> > > <mkhlud...@griddynamics.com> > > > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>