scripting.asciidoc 24 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691
  1. [[modules-scripting]]
  2. == Scripting
  3. The scripting module enables you to use scripts to evaluate custom
  4. expressions. For example, you could use a script to return "script fields"
  5. as part of a search request or evaluate a custom score for a query.
  6. TIP: Elasticsearch now has a built-in scripting language called _Painless_
  7. that provides a more secure alternative for implementing
  8. scripts for Elasticsearch. We encourage you to try it out--
  9. for more information, see <<modules-scripting-painless, Painless Scripting Language>>.
  10. The default scripting language is http://groovy-lang.org/[groovy]
  11. (http://mvel.codehaus.org/[mvel] was the default in 1.3.x and earlier).
  12. Additional `lang` plugins enable you to run scripts written in other languages.
  13. Everywhere a script can be used, you can include a `lang` parameter
  14. to specify the language of the script. Plugins are available for following languages:
  15. [cols="<,<,<",options="header",]
  16. |=======================================================================
  17. |Language |Sandboxed |Required plugin
  18. |groovy |no |built-in
  19. |expression |yes |built-in
  20. |mustache |yes |built-in
  21. /painless /yes /built-in (module)
  22. |javascript |no |{plugins}/lang-javascript.html[elasticsearch-lang-javascript]
  23. |python |no |{plugins}/lang-python.html[elasticsearch-lang-python]
  24. |=======================================================================
  25. .Groovy dynamic scripting off by default from v1.4.3
  26. [IMPORTANT]
  27. ===================================================
  28. Groovy dynamic scripting is off by default. This prevents Groovy scripts
  29. from being accepted as part of a request or retrieved from the
  30. `.scripts` index. You can still use Groovy file scripts stored in
  31. the `config/scripts/` directory on every node.
  32. To convert an inline script to a file-based script, save the contents
  33. of the `inline` field to a file with the `.groovy` extension and
  34. store it in the `config/scripts` directory on every data node in your
  35. cluster.
  36. For example, if you have the following inline script:
  37. [source,js]
  38. -----------------------------------
  39. GET /_search
  40. {
  41. "script_fields": {
  42. "my_field": {
  43. "inline": "1 + my_var",
  44. "params": {
  45. "my_var": 2
  46. }
  47. }
  48. }
  49. }
  50. -----------------------------------
  51. Save `1 + my_var` in a file called `config/scripts/my_script.groovy`.
  52. To use the script in a request, specify its name (without the `.groovy` extension) in the `file` field:
  53. [source,js]
  54. -----------------------------------
  55. GET /_search
  56. {
  57. "script_fields": {
  58. "my_field": {
  59. "script": {
  60. "file": "my_script",
  61. "params": {
  62. "my_var": 2
  63. }
  64. }
  65. }
  66. }
  67. }
  68. -----------------------------------
  69. ===================================================
  70. [float]
  71. === File-based Scripts
  72. To increase security, Elasticsearch does not allow you to specify scripts for
  73. non-sandboxed languages with a request. Instead, scripts must be placed in the
  74. `scripts` directory inside the configuration directory (the directory where
  75. elasticsearch.yml is). The default location of this `scripts` directory can be
  76. changed by setting `path.scripts` in elasticsearch.yml. Scripts placed into
  77. this directory will automatically be picked up and be available to be used.
  78. Once a script has been placed in this directory, it can be referenced by name.
  79. For example, a script called `calculate-score.groovy` can be referenced in a
  80. request like this:
  81. [source,sh]
  82. --------------------------------------------------
  83. $ tree config
  84. config
  85. ├── elasticsearch.yml
  86. ├── logging.yml
  87. └── scripts
  88. └── calculate-score.groovy
  89. --------------------------------------------------
  90. [source,sh]
  91. --------------------------------------------------
  92. $ cat config/scripts/calculate-score.groovy
  93. log(_score * 2) + my_modifier
  94. --------------------------------------------------
  95. [source,js]
  96. --------------------------------------------------
  97. curl -XPOST localhost:9200/_search -d '{
  98. "query": {
  99. "function_score": {
  100. "query": {
  101. "match": {
  102. "body": "foo"
  103. }
  104. },
  105. "functions": [
  106. {
  107. "script_score": {
  108. "script": {
  109. "lang": "groovy",
  110. "file": "calculate-score",
  111. "params": {
  112. "my_modifier": 8
  113. }
  114. }
  115. }
  116. }
  117. ]
  118. }
  119. }
  120. }'
  121. --------------------------------------------------
  122. The name of the script is derived from the hierarchy of directories it
  123. exists under, and the file name without the lang extension. For example,
  124. a script placed under `config/scripts/group1/group2/test.py` will be
  125. named `group1_group2_test`.
  126. [float]
  127. === Indexed Scripts
  128. Elasticsearch allows you to store scripts in an internal index known as
  129. `.scripts` and reference them by id. There are REST endpoints to manage
  130. indexed scripts as follows:
  131. Requests to the scripts endpoint look like :
  132. [source,js]
  133. -----------------------------------
  134. /_scripts/{lang}/{id}
  135. -----------------------------------
  136. Where the `lang` part is the language the script is in and the `id` part is the id
  137. of the script. In the `.scripts` index the type of the document will be set to the `lang`.
  138. [source,js]
  139. -----------------------------------
  140. curl -XPOST localhost:9200/_scripts/groovy/indexedCalculateScore -d '{
  141. "script": "log(_score * 2) + my_modifier"
  142. }'
  143. -----------------------------------
  144. This will create a document with id: `indexedCalculateScore` and type: `groovy` in the
  145. `.scripts` index. The type of the document is the language used by the script.
  146. This script can be accessed at query time by using the `id` script parameter and passing
  147. the script id:
  148. [source,js]
  149. --------------------------------------------------
  150. curl -XPOST localhost:9200/_search -d '{
  151. "query": {
  152. "function_score": {
  153. "query": {
  154. "match": {
  155. "body": "foo"
  156. }
  157. },
  158. "functions": [
  159. {
  160. "script_score": {
  161. "script": {
  162. "id": "indexedCalculateScore",
  163. "lang" : "groovy",
  164. "params": {
  165. "my_modifier": 8
  166. }
  167. }
  168. }
  169. }
  170. ]
  171. }
  172. }
  173. }'
  174. --------------------------------------------------
  175. The script can be viewed by:
  176. [source,js]
  177. -----------------------------------
  178. curl -XGET localhost:9200/_scripts/groovy/indexedCalculateScore
  179. -----------------------------------
  180. This is rendered as:
  181. [source,js]
  182. -----------------------------------
  183. '{
  184. "script": "log(_score * 2) + my_modifier"
  185. }'
  186. -----------------------------------
  187. Indexed scripts can be deleted by:
  188. [source,js]
  189. -----------------------------------
  190. curl -XDELETE localhost:9200/_scripts/groovy/indexedCalculateScore
  191. -----------------------------------
  192. [float]
  193. [[enable-dynamic-scripting]]
  194. === Enabling dynamic scripting
  195. We recommend running Elasticsearch behind an application or proxy, which
  196. protects Elasticsearch from the outside world. If users are allowed to run
  197. inline scripts (even in a search request) or indexed scripts, then they have
  198. the same access to your box as the user that Elasticsearch is running as. For
  199. this reason dynamic scripting is allowed only for sandboxed languages by default.
  200. First, you should not run Elasticsearch as the `root` user, as this would allow
  201. a script to access or do *anything* on your server, without limitations. Second,
  202. you should not expose Elasticsearch directly to users, but instead have a proxy
  203. application inbetween. If you *do* intend to expose Elasticsearch directly to
  204. your users, then you have to decide whether you trust them enough to run scripts
  205. on your box or not.
  206. It is possible to enable scripts based on their source, for
  207. every script engine, through the following settings that need to be added to the
  208. `config/elasticsearch.yml` file on every node.
  209. [source,yaml]
  210. -----------------------------------
  211. script.inline: true
  212. script.indexed: true
  213. -----------------------------------
  214. While this still allows execution of named scripts provided in the config, or
  215. _native_ Java scripts registered through plugins, it also allows users to run
  216. arbitrary scripts via the API. Instead of sending the name of the file as the
  217. script, the body of the script can be sent instead or retrieved from the
  218. `.scripts` indexed if previously stored.
  219. There are three possible configuration values for any of the fine-grained
  220. script settings:
  221. [cols="<,<",options="header",]
  222. |=======================================================================
  223. |Value |Description
  224. | `false` |scripting is turned off completely, in the context of the setting being set.
  225. | `true` |scripting is turned on, in the context of the setting being set.
  226. | `sandbox` |scripts may be executed only for languages that are sandboxed
  227. |=======================================================================
  228. The default values are the following:
  229. [source,yaml]
  230. -----------------------------------
  231. script.inline: sandbox
  232. script.indexed: sandbox
  233. script.file: true
  234. -----------------------------------
  235. NOTE: Global scripting settings affect the `mustache` scripting language.
  236. <<search-template,Search templates>> internally use the `mustache` language,
  237. and will still be enabled by default as the `mustache` engine is sandboxed,
  238. but they will be enabled/disabled according to fine-grained settings
  239. specified in `elasticsearch.yml`.
  240. It is also possible to control which operations can execute scripts. The
  241. supported operations are:
  242. [cols="<,<",options="header",]
  243. |=======================================================================
  244. |Value |Description
  245. | `aggs` |Aggregations (wherever they may be used)
  246. | `search` |Search api, Percolator api and Suggester api (e.g filters, script_fields)
  247. | `update` |Update api
  248. | `plugin` |Any plugin that makes use of scripts under the generic `plugin` category
  249. |=======================================================================
  250. Plugins can also define custom operations that they use scripts for instead
  251. of using the generic `plugin` category. Those operations can be referred to
  252. in the following form: `${pluginName}_${operation}`.
  253. The following example disables scripting for `update` and `mapping` operations,
  254. regardless of the script source, for any engine. Scripts can still be
  255. executed from sandboxed languages as part of `aggregations`, `search`
  256. and plugins execution though, as the above defaults still get applied.
  257. [source,yaml]
  258. -----------------------------------
  259. script.update: false
  260. script.mapping: false
  261. -----------------------------------
  262. Generic settings get applied in order, operation based ones have precedence
  263. over source based ones. Language specific settings are supported too. They
  264. need to be prefixed with the `script.engine.<engine>` prefix and have
  265. precedence over any other generic settings.
  266. [source,yaml]
  267. -----------------------------------
  268. script.engine.groovy.file.aggs: true
  269. script.engine.groovy.file.mapping: true
  270. script.engine.groovy.file.search: true
  271. script.engine.groovy.file.update: true
  272. script.engine.groovy.file.plugin: true
  273. script.engine.groovy.indexed.aggs: true
  274. script.engine.groovy.indexed.mapping: false
  275. script.engine.groovy.indexed.search: true
  276. script.engine.groovy.indexed.update: false
  277. script.engine.groovy.indexed.plugin: false
  278. script.engine.groovy.inline.aggs: true
  279. script.engine.groovy.inline.mapping: false
  280. script.engine.groovy.inline.search: false
  281. script.engine.groovy.inline.update: false
  282. script.engine.groovy.inline.plugin: false
  283. -----------------------------------
  284. [float]
  285. === Default Scripting Language
  286. The default scripting language (assuming no `lang` parameter is provided) is
  287. `groovy`. In order to change it, set the `script.default_lang` to the
  288. appropriate language.
  289. [float]
  290. === Automatic Script Reloading
  291. The `config/scripts` directory is scanned periodically for changes.
  292. New and changed scripts are reloaded and deleted script are removed
  293. from preloaded scripts cache. The reload frequency can be specified
  294. using `resource.reload.interval` setting, which defaults to `60s`.
  295. To disable script reloading completely set `script.auto_reload_enabled`
  296. to `false`.
  297. [[native-java-scripts]]
  298. [float]
  299. === Native (Java) Scripts
  300. Sometimes `groovy` and `expressions` aren't enough. For those times you can
  301. implement a native script.
  302. The best way to implement a native script is to write a plugin and install it.
  303. The plugin {plugins}/plugin-authors.html[documentation] has more information on
  304. how to write a plugin so that Elasticsearch will properly load it.
  305. To register the actual script you'll need to implement `NativeScriptFactory`
  306. to construct the script. The actual script will extend either
  307. `AbstractExecutableScript` or `AbstractSearchScript`. The second one is likely
  308. the most useful and has several helpful subclasses you can extend like
  309. `AbstractLongSearchScript`, `AbstractDoubleSearchScript`, and
  310. `AbstractFloatSearchScript`. Finally, your plugin should register the native
  311. script by declaring the `onModule(ScriptModule)` method.
  312. If you squashed the whole thing into one class it'd look like:
  313. [source,java]
  314. --------------------------------------------------
  315. public class MyNativeScriptPlugin extends Plugin {
  316. @Override
  317. public String name() {
  318. return "my-native-script";
  319. }
  320. @Override
  321. public String description() {
  322. return "my native script that does something great";
  323. }
  324. public void onModule(ScriptModule scriptModule) {
  325. scriptModule.registerScript("my_script", MyNativeScriptFactory.class);
  326. }
  327. public static class MyNativeScriptFactory implements NativeScriptFactory {
  328. @Override
  329. public ExecutableScript newScript(@Nullable Map<String, Object> params) {
  330. return new MyNativeScript();
  331. }
  332. @Override
  333. public boolean needsScores() {
  334. return false;
  335. }
  336. }
  337. public static class MyNativeScript extends AbstractFloatSearchScript {
  338. @Override
  339. public float runAsFloat() {
  340. float a = (float) source().get("a");
  341. float b = (float) source().get("b");
  342. return a * b;
  343. }
  344. }
  345. }
  346. --------------------------------------------------
  347. You can execute the script by specifying its `lang` as `native`, and the name
  348. of the script as the `id`:
  349. [source,js]
  350. --------------------------------------------------
  351. curl -XPOST localhost:9200/_search -d '{
  352. "query": {
  353. "function_score": {
  354. "query": {
  355. "match": {
  356. "body": "foo"
  357. }
  358. },
  359. "functions": [
  360. {
  361. "script_score": {
  362. "script": {
  363. "id": "my_script",
  364. "lang" : "native"
  365. }
  366. }
  367. }
  368. ]
  369. }
  370. }
  371. }'
  372. --------------------------------------------------
  373. [float]
  374. === Lucene Expressions Scripts
  375. experimental[The Lucene expressions module is undergoing significant development and the exposed functionality is likely to change in the future]
  376. Lucene's expressions module provides a mechanism to compile a
  377. `javascript` expression to bytecode. This allows very fast execution,
  378. as if you had written a `native` script. Expression scripts can be
  379. used in `script_score`, `script_fields`, sort scripts and numeric aggregation scripts.
  380. See the link:http://lucene.apache.org/core/4_9_0/expressions/index.html?org/apache/lucene/expressions/js/package-summary.html[expressions module documentation]
  381. for details on what operators and functions are available.
  382. Variables in `expression` scripts are available to access:
  383. * Single valued document fields, e.g. `doc['myfield'].value`
  384. * Single valued document fields can also be accessed without `.value` e.g. `doc['myfield']`
  385. * Parameters passed into the script, e.g. `mymodifier`
  386. * The current document's score, `_score` (only available when used in a `script_score`)
  387. Variables in `expression` scripts that are of type `date` may use the following member methods:
  388. * getYear()
  389. * getMonth()
  390. * getDayOfMonth()
  391. * getHourOfDay()
  392. * getMinutes()
  393. * getSeconds()
  394. The following example shows the difference in years between the `date` fields date0 and date1:
  395. `doc['date1'].getYear() - doc['date0'].getYear()`
  396. There are a few limitations relative to other script languages:
  397. * Only numeric fields may be accessed
  398. * Stored fields are not available
  399. * If a field is sparse (only some documents contain a value), documents missing the field will have a value of `0`
  400. [float]
  401. === Score
  402. In all scripts that can be used in aggregations, the current
  403. document's score is accessible in `_score`.
  404. [float]
  405. === Computing scores based on terms in scripts
  406. see <<modules-advanced-scripting, advanced scripting documentation>>
  407. [float]
  408. === Document Fields
  409. Most scripting revolve around the use of specific document fields data.
  410. The `doc['field_name']` can be used to access specific field data within
  411. a document (the document in question is usually derived by the context
  412. the script is used). Document fields are very fast to access since they
  413. end up being loaded into memory (all the relevant field values/tokens
  414. are loaded to memory). Note, however, that the `doc[...]` notation only
  415. allows for simple valued fields (can’t return a json object from it)
  416. and makes sense only on non-analyzed or single term based fields.
  417. The following data can be extracted from a field:
  418. [cols="<,<",options="header",]
  419. |=======================================================================
  420. |Expression |Description
  421. |`doc['field_name'].value` |The native value of the field. For example,
  422. if its a short type, it will be short.
  423. |`doc['field_name'].values` |The native array values of the field. For
  424. example, if its a short type, it will be short[]. Remember, a field can
  425. have several values within a single doc. Returns an empty array if the
  426. field has no values.
  427. |`doc['field_name'].empty` |A boolean indicating if the field has no
  428. values within the doc.
  429. |`doc['field_name'].multiValued` |A boolean indicating that the field
  430. has several values within the corpus.
  431. |`doc['field_name'].lat` |The latitude of a geo point type.
  432. |`doc['field_name'].lon` |The longitude of a geo point type.
  433. |`doc['field_name'].lats` |The latitudes of a geo point type.
  434. |`doc['field_name'].lons` |The longitudes of a geo point type.
  435. |`doc['field_name'].distance(lat, lon)` |The `plane` distance (in meters)
  436. of this geo point field from the provided lat/lon.
  437. |`doc['field_name'].distanceWithDefault(lat, lon, default)` |The `plane` distance (in meters)
  438. of this geo point field from the provided lat/lon with a default value.
  439. |`doc['field_name'].distanceInMiles(lat, lon)` |The `plane` distance (in
  440. miles) of this geo point field from the provided lat/lon.
  441. |`doc['field_name'].distanceInMilesWithDefault(lat, lon, default)` |The `plane` distance (in
  442. miles) of this geo point field from the provided lat/lon with a default value.
  443. |`doc['field_name'].distanceInKm(lat, lon)` |The `plane` distance (in
  444. km) of this geo point field from the provided lat/lon.
  445. |`doc['field_name'].distanceInKmWithDefault(lat, lon, default)` |The `plane` distance (in
  446. km) of this geo point field from the provided lat/lon with a default value.
  447. |`doc['field_name'].arcDistance(lat, lon)` |The `arc` distance (in
  448. meters) of this geo point field from the provided lat/lon.
  449. |`doc['field_name'].arcDistanceWithDefault(lat, lon, default)` |The `arc` distance (in
  450. meters) of this geo point field from the provided lat/lon with a default value.
  451. |`doc['field_name'].arcDistanceInMiles(lat, lon)` |The `arc` distance (in
  452. miles) of this geo point field from the provided lat/lon.
  453. |`doc['field_name'].arcDistanceInMilesWithDefault(lat, lon, default)` |The `arc` distance (in
  454. miles) of this geo point field from the provided lat/lon with a default value.
  455. |`doc['field_name'].arcDistanceInKm(lat, lon)` |The `arc` distance (in
  456. km) of this geo point field from the provided lat/lon.
  457. |`doc['field_name'].arcDistanceInKmWithDefault(lat, lon, default)` |The `arc` distance (in
  458. km) of this geo point field from the provided lat/lon with a default value.
  459. |`doc['field_name'].factorDistance(lat, lon)` |The distance factor of this geo point field from the provided lat/lon.
  460. |`doc['field_name'].factorDistance(lat, lon, default)` |The distance factor of this geo point field from the provided lat/lon with a default value.
  461. |`doc['field_name'].geohashDistance(geohash)` |The `arc` distance (in meters)
  462. of this geo point field from the provided geohash.
  463. |`doc['field_name'].geohashDistanceInKm(geohash)` |The `arc` distance (in km)
  464. of this geo point field from the provided geohash.
  465. |`doc['field_name'].geohashDistanceInMiles(geohash)` |The `arc` distance (in
  466. miles) of this geo point field from the provided geohash.
  467. |=======================================================================
  468. [float]
  469. === Stored Fields
  470. Stored fields can also be accessed when executing a script. Note, they
  471. are much slower to access compared with document fields, as they are not
  472. loaded into memory. They can be simply accessed using
  473. `_fields['my_field_name'].value` or `_fields['my_field_name'].values`.
  474. [float]
  475. === Accessing the score of a document within a script
  476. When using scripting for calculating the score of a document (for instance, with
  477. the `function_score` query), you can access the score using the `_score`
  478. variable inside of a Groovy script.
  479. [float]
  480. === Source Field
  481. The source field can also be accessed when executing a script. The
  482. source field is loaded per doc, parsed, and then provided to the script
  483. for evaluation. The `_source` forms the context under which the source
  484. field can be accessed, for example `_source.obj2.obj1.field3`.
  485. Accessing `_source` is much slower compared to using `doc`
  486. but the data is not loaded into memory. For a single field access `_fields` may be
  487. faster than using `_source` due to the extra overhead of potentially parsing large documents.
  488. However, `_source` may be faster if you access multiple fields or if the source has already been
  489. loaded for other purposes.
  490. [float]
  491. === Groovy Built In Functions
  492. There are several built in functions that can be used within scripts.
  493. They include:
  494. [cols="<,<",options="header",]
  495. |=======================================================================
  496. |Function |Description
  497. |`sin(a)` |Returns the trigonometric sine of an angle.
  498. |`cos(a)` |Returns the trigonometric cosine of an angle.
  499. |`tan(a)` |Returns the trigonometric tangent of an angle.
  500. |`asin(a)` |Returns the arc sine of a value.
  501. |`acos(a)` |Returns the arc cosine of a value.
  502. |`atan(a)` |Returns the arc tangent of a value.
  503. |`toRadians(angdeg)` |Converts an angle measured in degrees to an
  504. approximately equivalent angle measured in radians
  505. |`toDegrees(angrad)` |Converts an angle measured in radians to an
  506. approximately equivalent angle measured in degrees.
  507. |`exp(a)` |Returns Euler's number _e_ raised to the power of value.
  508. |`log(a)` |Returns the natural logarithm (base _e_) of a value.
  509. |`log10(a)` |Returns the base 10 logarithm of a value.
  510. |`sqrt(a)` |Returns the correctly rounded positive square root of a
  511. value.
  512. |`cbrt(a)` |Returns the cube root of a double value.
  513. |`IEEEremainder(f1, f2)` |Computes the remainder operation on two
  514. arguments as prescribed by the IEEE 754 standard.
  515. |`ceil(a)` |Returns the smallest (closest to negative infinity) value
  516. that is greater than or equal to the argument and is equal to a
  517. mathematical integer.
  518. |`floor(a)` |Returns the largest (closest to positive infinity) value
  519. that is less than or equal to the argument and is equal to a
  520. mathematical integer.
  521. |`rint(a)` |Returns the value that is closest in value to the argument
  522. and is equal to a mathematical integer.
  523. |`atan2(y, x)` |Returns the angle _theta_ from the conversion of
  524. rectangular coordinates (_x_, _y_) to polar coordinates (r,_theta_).
  525. |`pow(a, b)` |Returns the value of the first argument raised to the
  526. power of the second argument.
  527. |`round(a)` |Returns the closest _int_ to the argument.
  528. |`random()` |Returns a random _double_ value.
  529. |`abs(a)` |Returns the absolute value of a value.
  530. |`max(a, b)` |Returns the greater of two values.
  531. |`min(a, b)` |Returns the smaller of two values.
  532. |`ulp(d)` |Returns the size of an ulp of the argument.
  533. |`signum(d)` |Returns the signum function of the argument.
  534. |`sinh(x)` |Returns the hyperbolic sine of a value.
  535. |`cosh(x)` |Returns the hyperbolic cosine of a value.
  536. |`tanh(x)` |Returns the hyperbolic tangent of a value.
  537. |`hypot(x, y)` |Returns sqrt(_x2_ + _y2_) without intermediate overflow
  538. or underflow.
  539. |=======================================================================