mirror of
https://github.com/johnkerl/miller.git
synced 2026-07-28 18:21:52 +00:00
doc neaten
This commit is contained in:
John Kerl
parent
418ec3d1a9
commit
46fc608d4d
3 changed files with 94 additions and 66 deletions
|
|
@ -6,21 +6,38 @@ POKI_PUT_TOC_HERE
|
|||
<p/>
|
||||
|
||||
The essential usages of <tt>mlr filter</tt> and <tt>mlr put</tt> are for
|
||||
record-selection and record-updating expressions, respectively. For example:
|
||||
record-selection and record-updating expressions, respectively. For example, given the following input data:
|
||||
|
||||
POKI_RUN_COMMAND{{cat data/small}}HERE
|
||||
|
||||
<p/> you might retain only the records whose <tt>a</tt> field has value <tt>eks</tt>:
|
||||
|
||||
POKI_RUN_COMMAND{{mlr filter '$a == "eks"' data/small}}HERE
|
||||
|
||||
<p/> or you might add a new field which is a function of existing fields:
|
||||
|
||||
POKI_RUN_COMMAND{{mlr put '$ab = $a . "_" . $b ' data/small}}HERE
|
||||
|
||||
<p/>The two are essentially the same command. The only differences are:
|
||||
expressions sent to <tt>mlr filter</tt> must end with a boolean expression,
|
||||
which is the filtering criterion; <tt>mlr filter</tt> expressions may not
|
||||
reference the <tt>filter</tt> keyword within them; and <tt>mlr filter</tt>
|
||||
expressions may not use <tt>tee</tt>, <tt>emit</tt>, <tt>emitp</tt>, or
|
||||
<tt>emitf</tt>. All the rest is the same: in particular, you can define and
|
||||
invoke functions and subroutines to help produce the final boolean statement,
|
||||
and record fields may be assigned to in the statements preceding the final
|
||||
boolean statement.
|
||||
<p/>The two verbs <tt>mlr filter</tt> and <tt>mlr put</tt> are essentially the
|
||||
same. The only differences are:
|
||||
|
||||
<ul>
|
||||
|
||||
<li/> Expressions sent to <tt>mlr filter</tt> must end with a boolean expression,
|
||||
which is the filtering criterion;
|
||||
|
||||
<li/> <tt>mlr filter</tt> expressions may not
|
||||
reference the <tt>filter</tt> keyword within them; and
|
||||
|
||||
<li/> <tt>mlr filter</tt> expressions may not use <tt>tee</tt>, <tt>emit</tt>,
|
||||
<tt>emitp</tt>, or <tt>emitf</tt>.
|
||||
|
||||
</ul>
|
||||
|
||||
<p/> All the rest is the same: in particular, you can define and invoke
|
||||
functions and subroutines to help produce the final boolean statement, and
|
||||
record fields may be assigned to in the statements preceding the final boolean
|
||||
statement.
|
||||
|
||||
<p/>There are more details and more choices, of course, as detailed in the following sections.
|
||||
|
||||
|
|
@ -354,8 +371,6 @@ POKI_RUN_COMMAND{{mlr --icsvlite --opprint put '$format_ok = isstring($reachable
|
|||
|
||||
<p/> Or perhaps to flag badly formatted data outside the output stream:
|
||||
|
||||
<p/> xxx need a way to trap stderr within poki
|
||||
|
||||
POKI_RUN_COMMAND{{mlr --icsvlite --opprint put 'if (!isstring($reachable)) {eprint "Malformed at NR=".NR} ' data/het-bool.csv}}HERE
|
||||
|
||||
<p/> A third way is to abort the process on first instance of bad data:
|
||||
|
|
|
|||
|
|
@ -607,33 +607,33 @@ $ mlr --ofmt '%.9lf' --opprint seqgen --start 1 --stop 28 then put '
|
|||
' then put '$seconds=systime()' then step -a delta -f seconds then cut -x -f seconds
|
||||
i o fcount seconds_delta
|
||||
1 1 1 0
|
||||
2 2 3 0.000024796
|
||||
3 3 5 0.000014067
|
||||
4 5 9 0.000015974
|
||||
5 8 15 0.000020981
|
||||
6 13 25 0.000032187
|
||||
7 21 41 0.000045776
|
||||
8 34 67 0.000070095
|
||||
9 55 109 0.000111103
|
||||
2 2 3 0.000028133
|
||||
3 3 5 0.000012875
|
||||
4 5 9 0.000017166
|
||||
5 8 15 0.000022888
|
||||
6 13 25 0.000034094
|
||||
7 21 41 0.000048876
|
||||
8 34 67 0.000074148
|
||||
9 55 109 0.000123024
|
||||
10 89 177 0.000175953
|
||||
11 144 287 0.000279903
|
||||
12 233 465 0.000450134
|
||||
13 377 753 0.000721931
|
||||
14 610 1219 0.001163006
|
||||
15 987 1973 0.001879930
|
||||
16 1597 3193 0.003020048
|
||||
17 2584 5167 0.004924059
|
||||
18 4181 8361 0.007558823
|
||||
19 6765 13529 0.012623072
|
||||
20 10946 21891 0.023110151
|
||||
21 17711 35421 0.031341791
|
||||
22 28657 57313 0.050220013
|
||||
23 46368 92735 0.080469131
|
||||
24 75025 150049 0.134813070
|
||||
25 121393 242785 0.208026886
|
||||
26 196418 392835 0.342816114
|
||||
27 317811 635621 0.565840960
|
||||
28 514229 1028457 0.876019955
|
||||
14 610 1219 0.001160860
|
||||
15 987 1973 0.001880169
|
||||
16 1597 3193 0.003160000
|
||||
17 2584 5167 0.004883051
|
||||
18 4181 8361 0.008115768
|
||||
19 6765 13529 0.012959003
|
||||
20 10946 21891 0.022043228
|
||||
21 17711 35421 0.034470797
|
||||
22 28657 57313 0.055466175
|
||||
23 46368 92735 0.081876993
|
||||
24 75025 150049 0.130389929
|
||||
25 121393 242785 0.221334934
|
||||
26 196418 392835 0.341587067
|
||||
27 317811 635621 0.623054981
|
||||
28 514229 1028457 0.878679037
|
||||
</pre>
|
||||
</div>
|
||||
<p/>
|
||||
|
|
@ -665,33 +665,33 @@ $ mlr --ofmt '%.9lf' --opprint seqgen --start 1 --stop 28 then put '
|
|||
' then put '$seconds=systime()' then step -a delta -f seconds then cut -x -f seconds
|
||||
i o fcount seconds_delta
|
||||
1 1 1 0
|
||||
2 2 3 0.000030041
|
||||
3 3 3 0.000014067
|
||||
2 2 3 0.000028133
|
||||
3 3 3 0.000012875
|
||||
4 5 3 0.000010967
|
||||
5 8 3 0.000010967
|
||||
6 13 3 0.000010967
|
||||
7 21 3 0.000012159
|
||||
8 34 3 0.000009775
|
||||
9 55 3 0.000011206
|
||||
10 89 3 0.000010967
|
||||
11 144 3 0.000010967
|
||||
6 13 3 0.000010014
|
||||
7 21 3 0.000010014
|
||||
8 34 3 0.000010967
|
||||
9 55 3 0.000010014
|
||||
10 89 3 0.000010014
|
||||
11 144 3 0.000010014
|
||||
12 233 3 0.000014067
|
||||
13 377 3 0.000010967
|
||||
14 610 3 0.000010967
|
||||
13 377 3 0.000010014
|
||||
14 610 3 0.000010014
|
||||
15 987 3 0.000010014
|
||||
16 1597 3 0.000010967
|
||||
16 1597 3 0.000010014
|
||||
17 2584 3 0.000010014
|
||||
18 4181 3 0.000010014
|
||||
19 6765 3 0.000010014
|
||||
20 10946 3 0.000010967
|
||||
21 17711 3 0.000010014
|
||||
22 28657 3 0.000011921
|
||||
23 46368 3 0.000013113
|
||||
24 75025 3 0.000010967
|
||||
20 10946 3 0.000010014
|
||||
21 17711 3 0.000011921
|
||||
22 28657 3 0.000010014
|
||||
23 46368 3 0.000011921
|
||||
24 75025 3 0.000010014
|
||||
25 121393 3 0.000010967
|
||||
26 196418 3 0.000010014
|
||||
27 317811 3 0.000010014
|
||||
28 514229 3 0.000010967
|
||||
28 514229 3 0.000010014
|
||||
</pre>
|
||||
</div>
|
||||
<p/>
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ Miller commands were run with pretty-print-tabular output format.
|
|||
<p/>
|
||||
|
||||
The essential usages of <tt>mlr filter</tt> and <tt>mlr put</tt> are for
|
||||
record-selection and record-updating expressions, respectively. For example:
|
||||
record-selection and record-updating expressions, respectively. For example, given the following input data:
|
||||
|
||||
<p/>
|
||||
<div class="pokipanel">
|
||||
|
|
@ -202,6 +202,9 @@ a=wye,b=pan,i=5,x=0.5732889198020006,y=0.8636244699032729
|
|||
</pre>
|
||||
</div>
|
||||
<p/>
|
||||
|
||||
<p/> you might retain only the records whose <tt>a</tt> field has value <tt>eks</tt>:
|
||||
|
||||
<p/>
|
||||
<div class="pokipanel">
|
||||
<pre>
|
||||
|
|
@ -211,6 +214,9 @@ a=eks,b=wye,i=4,x=0.38139939387114097,y=0.13418874328430463
|
|||
</pre>
|
||||
</div>
|
||||
<p/>
|
||||
|
||||
<p/> or you might add a new field which is a function of existing fields:
|
||||
|
||||
<p/>
|
||||
<div class="pokipanel">
|
||||
<pre>
|
||||
|
|
@ -224,15 +230,26 @@ a=wye,b=pan,i=5,x=0.5732889198020006,y=0.8636244699032729,ab=wye_pan
|
|||
</div>
|
||||
<p/>
|
||||
|
||||
<p/>The two are essentially the same command. The only differences are:
|
||||
expressions sent to <tt>mlr filter</tt> must end with a boolean expression,
|
||||
which is the filtering criterion; <tt>mlr filter</tt> expressions may not
|
||||
reference the <tt>filter</tt> keyword within them; and <tt>mlr filter</tt>
|
||||
expressions may not use <tt>tee</tt>, <tt>emit</tt>, <tt>emitp</tt>, or
|
||||
<tt>emitf</tt>. All the rest is the same: in particular, you can define and
|
||||
invoke functions and subroutines to help produce the final boolean statement,
|
||||
and record fields may be assigned to in the statements preceding the final
|
||||
boolean statement.
|
||||
<p/>The two verbs <tt>mlr filter</tt> and <tt>mlr put</tt> are essentially the
|
||||
same. The only differences are:
|
||||
|
||||
<ul>
|
||||
|
||||
<li/> Expressions sent to <tt>mlr filter</tt> must end with a boolean expression,
|
||||
which is the filtering criterion;
|
||||
|
||||
<li/> <tt>mlr filter</tt> expressions may not
|
||||
reference the <tt>filter</tt> keyword within them; and
|
||||
|
||||
<li/> <tt>mlr filter</tt> expressions may not use <tt>tee</tt>, <tt>emit</tt>,
|
||||
<tt>emitp</tt>, or <tt>emitf</tt>.
|
||||
|
||||
</ul>
|
||||
|
||||
<p/> All the rest is the same: in particular, you can define and invoke
|
||||
functions and subroutines to help produce the final boolean statement, and
|
||||
record fields may be assigned to in the statements preceding the final boolean
|
||||
statement.
|
||||
|
||||
<p/>There are more details and more choices, of course, as detailed in the following sections.
|
||||
|
||||
|
|
@ -1025,8 +1042,6 @@ wilma 1 false
|
|||
|
||||
<p/> Or perhaps to flag badly formatted data outside the output stream:
|
||||
|
||||
<p/> xxx need a way to trap stderr within poki
|
||||
|
||||
<p/>
|
||||
<div class="pokipanel">
|
||||
<pre>
|
||||
|
|
@ -1056,8 +1071,6 @@ fred,true
|
|||
</div>
|
||||
<p/>
|
||||
|
||||
<p/> xxx under construction
|
||||
|
||||
<!-- ================================================================ -->
|
||||
<a id="Type-declarations_for_local_variables,_function_parameter,_and_function_return_values"/><h3>Type-declarations for local variables, function parameter, and function return values</h3>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue