honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Uppercasing some docs section title (#37781) 

Section titles are mostly uppercase, only a few cases where query DSL parameters
or Java method names are used as the title they should be lowercased.
This commit is contained in:
Christoph Büscher 2019-01-24 22:54:55 +01:00 committed by GitHub
parent e1d8df4ffa
commit 967de04257
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/community-clients/index.asciidoc
View File

@ -131,7 +131,7 @@ The following project appears to be abandoned:
Node.js client for the Elasticsearch REST API Node.js client for the Elasticsearch REST API
[[kotlin]] [[kotlin]]
== kotlin == Kotlin
* https://github.com/mbuhot/eskotlin[ES Kotlin]: * https://github.com/mbuhot/eskotlin[ES Kotlin]:
Elasticsearch Query DSL for kotlin based on the {client}/java-api/current/index.html[official Elasticsearch Java client]. Elasticsearch Query DSL for kotlin based on the {client}/java-api/current/index.html[official Elasticsearch Java client].

6
docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc
View File

@ -337,7 +337,7 @@ The JLH score can be used as a significance score by adding the parameter
The scores are derived from the doc frequencies in _foreground_ and _background_ sets. The _absolute_ change in popularity (foregroundPercent - backgroundPercent) would favor common terms whereas the _relative_ change in popularity (foregroundPercent/ backgroundPercent) would favor rare terms. Rare vs common is essentially a precision vs recall balance and so the absolute and relative changes are multiplied to provide a sweet spot between precision and recall. The scores are derived from the doc frequencies in _foreground_ and _background_ sets. The _absolute_ change in popularity (foregroundPercent - backgroundPercent) would favor common terms whereas the _relative_ change in popularity (foregroundPercent/ backgroundPercent) would favor rare terms. Rare vs common is essentially a precision vs recall balance and so the absolute and relative changes are multiplied to provide a sweet spot between precision and recall.
===== mutual information ===== Mutual information
Mutual information as described in "Information Retrieval", Manning et al., Chapter 13.5.1 can be used as significance score by adding the parameter Mutual information as described in "Information Retrieval", Manning et al., Chapter 13.5.1 can be used as significance score by adding the parameter
[source,js] [source,js]
@ -373,7 +373,7 @@ Chi square as described in "Information Retrieval", Manning et al., Chapter 13.5
Chi square behaves like mutual information and can be configured with the same parameters `include_negatives` and `background_is_superset`. Chi square behaves like mutual information and can be configured with the same parameters `include_negatives` and `background_is_superset`.
===== google normalized distance ===== Google normalized distance
Google normalized distance as described in "The Google Similarity Distance", Cilibrasi and Vitanyi, 2007 (http://arxiv.org/pdf/cs/0412098v3.pdf) can be used as significance score by adding the parameter Google normalized distance as described in "The Google Similarity Distance", Cilibrasi and Vitanyi, 2007 (http://arxiv.org/pdf/cs/0412098v3.pdf) can be used as significance score by adding the parameter
[source,js] [source,js]
@ -412,7 +412,7 @@ It is hard to say which one of the different heuristics will be the best choice
If none of the above measures suits your usecase than another option is to implement a custom significance measure: If none of the above measures suits your usecase than another option is to implement a custom significance measure:
===== scripted ===== Scripted
Customized scores can be implemented via a script: Customized scores can be implemented via a script:
[source,js] [source,js]

4
docs/reference/migration/migrate_7_0/mappings.asciidoc
View File

@ -67,8 +67,8 @@ should also be changed in the template to explicitly define `tree` to one of `ge
or `quadtree`. This will ensure compatibility with previously created indexes. or `quadtree`. This will ensure compatibility with previously created indexes.
[float] [float]
==== deprecated `geo_shape` parameters ==== Deprecated `geo_shape` parameters
The following type parameters are deprecated for the `geo_shape` field type: `tree`, The following type parameters are deprecated for the `geo_shape` field type: `tree`,
`precision`, `tree_levels`, `distance_error_pct`, `points_only`, and `strategy`. They `precision`, `tree_levels`, `distance_error_pct`, `points_only`, and `strategy`. They
will be removed in a future version. will be removed in a future version.

4
docs/reference/testing/testing-framework.asciidoc
View File

@ -8,7 +8,7 @@ Testing is a crucial part of your application, and as information retrieval itse
[[why-randomized-testing]] [[why-randomized-testing]]
=== why randomized testing? === Why randomized testing?
The key concept of randomized testing is not to use the same input values for every testcase, but still be able to reproduce it in case of a failure. This allows to test with vastly different input variables in order to make sure, that your implementation is actually independent from your provided test data. The key concept of randomized testing is not to use the same input values for every testcase, but still be able to reproduce it in case of a failure. This allows to test with vastly different input variables in order to make sure, that your implementation is actually independent from your provided test data.
@ -48,7 +48,7 @@ We provide a few classes that you can inherit from in your own test classes whic
[[unit-tests]] [[unit-tests]]
=== unit tests === Unit tests
If your test is a well isolated unit test which doesn't need a running Elasticsearch cluster, you can use the `ESTestCase`. If you are testing lucene features, use `ESTestCase` and if you are testing concrete token streams, use the `ESTokenStreamTestCase` class. Those specific classes execute additional checks which ensure that no resources leaks are happening, after the test has run. If your test is a well isolated unit test which doesn't need a running Elasticsearch cluster, you can use the `ESTestCase`. If you are testing lucene features, use `ESTestCase` and if you are testing concrete token streams, use the `ESTokenStreamTestCase` class. Those specific classes execute additional checks which ensure that no resources leaks are happening, after the test has run.