Mikhail, Thank you for confirming this , however Ahmet's proposal seems more simpler to implement to me .
On Wed, Dec 10, 2014 at 5:07 AM, Mikhail Khludnev < mkhlud...@griddynamics.com> wrote: > > S.L, > > I briefly skimmed Lucene50NormsConsumer.writeNormsField(), my conclusion > is: if you supply own similarity, which just avoids putting float to byte > in Similarity.computeNorm(FieldInvertState), you get right this value in . > Similarity.decodeNormValue(long). > You may wonder but this is what's exactly done in PreciseDefaultSimilarity > in TestLongNormValueSource. I think you can just use it. > > On Wed, Dec 10, 2014 at 12:11 PM, S.L <simpleliving...@gmail.com> wrote: > > > Hi Ahmet, > > > > Is there already an implementation of the suggested work around ? Thanks. > > > > On Tue, Dec 9, 2014 at 6:41 AM, Ahmet Arslan <iori...@yahoo.com.invalid> > > wrote: > > > > > Hi, > > > > > > Default length norm is not best option for differentiating very short > > > documents, like product names. > > > Please see : > > > http://find.searchhub.org/document/b3f776512ab640ec#b3f776512ab640ec > > > > > > I suggest you to create an additional integer field, that holds number > of > > > tokens. You can populate it via update processor. And then penalise > > (using > > > fuction queries) according to that field. This way you have more fine > > > grained and flexible control over it. > > > > > > Ahmet > > > > > > > > > > > > On Tuesday, December 9, 2014 12: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> >
