[jira] [Commented] (LUCENE-8012) Improve Explanation class

2018-01-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308084#comment-16308084
 ] 

ASF subversion and git services commented on LUCENE-8012:
-

Commit a56cb42fde41422c99108ff2749c29080bb94e36 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a56cb42 ]

LUCENE-8012: LTR contrib needs to use float values in explanations


> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Fix For: master (8.0)
>
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2018-01-02 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307887#comment-16307887
 ] 

ASF subversion and git services commented on LUCENE-8012:
-

Commit c1030eeb74e7d5ef6dc36173add6e9da5da645fe in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1030ee ]

LUCENE-8012: Explanation takes Number rather than float


> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Fix For: master (8.0)
>
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2018-01-02 Thread Adrien Grand (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307831#comment-16307831
 ] 

Adrien Grand commented on LUCENE-8012:
--

I'm +1 on merging, this is good progress already. We can deal with making 
CheckHits/CheckExplanations more picky in follow-up issues.

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Attachments: LUCENE-8012.patch, LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2017-12-13 Thread Adrien Grand (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289510#comment-16289510
 ] 

Adrien Grand commented on LUCENE-8012:
--

I like the change! Some suggestions:
 - Maybe require that the value is non null in Explanation.match?
 - In tests, we should probably either use the Number directly for the 
comparision whenever possible, or when it is not convenient at least use the 
doubleValue() in order to make sure that the explanation returned exactly the 
same score and not a double that rounds to the same float as the score?
 - We should review all implementations of DoubleValuesSource.explain to make 
sure they return a Double and not a Float. For instance ConstantValuesSource 
still casts its value to a float.


> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
> Attachments: LUCENE-8012.patch
>
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2017-12-13 Thread Robert Muir (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289225#comment-16289225
 ] 

Robert Muir commented on LUCENE-8012:
-

 {quote}
Changing .getValue() to return a Number is a pretty invasive change though. 
{quote}

I don't think it is. I tried it out and it seems fine. Its what we need to do.

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2017-12-13 Thread Alan Woodward (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288985#comment-16288985
 ] 

Alan Woodward commented on LUCENE-8012:
---

There are a couple of options here.  Just changing Explanation to internally 
hold a Number, but keeping .getValue() signed as a float improves the String 
representation but doesn't really help with precision loss in internal 
calculations.  Changing .getValue() to return a Number is a pretty invasive 
change though.  Another option would be to add an addition .getNumberValue() 
method, which would allow Sims, etc, to ask for their required precision.

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>  Labels: newdev
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (LUCENE-8012) Improve Explanation class

2017-10-25 Thread Alan Woodward (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218331#comment-16218331
 ] 

Alan Woodward commented on LUCENE-8012:
---

+1 to take Number.  I tried converting things to use doubles as a followup to 
LUCENE-7741, but this then complicated things in the various Similarity 
implementations that use Explanation as a way of passing internal values 
around.  Using Number should tidy that up nicely.

> Improve Explanation class
> -
>
> Key: LUCENE-8012
> URL: https://issues.apache.org/jira/browse/LUCENE-8012
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>
> Explanation class is currently nice and simple, and float matches the scoring 
> api, but this does not work well for debugging numerical errors of internal 
> calculations (it usually makes practical sense to use 64-bit double to avoid 
> issues).
> Also it makes for nasty formatting of integral values such as number of 
> tokens in the collection or even document's length, its just noise to see 
> {{10.0}} there instead of {{10}}, and scientific notation for e.g. number of 
> documents is just annoying. 
> One idea is to take Number instead of float? Then you could pass in the 
> correct numeric type (int,long,double,float) for internal calculations, 
> parameters, statistics, etc, and output would look nice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org