From d4ad020ecfd85ed0ad02a710c1fbc09938ac4dc0 Mon Sep 17 00:00:00 2001
From: Bill Zorn <bill.zorn@gmail.com>
Date: Wed, 18 Jul 2018 14:46:14 -0700
Subject: [PATCH 1/5] Draft version of FPBench 1.1 standards. Changes:   *
 Support for multiple and mixed-precision computations   * Semantics of
 numerical operations clarified as rounded real operations   * Precision can
 be specified per-operation using the rounding context   * New constant
 formats, including rational numbers and hexadecimal floating-point   * New
 metadata properties

---
 index.html             |   1 +
 spec/fpcore-1.1.html   | 467 +++++++++++++++++++++++++++++++++++++++++
 spec/index.html        |  22 ++
 spec/measures-1.1.html | 213 +++++++++++++++++++
 spec/metadata-1.1.html | 139 ++++++++++++
 5 files changed, 842 insertions(+)
 create mode 100644 spec/fpcore-1.1.html
 create mode 100644 spec/measures-1.1.html
 create mode 100644 spec/metadata-1.1.html
diff --git a/index.html b/index.html
index 41c7d2d..bf0f4be 100644
--- a/index.html
+++ b/index.html
@@ -31,6 +31,7 @@ <h2>Standards</h2>
       <li><a href="spec/fpcore-1.0.html">FPCore 1.0</a></li>
       <li><a href="spec/metadata-1.0.html">Metadata 1.0</a></li>
       <li><a href="spec/measures-1.0.html">Measures 1.0</a></li>
+      <li><a href="spec/">All versions</a></li>
     </ul>
     <ul>
       <h2>About</h2>
diff --git a/spec/fpcore-1.1.html b/spec/fpcore-1.1.html
new file mode 100644
index 0000000..d7e37a1
--- /dev/null
+++ b/spec/fpcore-1.1.html
@@ -0,0 +1,467 @@
+<!doctype html>
+<html lang="en_US">
+<head>
+  <meta charset="utf-8"/>
+  <title>FPBench FPCore 1.1</title>
+  <link rel="stylesheet" type="text/css" href="../fpbench.css">
+</head>
+<body class="gutter">
+
+<header>
+    <a href='..' style='color: black; text-decoration: none;'>
+      <img src='../img/logo.png' height='150' alt='FPBench Logo' />
+      <h1>FPCore 1.1 (DRAFT VERSION)</h1>
+      <p>A common format for floating-point computations</p>
+    </a>
+</header>
+
+<main>
+<header>
+  <h1>FPBench 1.1 standards</h1>
+
+  <p>
+    <a href="../">FPBench</a> is a standard benchmark suite for the
+    floating-point community. The benchmark suite contains a common format
+    for floating-point computation and metadata and a common set
+    of accuracy measures:
+  </p>
+
+  <ol>
+    <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
+    <li><a href="measures-1.1.html">Standard measures of error</a></li>
+  </ol>
+</header>
+
+<section id="fpcore">
+
+<header>
+  <h2>FPCore benchmark format</h2>
+
+  <p>
+    FPCore is the format used for FPBench benchmarks. It is a simple
+    functional programming language with conditionals and
+    loops. The syntax is an easy-to-parse S-expression syntax.
+  </p>
+</header>
+
+  <figure>
+    <pre><code class="fpcore">(FPCore (x)
+ :name "NMSE example 3.1"
+ :cite (hamming-1987)
+ :pre (>= x 0)
+ (- (sqrt (+ x 1)) (sqrt x)))</code></pre>
+    <caption>An example FPCore program, from the <data value="benchmarks/hamming-ch3.fpcore" class="suite-name">hamming-ch3</data> suite.</caption>
+  </figure>
+
+  <figure>
+    <pre><code class="fpcore">(FPCore (x)
+ :name "round with addition"
+ :spec (round x)
+ (let ([n (! :precision binary64 6755399441055744)])
+   (! :precision binary64 :round nearestEven (- (+ x n) n))))</code></pre>
+    <caption>An example of a precision-specific computation.</caption>
+  </figure>
+
+  <section id="syntax">
+  <h3>Syntax</h3>
+
+  <p>
+    Benchmarks use a simple S-expression syntax
+    with the following grammar.
+  </p>
+
+  <aside>
+    FPCore is modelled on <a href='http://smtlib.cs.uiowa.edu/'>SMT-LIB2</a>,
+    an input format for SMT solvers.
+  </aside>
+
+  <figure>
+    <dl class="grammar">
+      <dt id="g:fpcore">FPCore</dt>
+      <dd>( FPCore (<a href="#g:argument" title="Free variables in benchmark">argument</a>*)
+        <a href="#g:property" title="Metadata properties of the benchmark">property</a>*
+        <a href="#g:expr" title="Benchmark expression">expr</a> )
+      </dd>
+
+      <dt id="g:argument">argument</dt>
+      <dd><a href="#g:symbol" title="Name of free variable">symbol</a></dd>
+      <dd>( ! <a href="#g:property" title="Rounding context for free variable">property</a>* <a href="#g:symbol" title="Name of free variable">symbol</a> )</dd>
+
+      <dt id="g:expr">expr</dt>
+      <dd><a href="#g:number" title="A number">number</a></dd>
+      <dd><a href="#g:constant" title="A mathematical constant">constant</a></dd>
+      <dd><a href="#g:symbol" title="A variable">symbol</a></dd>
+      <dd>( <a href="#g:operation" title="Mathematical operation to perform">operation</a> <a href="#g:expr" title="Inputs to operation">expr</a>+ )</dd>
+      <dd>( if <a href="#g:expr" title="Conditional">expr</a> <a href="#g:expr" title="Branch if condition is true">expr</a> <a href="#g:expr" title="Branch if condition is false">expr</a> )</dd>
+      <dd>( let ( [ <a href="#g:symbol" title="Variable being bound">symbol</a> <a href="#g:expr" title="Value of variable">expr</a> ]* ) <a href="#g:expr" title="Body expression to evaluate with bindings">expr</a> )</dd>
+      <dd>( while <a href="#g:expr" title="Loop condition">expr</a> ( [ <a href="#g:symbol" title="Variable mutated in loop">symbol</a> <a href="#g:expr" title="Initial variable value">expr</a> <a href="#g:expr" title="Update expression for variable">expr</a> ]* ) <a href="#g:expr" title="Body expression to evaluate after loop">expr</a> )</dd>
+      <dd>( cast <a href="#g:expr" title="Expression to round with current rounding context">expr</a> )</dd>
+      <dd>( ! <a href="#g:property" title="Rounding context for expression">property</a>* <a href="#g:expr" title="Expression annotated by rounding context">expr</a> )</dd>
+
+      <dt id="g:number">number</dt>
+      <dd><a href="#g:decnum" title="A decimal number literal">decnum</a></dd>
+      <dd><a href="#g:hexnum" title="A hexadecimal number literal">hexnum</a></dd>
+      <dd><a href="#g:rational" title="A rational number">rational</a></dd>
+      <dd>( digits <a href="#g:decnum" title="Significand">decnum</a> <a href="#g:decnum" title="Exponent">decnum</a> <a href="#g:decnum" title="Base">decnum</a> )</dd>
+
+      <dt id="g:property">property</dt>
+      <dd>:<a href="#g:symbol" title="Property name">symbol</a> <a href="#g:expr" title="Property value given as expression">expr</a></dd>
+      <dd>:<a href="#g:symbol" title="Property name">symbol</a> <a href="#g:string" title="Property value given as string">string</a></dd>
+      <dd>:<a href="#g:symbol" title="Property name">symbol</a> ( <a href="#g:symbol" title="Property value given as list of symbols">symbol</a>* )</dd>
+    </dl>
+    <caption>High-level grammar of FPCore. The tokens <a href="#g:constant">constant</a> and <a href="#g:operation">operation</a>, as well as base tokens like <a href="#g:decnum">decnum</a>, are defined below. </caption>
+  </figure>
+
+  <p>
+    In this grammar, an <a href="#g:fpcore">FPCore</a> term describes
+    a single benchmark, with a set of free variables, a collection of
+    <a href="metadata-1.1.html">metadata properties</a>, and the
+    floating-point expression defining the benchmark. White-space is
+    ignored, and lines starting with the semicolon (<code>;</code>)
+    are treated as comments and ignored. The basic tokens are defined
+    as expected:
+  </p>
+
+  <dl class="code-terms">
+    <dt id="g:symbol">symbol</dt>
+    <dd>Any sequence of letters, digits, or characters from the
+      set <code>~!@$%^&*_-+=<>.?/:</code> not starting with a digit,
+      implemented for ASCII by the regular expression:
+      <pre class="expr"><code>[a-zA-Z~!@$%^&*_\-+=<>.?/:][a-zA-Z0-9~!@$%^&*_\-+=<>.?/:]*</code></pre></dd>
+
+    <dt id="g:decnum">decnum</dt>
+    <dd>An optional plus (<code>+</code>) or minus (<code>-</code>)
+      sign followed by either a sequence of decimal digits which
+      may optionally be followed by a period (<code>.</code>) and another
+      sequence of digits, or by a period and a sequence
+      of digits. This may be followed by an <code>e</code>, an optional plus
+      or minus sign, and a final sequence of digits. This definition is implemented
+      for ASCII by the regular expression:
+      <pre class="expr"><code>[-+]?([0-9]+(\.[0-9]+)?|\.[0-9]+)(e[-+]?[0-9]+)?</code></pre></dd>
+
+    <dt id="g:hexnum">hexnum</dt>
+    <dd>An optional plus (<code>+</code>) or minus (<code>-</code>) sign,
+      followed by the hexadecimal literal identifier <code>0x</code>,
+      all followed by either a sequence of hexadecimal digits (<code>[0-9a-f]</code>) which
+      may optionally be followed by a period (<code>.</code>) and another
+      sequence of hex digits, or by a period and a sequence
+      of hex digits. This may be followed by a <code>p</code>, an optional plus
+      or minus sign, and a sequence of decimal digits. This definition is implemented
+      for ASCII by the following regular expression, which is case-insensitive:
+      <pre class="expr"><code>[+-]?0x([0-9a-f]+(\.[0-9a-f]+)?|\.[0-9a-f]+)(p[-+]?[0-9]+)?</code></pre></dd>
+
+    <dt id="g:rational">rational</dt>
+    <dd>An optional plus (<code>+</code>) or minus (<code>-</code>) sign,
+      followed by a sequence of decimal digits that form the numerator, followed by
+      a slash (<code>/</code>), followed by a nonzero sequence of decimal digits that
+      form the denominator. This definition is implemented for ASCII by the regular expression:
+      <pre class="expr"><code>[+-]?[0-9]+/[0-9]*[1-9][0-9]*</code></pre></dd>
+
+    <dt id="g:string">string</dt>
+    <dd>Any sequence of printable characters, spaces, tabs, or
+      carriage returns, delimited by double quotes
+      (<code>&quot;</code>). Within the double quotes, backslashes
+      (<code>\</code>) have special meaning. A backslash followed by a
+      double quote represents a double quote and does not terminate
+      the string; a backslash followed by a backslash represents a
+      backslash; other escapes may also be supported by
+      implementations, but their meaning is not defined in this
+      standard. We recommend that implementations only use escapes
+      defined in the C or Matlab standard libraries.
+      This definition is implemented for ASCII by the regular expression:
+      <pre class="expr"><code>&quot;([\x20-\x21\x23-\x5b\x5d-\x7e]|\\[&quot;\\])*&quot;</code></pre></dd>
+  </dl>
+  </section>
+
+  <section id="g:operation">
+  <h3>Supported operations</h3>
+
+  <aside>
+    FPCore covers common library functions in C, Fortran, and Matlab.
+  </aside>
+
+  <p>The following operations are supported:</p>
+
+  <table class="code-terms">
+    <colgroup><col><col><col><col><col></colgroup>
+    <thead><th colspan="5">Supported Mathematical Operations</th></thead>
+    <tbody>
+    <tr>
+    <td>+</td><td>-</td><td>*</td><td>/</td><td>fabs</td>
+    </tr><tr>
+    <td>fma</td><td>exp</td><td>exp2</td><td>expm1</td><td>log</td>
+    </tr><tr>
+    <td>log10</td><td>log2</td><td>log1p</td><td>pow</td><td>sqrt</td>
+    </tr><tr>
+    <td>cbrt</td><td>hypot</td><td>sin</td><td>cos</td><td>tan</td>
+    </tr><tr>
+    <td>asin</td><td>acos</td><td>atan</td><td>atan2</td><td>sinh</td>
+    </tr><tr>
+    <td>cosh</td><td>tanh</td><td>asinh</td><td>acosh</td><td>atanh</td>
+    </tr><tr>
+    <td>erf</td><td>erfc</td><td>tgamma</td><td>lgamma</td><td>ceil</td>
+    </tr><tr>
+    <td>floor</td><td>fmod</td><td>remainder</td><td>fmax</td><td>fmin</td>
+    </tr><tr>
+    <td>fdim</td><td>copysign</td><td>trunc</td><td>round</td><td>nearbyint</td>
+    </tr>
+    </tbody>
+    <thead><th colspan="5">Supported Testing Operations</th></thead>
+    <tbody>
+    <tr>
+    <td>&lt;</td><td>&gt;</td><td>&lt;=</td><td>&gt;=</td><td>==</td>
+    </tr><tr>
+    <td>!=</td><td>and</td><td>or</td><td>not</td><td>isfinite</td>
+    </tr><tr>
+    <td>isinf</td><td>isnan</td><td>isnormal</td><td>signbit</td>
+    </tr>
+    </tbody>
+  </table>
+
+  <aside>
+    Arithmetic operations are binary, because floating-point
+    arithmetic is non-associative. Since boolean operations are,
+    however, exact, they may be given arbitrarily many arguments.
+  </aside>
+
+  <p>
+    All operations have the same signature as the equivalent operations
+    in <a href="http://en.cppreference.com/w/c/numeric/math">C11</a>.
+    The arithmetic functions are all binary operators,
+    except that unary <code>-</code> represents negation.
+    The comparison operators and boolean <code>and</code>
+    and <code>or</code> allow an arbitrary number of arguments.
+  </p>
+
+  <p>A comparison operator with more than two operators is interpreted
+    as the conjuction of all ordered pairs of arguments. In other
+    words, <code>==</code> tests that all
+    its arguments are equal; <code>!=</code> tests that all its
+    arguments are distinct;
+    and <code>&lt;</code>, <code>&gt;</code>, <code>&lt;=</code>,
+    and <code>&gt;=</code> test that their arguments are sorted (in
+    the appropriate order), with equal elements allowed
+    for <code>&lt;=</code> and <code>&gt;=</code>, and disallowed
+    for <code>&lt;</code> and <code>&gt;</code>.
+  </p>
+  </section>
+
+  <section id="g:constant">
+  <h3>Supported constants</h3>
+
+  <p>The following constants are supported:</p>
+
+  <aside>
+    FPCore supports all constants commonly provided by C and Fortran implementations.
+  </aside>
+
+  <table class="code-terms">
+    <colgroup><col><col><col><col><col></colgroup>
+    <thead><th colspan="5">Supported Mathematical Constants</th></thead>
+    <tbody>
+    <tr>
+    <td>E</td><td>LOG2E</td><td>LOG10E</td><td>LN2</td><td>LN10</td>
+    </tr><tr>
+    <td>PI</td><td>PI_2</td><td>PI_4</td><td>1_PI</td><td>2_PI</td>
+    </tr><tr>
+    <td>2_SQRTPI</td><td>SQRT2</td><td>SQRT1_2</td><td>INFINITY</td><td>NAN</td></tr>
+    </tbody>
+    <thead><th colspan="5">Supported Boolean Constants</th></thead>
+    <tbody>
+    <tr>
+    <td>TRUE</td><td>FALSE</td>
+    </tr>
+    </tbody>
+  </table>
+
+  <p>
+    The floating-point constants are defined just like their analogs in
+    <a href="http://www.gnu.org/software/libc/manual/html_node/Mathematical-Constants.html">GNU libc</a>.
+    All constants must evaluate to a value as close as possible to their
+    mathematically-accurate real value, according to the rounding context.
+  </p>
+  </section>
+
+  <section id="semantics">
+  <h3>Semantics</h3>
+
+  <aside>
+    When FPCore expressions used mixed or incorrect types, we expect
+    tools to inform the user of their error. FPBench will provide a
+    type checker for FPBench expressions to help users diagnose and
+    fix any undefined behavior.
+  </aside>
+
+  <p>
+    FPCore expressions can describe concrete floating-point
+    computations, abstract specifications of those computations, or
+    intermediates between the two. The semantics of FPCore are
+    correspondingly flexible, and are made explicit by the rounding context.
+  </p>
+
+  <p>
+    Values in FPCore expressions are either boolean values or extended
+    real numbers, which can be actual real numbers (usualy rounded to some
+    finite precision) or special
+    floating-point values such as infinities and NaN. Numerical operations are
+    treated as rounded real operations: they take extended real values as input
+    and return the corresponding extended real result, rounded according to the
+    rounding context. The behavior of rounding and the rounding context is
+    described in detail under <a href="#rounding">rounding</a>.
+  </p>
+
+  <p>
+    Operations that receive values of mixed or incorrect types, such
+    as <code>(+ 1 TRUE)</code>, are illegal and the results of
+    evaluating them undefined. If tools do not support the rounding context
+    specified for a computation, the result is similarly undefined, and the
+    tool should give some indication for the reason of failure.
+  </p>
+
+  <dl class="code-terms">
+    <dt>Function application</dt>
+    <dd>
+      The semantics of function application are standard.
+    </dd>
+
+    <dt><code>if</code> expressions</dt>
+    <dd>
+      An <code>if</code> expression evaluates the conditional to a
+      boolean and then returns the result of the first branch if the
+      conditional is true or the second branch if the conditional is
+      false.
+    </dd>
+
+    <dt><code>let</code> expressions</dt>
+    <dd>
+      Bindings in a <code>let</code> expression are evaluated
+      simultaneously, as in a simultaneous substitution.
+      Thus, <code>(let ([a b] [b a]) (- a b))</code> is
+      the same as <code>(- b a)</code> and <code>(let ([a 1] [b a])
+        b)</code> is illegal unless <code>a</code> is available in the
+      context. For sequentially binding variables, use nested
+      <code>let</code>s.
+    </dd>
+
+    <dt><code>while</code> expressions</dt>
+    <dd>
+      <p>
+        A <code>while</code> loop contains a conditional, a list of
+        bound variables, and a return expression. Both the conditional
+        and the return expression may refer to the bound variables.
+        While loops are evaluated according the equality:
+      </p>
+
+      <pre style="width: 55ex; margin: 1em auto"><code>(while <var>cond</var> ([<var>x</var> <var>init</var> <var>update</var>] ...) <var>body</var>)<hr style="border-style: double; border-width: 4px 0 0"/>(let ([<var>x</var> <var>init</var>] ...)
+  (if <var>cond</var>)
+    (while <var>cond</var> ([<var>x</var> <var>update</var> <var>update</var>] ...) <var>body</var>)
+    body)</code></pre>
+
+      <p>
+        In other words,
+        the list of bound variables gives
+        the variable's name,
+        its initial value,
+        and the value it is updated to after each iteration.
+        The loop is executed by
+        initializing all bound variables
+        and then
+        evaluating the condition
+        and simultaneously updating the variables
+        until the condition returns false.
+        Once the condition returns false,
+        the return expression is evaluated
+        and its value is returned.
+      </p>
+    </dd>
+
+    <aside>
+      <code>cast</code> is useful for explicitly rounding variables.
+      Normally, variables reflect a call by value semantics and are not rounded
+      where they appear as values.
+    </aside>
+
+    <dt><code>cast</code> expressions</dt>
+    <dd>
+      <p>
+        A <code>cast</code> performs explicit rounding according to the
+        rounding context. If the context specifies real precision, it is
+        guaranteed to be a no-op.
+      </p>
+    </dd>
+
+    <dt><code>!</code> annotations</dt>
+    <dd>
+      <p>
+        A <code>!</code> annotation updates the rounding context for a
+        subexpression. All metadata properties in the current rounding context
+        are removed and replaced with the properties provided in the annotation.
+        See <a href="#rounding">rounding</a>.
+      </p>
+    </dd>
+  </dl>
+  </section>
+
+  <section id="rounding">
+  <h3>Rounding</h3>
+
+  <p>
+    FPCore allows the precision of program inputs, constants, and operations
+    to be controlled via a rounding context. The context consists of
+    a set of <a href="metadata-1.1.html">metadata properties</a> which
+    are initially inherited from the overall properties of the FPCore
+    and can be updated for a subexpression by wrapping it with a
+    ! annotation, or for a program input by supplying an annotation on the argument.
+  </p>
+
+  <p>
+    Rounding contexts use lexical scoping. For example, in the expression
+  </p>
+
+  <figure>
+    <pre><code>(! :precision binary64
+      (let ([ y (! :precision binary32 (- x 1))])
+      (+ y 1)))))</code></pre>
+  </figure>
+
+  <p>
+    the subtraction will take place in a context with <code>binary32</code> precision, but the
+    addition will take place in a context that has inherited <code>binary64</code> precision
+    from the annotation enclosing the entire <code>let</code>.
+  </p>
+
+  <aside>
+    The same precision context can be specified in multiple ways, and tracking the context can be
+    complex. To make the context more regular, an FPCore can be put into canonical form, where
+    each operation, constant, and input is directly annotated with its rounding context.
+  </aside>
+
+  <p>
+    Number literals, mathematical constants, and program inputs
+    are also rounded according to the rounding context. Variables are not rounded
+    where they appear as values, but will usually hold rounded values, either from
+    the expressions where they are bound or from rounded program inputs.
+  </p>
+
+  <p>
+    FPCore does not restrict the behvior of the rounding function or the set
+    of metadata properties that its behavior depends on. Some common precision
+    and rounding direction properties are described for the metadata properties
+    <a href="metadata-1.1.html#p:precision"><code>:precision</code></a> and <a href="metadata-1.1.html#p:round"><code>:round</code></a>.
+    Tools are not required to support all of these rounding behaviors, and are allowed
+    to introduce new ones and new metadata properties to control them.
+  </p>
+
+  <p>
+    Similarly, FPCore does not restrict the representation used internally by a tool
+    to store values. Numeric values can be floating-point values of various precisions,
+    fixed-point values, or symbolic representations of mathematical real numbers. This specification
+    uses mathematical reals as a universal way to describe the value of any representation,
+    but tools are not required to be able to represent arbitrary real numbers exactly.
+  </p>
+
+  </section>
+</section>
+
+</main>
diff --git a/spec/index.html b/spec/index.html
index 583c3ec..8ac4a22 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -20,6 +20,28 @@ <h1>FPBench Standards</h1>
     listed on here.
   </p>
 
+  <ul>
+    <li>FPBench 1.1 Standards (DRAFT VERSION):
+      <ul>
+        <li><a href="fpcore-1.1.html">FPCore benchmark format</a></li>
+        <li><a href="metadata-1.1.html">FPCore metadata properties</a></li>
+        <li><a href="measures-1.1.html">FPBench standard measures</a></li>
+      </ul>
+      Changes:
+      <ul>
+        <li>Support for multiple and mixed-precision computations</li>
+        <li>Semantics of numerical operations clarified as rounded real operations</li>
+        <li>Precision can be specified per-operation using the rounding context</li>
+        <li>New constant formats, including rational numbers and hexadecimal floating-point</li>
+        <li>New metadata properties <code>:round</code> and <code>:spec</code></li>
+      </ul>
+    </li>
+  </ul>
+
+  <p>
+    Previous versions of the standards:
+  </p>
+
   <ul>
     <li>FPBench 1.0 Standards:
       <ul>
diff --git a/spec/measures-1.1.html b/spec/measures-1.1.html
new file mode 100644
index 0000000..fc5bfa6
--- /dev/null
+++ b/spec/measures-1.1.html
@@ -0,0 +1,213 @@
+<!doctype html>
+<html lang="en_US">
+<head>
+  <meta charset="utf-8"/>
+  <title>FPBench Measures 1.0</title>
+  <link rel="stylesheet" type="text/css" href="../fpbench.css">
+</head>
+<body class="gutter">
+
+<header>
+    <a href='..' style='color: black; text-decoration: none;'>
+      <img src='../img/logo.png' height='150' alt='FPBench Logo' />
+      <h1>Measures 1.0</h1>
+      <p>Common error measures for floating-point computations</p>
+    </a>
+</header>
+
+<main>
+<header>
+  <h1>FPBench 1.1 standards</h1>
+
+  <p>
+    <a href="../">FPBench</a> is a standard benchmark suite for the
+    floating point community. The benchmark suite contains a common format
+    for floating-point computation and metadata and a common set
+    of accuracy measures:
+  </p>
+
+  <ol>
+    <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
+    <li><a href="measures-1.1.html">Standard measures of error</a></li>
+  </ol>
+
+</header>
+
+<section id="measures">
+<header>
+  <h2>FPBench Standard Measures</h2>
+  
+  <p>
+    FPBench standardizes several measures of accuracy; tools that measure
+    accuracy should state which of the FPBench accuracy measures they use, so
+    that the community can more easily compare tools.
+  </p>
+</header>
+
+<p>
+  FPBench analyses floating-point accuracy along several axes:
+  scaling vs non-scaling error, forward vs. backward error, and maximum vs.
+  average error. Tools that measure error may use sound vs. statistical
+  techniques, and tools that transform programs have several options for how to
+  measure accuracy improvement.
+</p>
+
+<h3>Scaling vs. non-scaling error (\(\varepsilon\))</h3>
+
+<p>
+  There are several ways to measure the error of producing the inaccurate value
+  \(\hat x\) instead of the true value \(x\). Two common mathematical notions are
+  the absolute and relative error:
+</p>
+<figure>
+\[
+\varepsilon_{\text{abs}}(x, x') = \left|x - \hat x\right|
+\quad \text{and} \quad
+\varepsilon_{\text{rel}}(x, x') = \left|\frac{x - \hat x}{x}\right|
+\]
+</figure>
+
+<p>
+  Relative error scales with the quantity being measured, and thus makes sense
+  for measuring both large and small numbers, much like the floating-point
+  format itself. A notion of error more closely tied to the floating-point
+  format is the Units in the Last Place (ULPs) difference.
+</p>
+<aside>
+  Unfortunately, the term Units in the Last Place, or ULPs, means different
+  things in the mathematical and programming communities. We use the definition
+  common for programming tools, such as
+  <a href="https://github.com/StanfordPL/stoke">STOKE-FP</a>.
+</aside>
+<p>
+  Some tools instead use the logarithm of the ULPs, which approximately
+  describes the number of incorrect low-order bits in \(\hat x\). These two
+  measures are defined as:
+</p>
+<figure>
+\[
+\varepsilon_{\text{ulps}}(x, x') = |\mathbb{F} \cap [\min(x, \hat x), \max(x, \hat x)]|
+\quad \text{and} \quad
+\varepsilon_{\text{bits}}(x, x') = \log_2 \varepsilon_{\text{ulps}}(x, x')
+\]
+</figure>
+
+<p>
+  The floating-point numbers are distributed roughly exponentially, so this
+  measure of error scales in a similar manner to relative error; however, it
+  is better-behaved in the presence of denormal numbers and infinities.
+</p>
+
+<h3>Forward vs. backward error (\(\epsilon\))</h3>
+
+<p>
+  Forward error and backward error are two common measures for the error of a
+  mathematical <i>computation</i>. For a true function \(f\) and its
+  approximation \(\hat f\), forward error measures the difference between
+  outputs for a fixed input, while backward error measures the difference
+  between inputs for a fixed output. Formally:
+</p>
+<aside> Where \(n\) is the number of arguments. </aside>
+<figure>
+\[
+  \epsilon_{fwd}(f, \hat{f}, x) = \varepsilon(f(x), \hat{f}(x))
+\]
+\[
+  \epsilon_{bwd}(f, \hat{f}, x) =
+    \min \left\{ \varepsilon(x, x') : x' \in \mathbb{F}^n \land {\hat f}(x') = f(x) \right\}
+\]
+</figure>
+
+<p>
+  Backward error is important for evaluating the stability of an algorithm, and
+  in scientific applications where multiple sources of error (algorithmic error
+      vs. sensor error) must be compared. Existing tools typically measure
+  forward error because backward error can be tricky to compute for
+  floating-point computations, where there may not be an input that produces
+  the true output.
+
+<h3>Average vs. maximum error (\(E\))</h3>
+
+<p>
+  Describing the error of a floating-point computation means summarizing its
+  behaviour across multiple inputs. Existing tools use either maximum or
+  average error for this task. Formally:
+</p>
+<aside>
+  Where \(N\) is the number of valid inputs, and \(n\) is the number of arguments.
+</aside>
+<figure>
+\[
+  E_{\text{max}}(f, \hat{f}) = \max \left\{\epsilon(f, \hat{f}, x) : x \in \mathbb{F}^n\right\}
+  \quad \text{and} \quad
+  E_{\text{avg}}(f, \hat{f}) = \frac{1}{N} \sum_{x\in \mathbb{F}^n} \epsilon(f, \hat{f}, x)
+\]
+</figure>
+
+<p>
+  Worst-case error tends to be easier to measure soundly, while average error
+  tends to be easier to measure statistically.
+</p>
+
+<h3>Sound vs. statistical techniques</h3>
+
+<p>
+  Running a floating-point program on all valid inputs is intractable. Existing
+  tools either soundly overapproximate the error using static analysis, or
+  approximate the error using statistical sampling.
+</p>
+
+<p>
+  Most static techniques are based on interval or affine arithmetic to
+  over-approximate floating-point arithmetic, often using abstract
+  interpretation. Abstract interpretation may use either non-relational or
+  relational abstract domains, and may use acceleration techniques (widenings)
+  to over-approximate loops without unrolling them. While such techniques tend
+  to provide loose over-approximations of the floating-point error of programs,
+  they are fast and provide sound error bounds. In some embedded applications,
+  correctness is critical and unsound techniques will not do.
+</p>
+
+<p>
+  In domains where correctness is not absolutely critical, sampling can provide
+  tight approximations of error. Many sampling techniques are used, including
+  naive random samples and Markov-chain Monte Carlo. These techniques involve
+  running a program multiple times, so they tend to be slower than static
+  analysis.
+</p>
+
+<h3>Measuring improvement (\(\iota\))</h3>
+
+<p>
+  Tools that <i>transform</i> floating-point programs need to compare the
+  accuracy of two floating-point implementations of a function, the original
+  and the transformed. Several comparison measures are possible. Comparisons
+  can use the improvement in worst-case or average error between the original
+  \(\hat f\) and improved \(\hat f'\) implementation of the same mathematical
+  function \(f\):
+</p>
+
+\[
+  \iota_{\text{imp}} = E(f, \hat{f}) - E(f, \hat{f}')
+\]
+
+<p>
+  However, one cannot usually improve the accuracy of a computation
+  simultaneously on all inputs. It is thus often necessary to make a
+  computation less accurate on some points to make it more accurate overall. In
+  this case, it may be useful to report the largest unimprovement, which
+  measures the cost of improving accuracy:
+</p>
+
+<figure>
+\[
+  \iota_{\text{wrs}}(\hat{f},\hat{f}') = \max \left\{ \epsilon(f, \hat{f}', x) - \epsilon(f, \hat{f}', x)
+\ :\ x\in \mathbb{F}^n\right\}
+\]
+</figure>
+
+  <script src='https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'></script>
+</section>
+
+</main>
diff --git a/spec/metadata-1.1.html b/spec/metadata-1.1.html
new file mode 100644
index 0000000..1dd7154
--- /dev/null
+++ b/spec/metadata-1.1.html
@@ -0,0 +1,139 @@
+<!doctype html>
+<html lang="en_US">
+<head>
+  <meta charset="utf-8"/>
+  <title>FPBench Metadata 1.1</title>
+  <link rel="stylesheet" type="text/css" href="../fpbench.css">
+</head>
+<body class="gutter">
+
+<header>
+    <a href='..' style='color: black; text-decoration: none;'>
+      <img src='../img/logo.png' height='150' alt='FPBench Logo' />
+      <h1>Metadata 1.1 (DRAFT VERSION)</h1>
+      <p>Common metadata for floating-point computations</p>
+    </a>
+</header>
+
+<main>
+<header>
+  <h1>FPBench 1.1 standards</h1>
+
+  <p>
+    <a href="../">FPBench</a> is a standard benchmark suite for the
+    floating point community. The benchmark suite contains a common format
+    for floating-point computation and metadata and a common set
+    of accuracy measures:
+  </p>
+
+  <ol>
+    <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
+    <li><a href="measures-1.1.html">Standard measures of error</a></li>
+  </ol>
+
+</header>
+
+<section id="props">
+<header>
+  <h2>FPCore metadata properties</h2>
+
+  <p>
+    The metadata properties allow describing additional information
+    about each benchmark, such as their name, description,
+    precision, citations, or preconditions.
+  </p>
+</header>
+
+
+<p>
+  FPBench 1.1 defines the meaning of the following properties:
+</p>
+
+<dl class="code-terms">
+  <dt id="p:name">:name</dt>
+  <dd>
+    A string name for the benchmark. If a name is needed and not
+    provided, we recommend using the body expression.
+  </dd>
+
+  <dt id="p:description">:description</dt>
+  <dd>
+    A string description for the benchmark and its inputs. We
+    recommend describing the physical meaning and units of inputs
+    when applicable.
+  </dd>
+
+  <dt id="p:cite">:cite</dt>
+  <dd>
+    A list of symbols that describe the sources of the benchmark.
+    We recommend making available a BibTeX file which uses the
+    same symbols as keys.
+  </dd>
+
+  <dt id="p:precision">:precision</dt>
+  <dd>
+    Describes the floating-point precision used for <a href="fpcore-1.1.html#rounding">rounding</a>. It is expected
+    to be a symbol for one of the IEEE 754 names (such as <code>binary32</code>
+    and <code>binary64</code>) or one of the special values <code>real</code> or
+    <code>integer</code>. <code>real</code> precision indicates that no rounding
+    should take place, while <code>integer</code> precision specifies the behavior of
+    (unbounded) mathematical integers. If no <code>:precision</code> property is specified,
+    implementations should assume a sane default, such as <code>binary64</code> or
+    possibly <code>real</code> depending on the application domain.
+  </dd>
+
+  <dt id="p:round">:round</dt>
+  <dd>
+    The floating-point rounding mode used for <a href="fpcore-1.1.html#rounding">rounding</a>. Expected to be one of the IEEE 754 modes
+    <code>nearestEven</code>, <code>nearestAway</code>, <code>toPositive</code>,
+    <code>toNegative</code>, or <code>toZero</code>.
+  </dd>
+
+  <aside>
+    If a <code>:spec</code> is not provided for a benchmark, the assumed <code>:spec</code>
+    will use the same expression as the benchmark, but a rounding context with <code>real</code>
+    precision. This makes sense for most precision-independent benchmarks that implement a real
+    function directly.
+  </aside>
+
+  <dt id="p:pre">:pre</dt>
+  <dd>
+    A precondition on inputs to the benchmark. Tools should not use
+    points that fail the precondition to determine the accuracy of the
+    benchmark. It is expected to be
+    an <a href="fpcore-1.1.html#g:expr">expression</a> that
+    returns a boolean value. A rounding context can be given explicitly
+    for the expression, but if it is not, the default rounding context is assumed
+    to have <code>real</code> precision rather than the overall properties specified
+    for the FPCore.
+  </dd>
+
+  <dt id="p:spec">:spec</dt>
+  <dd>
+    A real-valued function approximated by the benchmark. If not provided,
+    then it is assumed to be the body of the benchmark. As with preconditions
+    specified with <code>:pre</code>, a rounding context can be provided explicitly,
+    but it is assumed to have <code>real</code> precision rather than the overall properties specified
+    for the FPCore.
+  </dd>
+
+  <dt id="p:math-library">:math-library</dt>
+  <dd>
+    The library used in the source to implement floating-point
+    operations. It is expected to be a symbol identifying a library
+    implementation and version, such as <code>gnu-libm-2.34</code>.
+  </dd>
+</dl>
+
+<p>
+  Additionally, properties prefixed by the name of a tool (such
+  as <code>:xxx-foobar</code>) are reserved for definition by that
+  tool. Only that tool may define the meaning of those properties;
+  other tools should not depend on the meaning of those
+  properties, nor must the defining tool keep the meaning constant.
+</p>
+
+</section>
+
+</main>

From 16e177e72f28185bc442478cdff1a97e32033b8a Mon Sep 17 00:00:00 2001
From: Bill Zorn <bill.zorn@gmail.com>
Date: Tue, 24 Jul 2018 18:35:23 -0700
Subject: [PATCH 2/5] fix typos

---
 spec/fpcore-1.1.html | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/spec/fpcore-1.1.html b/spec/fpcore-1.1.html
index d7e37a1..e4485d4 100644
--- a/spec/fpcore-1.1.html
+++ b/spec/fpcore-1.1.html
@@ -51,7 +51,7 @@ <h2>FPCore benchmark format</h2>
  :cite (hamming-1987)
  :pre (>= x 0)
  (- (sqrt (+ x 1)) (sqrt x)))</code></pre>
-    <caption>An example FPCore program, from the <data value="benchmarks/hamming-ch3.fpcore" class="suite-name">hamming-ch3</data> suite.</caption>
+    <caption>An example FPCore benchmark, from the <data value="benchmarks/hamming-ch3.fpcore" class="suite-name">hamming-ch3</data> suite.</caption>
   </figure>
 
   <figure>
@@ -411,7 +411,7 @@ <h3>Rounding</h3>
     to be controlled via a rounding context. The context consists of
     a set of <a href="metadata-1.1.html">metadata properties</a> which
     are initially inherited from the overall properties of the FPCore
-    and can be updated for a subexpression by wrapping it with a
+    benchmark and can be updated for a subexpression by wrapping it with a
     ! annotation, or for a program input by supplying an annotation on the argument.
   </p>
 
@@ -433,8 +433,8 @@ <h3>Rounding</h3>
 
   <aside>
     The same precision context can be specified in multiple ways, and tracking the context can be
-    complex. To make the context more regular, an FPCore can be put into canonical form, where
-    each operation, constant, and input is directly annotated with its rounding context.
+    complex. To make the context more regular, an FPCore benchmark can be put into canonical form,
+    where each operation, constant, and input is directly annotated with its rounding context.
   </aside>
 
   <p>
@@ -445,7 +445,7 @@ <h3>Rounding</h3>
   </p>
 
   <p>
-    FPCore does not restrict the behvior of the rounding function or the set
+    FPCore does not restrict the behavior of the rounding function or the set
     of metadata properties that its behavior depends on. Some common precision
     and rounding direction properties are described for the metadata properties
     <a href="metadata-1.1.html#p:precision"><code>:precision</code></a> and <a href="metadata-1.1.html#p:round"><code>:round</code></a>.

From 8a9316aa1ab768ca3796195f7d6e3beecf9dbf03 Mon Sep 17 00:00:00 2001
From: Bill Zorn <bill.zorn@gmail.com>
Date: Mon, 13 Aug 2018 17:20:29 -0700
Subject: [PATCH 3/5] update standard so that annotations inherit properties
 from the parent context Also adds some examples:   * an aside about
 tool-specific properties, featuring Herbie   * examples related to cast and
 double rounding   * examples related to context inheritance

---
 spec/fpcore-1.1.html   | 148 +++++++++++++++++++++++++++++++++++++++--
 spec/metadata-1.1.html |   6 ++
 2 files changed, 147 insertions(+), 7 deletions(-)

diff --git a/spec/fpcore-1.1.html b/spec/fpcore-1.1.html
index e4485d4..a304626 100644
--- a/spec/fpcore-1.1.html
+++ b/spec/fpcore-1.1.html
@@ -395,9 +395,9 @@ <h3>Semantics</h3>
     <dd>
       <p>
         A <code>!</code> annotation updates the rounding context for a
-        subexpression. All metadata properties in the current rounding context
-        are removed and replaced with the properties provided in the annotation.
-        See <a href="#rounding">rounding</a>.
+        subexpression. Properties specified in the annotation are set
+        to the provided values, and all other properties are inherited
+        from the parent context. See <a href="#rounding">rounding</a>.
       </p>
     </dd>
   </dl>
@@ -420,15 +420,16 @@ <h3>Rounding</h3>
   </p>
 
   <figure>
-    <pre><code>(! :precision binary64
-      (let ([ y (! :precision binary32 (- x 1))])
-      (+ y 1)))))</code></pre>
+    <pre><code>(! :precision binary64 :round nearestEven
+  (let ([ y (! :precision binary32 (- x 1))])
+    (+ y 1)))))</code></pre>
   </figure>
 
   <p>
     the subtraction will take place in a context with <code>binary32</code> precision, but the
     addition will take place in a context that has inherited <code>binary64</code> precision
-    from the annotation enclosing the entire <code>let</code>.
+    from the annotation enclosing the entire <code>let</code>. Both operations will take place
+    in a context that has inherited <code>nearestEven</code> rounding behavior.
   </p>
 
   <aside>
@@ -462,6 +463,139 @@ <h3>Rounding</h3>
   </p>
 
   </section>
+
+  <section id="examples">
+  <h3>Examples</h3>
+
+  <dl class="code-terms">
+    <dt id="e:casting">Rounding with <code>cast</code></dt>
+    <dd>
+      <p>
+        The <code>cast</code> operation is necessary for explicitly rounding values
+        without performing other numerical operations. Precision annotations specified
+        with <code>!</code> never cause any numerical operations to occur; they only
+        change the rounding context.
+      </p>
+
+      <p>
+        For example, the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64 (! :precision binary32 x))</code></pre>
+      </figure>
+
+      <p>
+        will not round the value of the variable <code>x</code>. This expression is the
+        same as simply specifying
+      </p>
+
+      <figure>
+        <pre><code>x</code></pre>
+      </figure>
+
+      <p>
+        regardless of the rounding context. To round <code>x</code>, it is necessary
+        to <code>cast</code> it in a context with the desired precision. The expression
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64 (! :precision binary32 (cast x)))</code></pre>
+      </figure>
+
+      <p>
+        will round <code>x</code> to <code>binary32</code> precision (here the outer
+        annotation for <code>binary64</code> precision is redundant, as it will be overwritten by the
+        inner one), while the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64 (cast (! :precision binary32 (cast x))))</code></pre>
+      </figure>
+
+      <p>
+        will round <code>x</code> twice, first to <code>binary32</code> precision, and then from <code>binary32</code>
+        to <code>binary64</code> precision.
+      </p>
+
+      <p>
+        Because numerical operations already round their outputs, it should not be necessary
+        to <code>cast</code> in most cases, unless double rounding is specifically intended.
+        For example, in an expression such as
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64
+  (let ([ x (+ y 1)])
+    x))</code></pre>
+      </figure>
+
+      <p>
+        the value stored in x will already be rounded to <code>binary64</code> precision,
+        as the addition is done in a context with that precision. Inserting an explicit
+        <code>cast</code> around either the addition or the use of <code>x</code> would
+        cause double rounding, and while in the case of <code>binary64</code> precision
+        this is a no-op, for other rounding contexts it could lead to undesirable behavior.
+      </p>
+    </dd>
+
+    <dt id="e:inheritance">Inheriting properties in rounding contexts</dt>
+    <dd>
+      <p>
+        All properties not explicitly specified in a <code>!</code> precision annotation
+        are inherited from the parent context. For the top level expression in an
+        FPCore benchmark, the parent context includes all the overall properties of the benchmark.
+      </p>
+
+      <p>
+        For example, in the following benchmark
+      </p>
+
+      <figure>
+        <pre><code class="fpcore">(FPCore ()
+ :name "foo"
+ :math-library gnu-libm-2.34
+ :spec 0
+  (! :precision binary64 (sin PI)))</code></pre>
+      </figure>
+
+      <p>
+        the <code>sin</code> operation will take place in a context with <code>name</code>
+        <code>"foo"</code>, <code>math-library</code> <code>gnu-libm-2.34</code>, <code>spec</code> 0, and
+        <code>binary64</code> precision. Even properties that are seemingly unrelated to
+        rounding, such as the name of the benchmark, are inherited. The FPCore standard does
+        not prohibit tools from implementing rounding functions that depend on these properties,
+        or other tool-specific properties, although having a rounding function that depends on
+        <code>name</code> is not advised.
+      </p>
+
+      <p>
+        Properties in the rounding context might come from multiple different annotations. For example,
+        in the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :math-library gnu-libm-2.34 (! :round toZero (! :precision binary32 (+ x 1))))</code></pre>
+      </figure>
+
+      <p>
+        the addition will take place as expected in a context with <code>binary32</code> precision,
+        <code>toZero</code> rounding direction, and the <code>gnu-libm-2.34</code> math library. This
+        can be useful if some, but not all, of the properties are shared by multiple subexpressions.
+        For example, in the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64 (- (! :round toPositive (+ x y)) (! :round toNegative (+ x y))))</code></pre>
+      </figure>
+
+      <p>
+        all of the operations will take place in a context with <code>binary64</code> precision, but the additions
+        will use different rounding directions.
+      </p>
+    </dd>
+  </dl>
+  </section>
 </section>
 
 </main>
diff --git a/spec/metadata-1.1.html b/spec/metadata-1.1.html
index 1dd7154..026a01d 100644
--- a/spec/metadata-1.1.html
+++ b/spec/metadata-1.1.html
@@ -45,6 +45,12 @@ <h2>FPCore metadata properties</h2>
   </p>
 </header>
 
+<aside>
+  In cases where it is necessary to provide additional metadata, tools can
+  define their own properties. For example, Herbie includes the
+  <a href="http://herbie.uwplse.org/doc/latest/input.html#properties"><code>:herbie-time</code></a>
+  property in its output to indicate how long it took to rewrite the benchmark.
+</aside>
 
 <p>
   FPBench 1.1 defines the meaning of the following properties:

From 8360e70678bc2a41470e4d7ef6533ac7bfa7e45a Mon Sep 17 00:00:00 2001
From: Pavel Panchekha <me@pavpanchekha.com>
Date: Wed, 15 Aug 2018 16:08:53 -0700
Subject: [PATCH 4/5] Pass over the 1.1 documentation

---
 spec/examples-1.1.html | 168 ++++++++++++++++++++++
 spec/fpcore-1.1.html   | 307 ++++++++++++++---------------------------
 spec/index.html        |  49 ++++---
 spec/measures-1.1.html |   1 +
 spec/metadata-1.1.html |   1 +
 5 files changed, 296 insertions(+), 230 deletions(-)
 create mode 100644 spec/examples-1.1.html

diff --git a/spec/examples-1.1.html b/spec/examples-1.1.html
new file mode 100644
index 0000000..7b2f291
--- /dev/null
+++ b/spec/examples-1.1.html
@@ -0,0 +1,168 @@
+<!doctype html>
+<html lang="en_US">
+<head>
+  <meta charset="utf-8"/>
+  <title>FPBench Examples 1.1</title>
+  <link rel="stylesheet" type="text/css" href="../fpbench.css">
+</head>
+<body class="gutter">
+
+<header>
+    <a href='..' style='color: black; text-decoration: none;'>
+      <img src='../img/logo.png' height='150' alt='FPBench Logo' />
+      <h1>FPCore 1.1 (DRAFT VERSION)</h1>
+      <p>A common format for floating-point computations</p>
+    </a>
+</header>
+
+<main>
+<header>
+  <h1>FPBench 1.1 standards</h1>
+
+  <p>
+    <a href="../">FPBench</a> is a standard benchmark suite for the
+    floating-point community. The benchmark suite contains a common format
+    for floating-point computation and metadata and a common set
+    of accuracy measures:
+  </p>
+
+  <ol>
+    <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="examples-1.1.html">FPCore example inputs</a></li>
+    <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
+    <li><a href="measures-1.1.html">Standard measures of error</a></li>
+  </ol>
+</header>
+
+<section id="cast">
+  <h2>Rounding with <code>cast</code></h3>
+
+  <p>
+    The <code>cast</code> operation is necessary for explicitly rounding values
+    without performing other numerical operations. Precision annotations specified
+    with <code>!</code> never cause any numerical operations to occur; they only
+    change the rounding context.
+  </p>
+
+  <p>
+    For example, the expression
+  </p>
+
+  <figure>
+    <pre><code>(! :precision binary64 (! :precision binary32 x))</code></pre>
+  </figure>
+
+  <p>
+    will not round the value of the variable <code>x</code>. This expression is the
+    same as simply specifying
+  </p>
+
+  <figure>
+    <pre><code>x</code></pre>
+  </figure>
+
+  <p>
+    regardless of the rounding context. To round <code>x</code>, it is necessary
+    to <code>cast</code> it in a context with the desired precision. The expression
+  </p>
+
+  <figure>
+    <pre><code>(! :precision binary64 (! :precision binary32 (cast x)))</code></pre>
+  </figure>
+
+  <p>
+    will round <code>x</code> to <code>binary32</code> precision (here the outer
+    annotation for <code>binary64</code> precision is redundant, as it will be overwritten by the
+    inner one), while the expression
+  </p>
+
+  <figure>
+    <pre><code>(! :precision binary64 (cast (! :precision binary32 (cast x))))</code></pre>
+  </figure>
+
+  <p>
+    will round <code>x</code> twice, first to <code>binary32</code> precision, and then from <code>binary32</code>
+    to <code>binary64</code> precision.
+  </p>
+
+  <p>
+    Because numerical operations already round their outputs, it should not be necessary
+    to <code>cast</code> in most cases, unless double rounding is specifically intended.
+    For example, in an expression such as
+  </p>
+
+  <figure>
+    <pre><code>(! :precision binary64
+   ([ x (+ y 1)])
+  )</code></pre>
+  </figure>
+
+  <p>
+    the value stored in x will already be rounded to <code>binary64</code> precision,
+    as the addition is done in a context with that precision. Inserting an explicit
+    <code>cast</code> around either the addition or the use of <code>x</code> would
+    cause double rounding, and while in the case of <code>binary64</code> precision
+    this is a no-op, for other rounding contexts it could lead to undesirable behavior.
+  </p>
+</section>
+
+<section id="inheriting">
+  <h2>Inheriting properties in rounding contexts</h2>
+
+      <p>
+        All properties not explicitly specified in a <code>!</code> precision annotation
+        are inherited from the parent context. For the top level expression in an
+        FPCore benchmark, the parent context includes all the overall properties of the benchmark.
+      </p>
+
+      <p>
+        For example, in the following benchmark
+      </p>
+
+      <figure>
+        <pre><code class="fpcore">(FPCore ()
+ :name "foo"
+ :math-library gnu-libm-2.34
+ :spec 0
+  (! :precision binary64 (sin PI)))</code></pre>
+      </figure>
+
+      <p>
+        the <code>sin</code> operation will take place in a context with <code>name</code>
+        <code>"foo"</code>, <code>math-library</code> <code>gnu-libm-2.34</code>, <code>spec</code> 0, and
+        <code>binary64</code> precision. Even properties that are seemingly unrelated to
+        rounding, such as the name of the benchmark, are inherited. The FPCore standard does
+        not prohibit tools from implementing rounding functions that depend on these properties,
+        or other tool-specific properties, although having a rounding function that depends on
+        <code>name</code> is not advised.
+      </p>
+
+      <p>
+        Properties in the rounding context might come from multiple different annotations. For example,
+        in the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :math-library gnu-libm-2.34 (! :round toZero (! :precision binary32 (+ x 1))))</code></pre>
+      </figure>
+
+      <p>
+        the addition will take place as expected in a context with <code>binary32</code> precision,
+        <code>toZero</code> rounding direction, and the <code>gnu-libm-2.34</code> math library. This
+        can be useful if some, but not all, of the properties are shared by multiple subexpressions.
+        For example, in the expression
+      </p>
+
+      <figure>
+        <pre><code>(! :precision binary64 (- (! :round toPositive (+ x y)) (! :round toNegative (+ x y))))</code></pre>
+      </figure>
+
+      <p>
+        all of the operations will take place in a context with <code>binary64</code> precision, but the additions
+        will use different rounding directions.
+      </p>
+</section>
+
+</main>
+</body>
+</html>
diff --git a/spec/fpcore-1.1.html b/spec/fpcore-1.1.html
index a304626..c5fc382 100644
--- a/spec/fpcore-1.1.html
+++ b/spec/fpcore-1.1.html
@@ -28,6 +28,7 @@ <h1>FPBench 1.1 standards</h1>
 
   <ol>
     <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="examples-1.1.html">FPCore example inputs</a></li>
     <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
     <li><a href="measures-1.1.html">Standard measures of error</a></li>
   </ol>
@@ -113,6 +114,11 @@ <h3>Syntax</h3>
     <caption>High-level grammar of FPCore. The tokens <a href="#g:constant">constant</a> and <a href="#g:operation">operation</a>, as well as base tokens like <a href="#g:decnum">decnum</a>, are defined below. </caption>
   </figure>
 
+  <aside>
+    Note that free variabels to a benchmark can be <code>!</code> annotated.
+    These annotations are used for specifying that variable's precision.
+  </aside>
+
   <p>
     In this grammar, an <a href="#g:fpcore">FPCore</a> term describes
     a single benchmark, with a set of free variables, a collection of
@@ -286,13 +292,6 @@ <h3>Supported constants</h3>
   <section id="semantics">
   <h3>Semantics</h3>
 
-  <aside>
-    When FPCore expressions used mixed or incorrect types, we expect
-    tools to inform the user of their error. FPBench will provide a
-    type checker for FPBench expressions to help users diagnose and
-    fix any undefined behavior.
-  </aside>
-
   <p>
     FPCore expressions can describe concrete floating-point
     computations, abstract specifications of those computations, or
@@ -302,24 +301,28 @@ <h3>Semantics</h3>
 
   <p>
     Values in FPCore expressions are either boolean values or extended
-    real numbers, which can be actual real numbers (usualy rounded to some
-    finite precision) or special
-    floating-point values such as infinities and NaN. Numerical operations are
-    treated as rounded real operations: they take extended real values as input
-    and return the corresponding extended real result, rounded according to the
-    rounding context. The behavior of rounding and the rounding context is
-    described in detail under <a href="#rounding">rounding</a>.
+    real numbers, which can be actual real numbers (usually rounded to
+    some finite precision) or special floating-point values such as
+    infinities and NaN. Numerical operations take extended real values
+    as input and return the corresponding extended real result,
+    rounded according to a <i>rounding context</i>. The behavior of
+    rounding and the rounding context is described in detail
+    under <a href="#rounding">Rounding</a>.
   </p>
 
+  <aside>
+    When FPCore expressions used mixed or incorrect types, we expect
+    tools to inform the user of their error. FPBench provides a type
+    checker to help users diagnose and fix any undefined behavior.
+  </aside>
+
   <p>
     Operations that receive values of mixed or incorrect types, such
     as <code>(+ 1 TRUE)</code>, are illegal and the results of
-    evaluating them undefined. If tools do not support the rounding context
-    specified for a computation, the result is similarly undefined, and the
-    tool should give some indication for the reason of failure.
+    evaluating them undefined.
   </p>
 
-  <dl class="code-terms">
+  <dl>
     <dt>Function application</dt>
     <dd>
       The semantics of function application are standard.
@@ -340,10 +343,13 @@ <h3>Semantics</h3>
       Thus, <code>(let ([a b] [b a]) (- a b))</code> is
       the same as <code>(- b a)</code> and <code>(let ([a 1] [b a])
         b)</code> is illegal unless <code>a</code> is available in the
-      context. For sequentially binding variables, use nested
+      context. For sequentially binding variables, nest
       <code>let</code>s.
     </dd>
 
+    <aside>
+      FPCore expressions with loops can be easier to author using the <a href="../fpimp.html">FPImp</a> intermediate language.
+    </aside>
     <dt><code>while</code> expressions</dt>
     <dd>
       <p>
@@ -353,35 +359,25 @@ <h3>Semantics</h3>
         While loops are evaluated according the equality:
       </p>
 
-      <pre style="width: 55ex; margin: 1em auto"><code>(while <var>cond</var> ([<var>x</var> <var>init</var> <var>update</var>] ...) <var>body</var>)<hr style="border-style: double; border-width: 4px 0 0"/>(let ([<var>x</var> <var>init</var>] ...)
-  (if <var>cond</var>)
-    (while <var>cond</var> ([<var>x</var> <var>update</var> <var>update</var>] ...) <var>body</var>)
-    body)</code></pre>
+      <pre style="width: 55ex; margin: 1em auto"><code>(while <var>cond</var> ([<var>x</var> <var>init</var> <var>update</var>] ...) <var>retexpr</var>)<hr style="border-style: double; border-width: 4px 0 0"/>(let ([<var>x</var> <var>init</var>] ...)
+  (if <var>cond</var>
+    (while <var>cond</var> ([<var>x</var> <var>update</var> <var>update</var>] ...) <var>retexpr</var>)
+    <var>retexpr</var>)</code></pre>
 
       <p>
-        In other words,
-        the list of bound variables gives
-        the variable's name,
-        its initial value,
-        and the value it is updated to after each iteration.
-        The loop is executed by
-        initializing all bound variables
-        and then
-        evaluating the condition
-        and simultaneously updating the variables
-        until the condition returns false.
-        Once the condition returns false,
-        the return expression is evaluated
-        and its value is returned.
+        In other words, the list of bound variables gives the
+        variable's name, its initial value, and the expression by
+        which it is updated to after each iteration. The loop
+        initializes all bound variables; evaluates the condition; if
+        true, simultaneously updates the variables with the update
+        expression and repeats; if false, the return expression is
+        evaluated and its value is returned.
       </p>
     </dd>
 
     <aside>
-      <code>cast</code> is useful for explicitly rounding variables.
-      Normally, variables reflect a call by value semantics and are not rounded
-      where they appear as values.
+      <code>cast</code> is used for double-rounding—see <a href="examples-1.1.html#cast">the examples</a>. Nested <code>!</code> annotations change the rounding context but do not multiply round values.
     </aside>
-
     <dt><code>cast</code> expressions</dt>
     <dd>
       <p>
@@ -397,7 +393,7 @@ <h3>Semantics</h3>
         A <code>!</code> annotation updates the rounding context for a
         subexpression. Properties specified in the annotation are set
         to the provided values, and all other properties are inherited
-        from the parent context. See <a href="#rounding">rounding</a>.
+        from the parent context. See <a href="#rounding">Rounding</a>.
       </p>
     </dd>
   </dl>
@@ -408,194 +404,95 @@ <h3>Rounding</h3>
 
   <p>
     FPCore allows the precision of program inputs, constants, and operations
-    to be controlled via a rounding context. The context consists of
-    a set of <a href="metadata-1.1.html">metadata properties</a> which
-    are initially inherited from the overall properties of the FPCore
-    benchmark and can be updated for a subexpression by wrapping it with a
-    ! annotation, or for a program input by supplying an annotation on the argument.
+    to be controlled via a <i>rounding context</i>. The context consists of
+    a set of <a href="metadata-1.1.html">metadata properties</a>, which
+    affect how function application, casts, and constants are rounded.
   </p>
 
   <p>
-    Rounding contexts use lexical scoping. For example, in the expression
+    Number literals, mathematical constants, and program inputs are
+    rounded according to the rounding context. Variables, however, are
+    not rounded where they appear as values (since they hold rounded
+    values, either from the expressions where they are bound or from
+    rounded program inputs).
   </p>
 
-  <figure>
-    <pre><code>(! :precision binary64 :round nearestEven
-  (let ([ y (! :precision binary32 (- x 1))])
-    (+ y 1)))))</code></pre>
-  </figure>
-
   <p>
-    the subtraction will take place in a context with <code>binary32</code> precision, but the
-    addition will take place in a context that has inherited <code>binary64</code> precision
-    from the annotation enclosing the entire <code>let</code>. Both operations will take place
-    in a context that has inherited <code>nearestEven</code> rounding behavior.
+    Function applications round their results using the rounding context.
+    More precisely, a function application
+    <code>(<var>f</var> <var>e<sub>1</sub></var> ...)</code> in a
+    rounding context <var>ρ</var> must evaluate to the same value as
+    if <code><var>f</var></code> were evaluated in exact real
+    arithmetic, and then rounded according to the rounding context.
+    Formally:
   </p>
 
-  <aside>
-    The same precision context can be specified in multiple ways, and tracking the context can be
-    complex. To make the context more regular, an FPCore benchmark can be put into canonical form,
-    where each operation, constant, and input is directly annotated with its rounding context.
-  </aside>
+  <pre style="width: 80%; margin: 1em auto; text-align: center">
+    v<sub>i</sub> = ⟦<var>e<sub>i</sub></var>⟧<sub>ρ</sub> <hr style="border-style: double; border-width: 4px 0 0" /> ⟦ <code>(<var>f</var> <var>e<sub>i</sub></var> ...)</code> ⟧<sub>ρ</sub> = round( ρ, ⟦f⟧(v<sub>i</sub> , ... ) )
+  </pre>
 
   <p>
-    Number literals, mathematical constants, and program inputs
-    are also rounded according to the rounding context. Variables are not rounded
-    where they appear as values, but will usually hold rounded values, either from
-    the expressions where they are bound or from rounded program inputs.
+    Casts behave identically to applying the identity function (and
+    then rounding the result).
   </p>
 
   <p>
     FPCore does not restrict the behavior of the rounding function or the set
     of metadata properties that its behavior depends on. Some common precision
     and rounding direction properties are described for the metadata properties
-    <a href="metadata-1.1.html#p:precision"><code>:precision</code></a> and <a href="metadata-1.1.html#p:round"><code>:round</code></a>.
-    Tools are not required to support all of these rounding behaviors, and are allowed
-    to introduce new ones and new metadata properties to control them.
+    <a href="metadata-1.1.html#p:precision"><code>:precision</code></a>
+    and <a href="metadata-1.1.html#p:round"><code>:round</code></a>.
+    Tools are not required to support all of these rounding behaviors,
+    and are allowed to introduce new ones and new metadata properties
+    to control them.
   </p>
 
+  <aside>
+    The same precision context can be specified in multiple ways.
+    FPBench will provide tools to transform rounding contexts into
+    normal forms.
+  </aside>
+
   <p>
-    Similarly, FPCore does not restrict the representation used internally by a tool
-    to store values. Numeric values can be floating-point values of various precisions,
-    fixed-point values, or symbolic representations of mathematical real numbers. This specification
-    uses mathematical reals as a universal way to describe the value of any representation,
-    but tools are not required to be able to represent arbitrary real numbers exactly.
+    Rounding contexts are initialized with the properties of the
+    overall FPCore benchmark and are updated with
+    <code>!</code> annotations. Program inputs can also be annotated
+    to describe the precision of the input.
+    <code>!</code> use lexical scoping. For example, in the expression
   </p>
 
-  </section>
-
-  <section id="examples">
-  <h3>Examples</h3>
-
-  <dl class="code-terms">
-    <dt id="e:casting">Rounding with <code>cast</code></dt>
-    <dd>
-      <p>
-        The <code>cast</code> operation is necessary for explicitly rounding values
-        without performing other numerical operations. Precision annotations specified
-        with <code>!</code> never cause any numerical operations to occur; they only
-        change the rounding context.
-      </p>
-
-      <p>
-        For example, the expression
-      </p>
-
-      <figure>
-        <pre><code>(! :precision binary64 (! :precision binary32 x))</code></pre>
-      </figure>
-
-      <p>
-        will not round the value of the variable <code>x</code>. This expression is the
-        same as simply specifying
-      </p>
-
-      <figure>
-        <pre><code>x</code></pre>
-      </figure>
-
-      <p>
-        regardless of the rounding context. To round <code>x</code>, it is necessary
-        to <code>cast</code> it in a context with the desired precision. The expression
-      </p>
-
-      <figure>
-        <pre><code>(! :precision binary64 (! :precision binary32 (cast x)))</code></pre>
-      </figure>
-
-      <p>
-        will round <code>x</code> to <code>binary32</code> precision (here the outer
-        annotation for <code>binary64</code> precision is redundant, as it will be overwritten by the
-        inner one), while the expression
-      </p>
-
-      <figure>
-        <pre><code>(! :precision binary64 (cast (! :precision binary32 (cast x))))</code></pre>
-      </figure>
-
-      <p>
-        will round <code>x</code> twice, first to <code>binary32</code> precision, and then from <code>binary32</code>
-        to <code>binary64</code> precision.
-      </p>
-
-      <p>
-        Because numerical operations already round their outputs, it should not be necessary
-        to <code>cast</code> in most cases, unless double rounding is specifically intended.
-        For example, in an expression such as
-      </p>
-
-      <figure>
-        <pre><code>(! :precision binary64
-  (let ([ x (+ y 1)])
-    x))</code></pre>
-      </figure>
-
-      <p>
-        the value stored in x will already be rounded to <code>binary64</code> precision,
-        as the addition is done in a context with that precision. Inserting an explicit
-        <code>cast</code> around either the addition or the use of <code>x</code> would
-        cause double rounding, and while in the case of <code>binary64</code> precision
-        this is a no-op, for other rounding contexts it could lead to undesirable behavior.
-      </p>
-    </dd>
-
-    <dt id="e:inheritance">Inheriting properties in rounding contexts</dt>
-    <dd>
-      <p>
-        All properties not explicitly specified in a <code>!</code> precision annotation
-        are inherited from the parent context. For the top level expression in an
-        FPCore benchmark, the parent context includes all the overall properties of the benchmark.
-      </p>
-
-      <p>
-        For example, in the following benchmark
-      </p>
-
-      <figure>
-        <pre><code class="fpcore">(FPCore ()
- :name "foo"
- :math-library gnu-libm-2.34
- :spec 0
-  (! :precision binary64 (sin PI)))</code></pre>
-      </figure>
-
-      <p>
-        the <code>sin</code> operation will take place in a context with <code>name</code>
-        <code>"foo"</code>, <code>math-library</code> <code>gnu-libm-2.34</code>, <code>spec</code> 0, and
-        <code>binary64</code> precision. Even properties that are seemingly unrelated to
-        rounding, such as the name of the benchmark, are inherited. The FPCore standard does
-        not prohibit tools from implementing rounding functions that depend on these properties,
-        or other tool-specific properties, although having a rounding function that depends on
-        <code>name</code> is not advised.
-      </p>
-
-      <p>
-        Properties in the rounding context might come from multiple different annotations. For example,
-        in the expression
-      </p>
-
-      <figure>
-        <pre><code>(! :math-library gnu-libm-2.34 (! :round toZero (! :precision binary32 (+ x 1))))</code></pre>
-      </figure>
+  <figure>
+    <pre><code>(! :precision binary64 :round nearestEven
+  (let ([ y (! :precision binary32 (- x 1))])
+    (+ y 1)))))</code></pre>
+  </figure>
 
-      <p>
-        the addition will take place as expected in a context with <code>binary32</code> precision,
-        <code>toZero</code> rounding direction, and the <code>gnu-libm-2.34</code> math library. This
-        can be useful if some, but not all, of the properties are shared by multiple subexpressions.
-        For example, in the expression
-      </p>
+  <p>
+    the subtraction will take place in a context
+    with <code>binary32</code> precision, but the addition will take
+    place in a context that has inherited <code>binary64</code>
+    precision from the annotation enclosing the
+    entire <code>let</code>. Both operations will take place in a
+    context that has inherited <code>nearestEven</code> rounding
+    behavior. The <a href="examples-1.1.html#inheriting">examples</a>
+    contain more details.
+  </p>
 
-      <figure>
-        <pre><code>(! :precision binary64 (- (! :round toPositive (+ x y)) (! :round toNegative (+ x y))))</code></pre>
-      </figure>
+  <p>
+    If tools do not support the rounding context specified for a
+    computation, the result is undefined, and the tool should give
+    some indication of the reason for the failure. FPCore does not
+    restrict the representation used internally by a tool to store
+    values. Numeric values can be floating-point values of various
+    precisions, fixed-point values, intervals, or any sort of symbolic
+    representations of mathematical real numbers. Though FPCore can
+    represent exact real computations, tools are not required to be
+    able to represent arbitrary real numbers exactly.
+  </p>
 
-      <p>
-        all of the operations will take place in a context with <code>binary64</code> precision, but the additions
-        will use different rounding directions.
-      </p>
-    </dd>
-  </dl>
   </section>
 </section>
 
 </main>
+</body>
+</html>
diff --git a/spec/index.html b/spec/index.html
index 8ac4a22..7573714 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -20,36 +20,35 @@ <h1>FPBench Standards</h1>
     listed on here.
   </p>
 
+  <h2>FPBench 1.1 (Draft)</h2>
+  
+  <p>FPBench 1.1 adds support for mixed-precision computations and clarifies the semantics of rounded operations.</p>
+
   <ul>
-    <li>FPBench 1.1 Standards (DRAFT VERSION):
-      <ul>
-        <li><a href="fpcore-1.1.html">FPCore benchmark format</a></li>
-        <li><a href="metadata-1.1.html">FPCore metadata properties</a></li>
-        <li><a href="measures-1.1.html">FPBench standard measures</a></li>
-      </ul>
-      Changes:
-      <ul>
-        <li>Support for multiple and mixed-precision computations</li>
-        <li>Semantics of numerical operations clarified as rounded real operations</li>
-        <li>Precision can be specified per-operation using the rounding context</li>
-        <li>New constant formats, including rational numbers and hexadecimal floating-point</li>
-        <li>New metadata properties <code>:round</code> and <code>:spec</code></li>
-      </ul>
-    </li>
+    <li><a href="fpcore-1.1.html">FPCore 1.1</a>: syntax and semantics for benchmarks.</li>
+    <li><a href="examples-1.1.html">Examples 1.1</a>: FPCore example inputs</a></li>
+    <li><a href="metadata-1.1.html">Metadata 1.1</a>: descriptive properties for benchmarks</li>
+    <li><a href="measures-1.1.html">Measures 1.1</a>: standard error measurements</li>
   </ul>
 
-  <p>
-    Previous versions of the standards:
-  </p>
+  <h3>Changes:</h3>
+  <ul>
+    <li>Support for multiple and mixed-precision computations</li>
+    <li>Semantics of numerical operations clarified as rounded real operations</li>
+    <li>Precision can be specified per-operation using the rounding context</li>
+    <li>New constant formats, including rational numbers and hexadecimal floating-point</li>
+    <li>New metadata properties <code>:round</code> and <code>:spec</code></li>
+  </ul>
+
+  <h2>FPBench 1.0</h2>
+
+  <p>FPBench 1.0 introduced a common format for floating point computations and standard measures for their accuracy.</p>
 
   <ul>
-    <li>FPBench 1.0 Standards:
-      <ul>
-        <li><a href="fpcore-1.0.html">FPCore benchmark format</a></li>
-        <li><a href="metadata-1.0.html">FPCore metadata properties</a></li>
-        <li><a href="measures-1.0.html">FPBench standard measures</a></li>
-      </ul>
-    </li>
+    <li><a href="fpcore-1.0.html">FPCore 1.0</a>: syntax and semantics for benchmarks.</li>
+    <li><a href="metadata-1.0.html">Metadata 1.0</a>: descriptive properties for benchmarks</li>
+    <li><a href="measures-1.0.html">Measures 1.0</a>: standard error measurements</li>
   </ul>
+
 </body>
 </html>
diff --git a/spec/measures-1.1.html b/spec/measures-1.1.html
index fc5bfa6..de32e2a 100644
--- a/spec/measures-1.1.html
+++ b/spec/measures-1.1.html
@@ -28,6 +28,7 @@ <h1>FPBench 1.1 standards</h1>
 
   <ol>
     <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="examples-1.1.html">FPCore example inputs</a></li>
     <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
     <li><a href="measures-1.1.html">Standard measures of error</a></li>
   </ol>
diff --git a/spec/metadata-1.1.html b/spec/metadata-1.1.html
index 026a01d..a916b9b 100644
--- a/spec/metadata-1.1.html
+++ b/spec/metadata-1.1.html
@@ -28,6 +28,7 @@ <h1>FPBench 1.1 standards</h1>
 
   <ol>
     <li><a href="fpcore-1.1.html">The FPCore input format</a></li>
+    <li><a href="examples-1.1.html">FPCore example inputs</a></li>
     <li><a href="metadata-1.1.html">Metadata for FPCore benchmarks</a></li>
     <li><a href="measures-1.1.html">Standard measures of error</a></li>
   </ol>

From ceffd83c3ff97ae968361d4bdb9379540299c286 Mon Sep 17 00:00:00 2001
From: Bill Zorn <bill.zorn@gmail.com>
Date: Wed, 15 Aug 2018 18:08:14 -0700
Subject: [PATCH 5/5] typo?

---
 spec/fpcore-1.1.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spec/fpcore-1.1.html b/spec/fpcore-1.1.html
index c5fc382..404732f 100644
--- a/spec/fpcore-1.1.html
+++ b/spec/fpcore-1.1.html
@@ -458,7 +458,7 @@ <h3>Rounding</h3>
     overall FPCore benchmark and are updated with
     <code>!</code> annotations. Program inputs can also be annotated
     to describe the precision of the input.
-    <code>!</code> use lexical scoping. For example, in the expression
+    <code>!</code> annotations use lexical scoping. For example, in the expression
   </p>
 
   <figure>

Supported Mathematical Operations
+	-	*	/	fabs
fma	exp	exp2	expm1	log
log10	log2	log1p	pow	sqrt
cbrt	hypot	sin	cos	tan
asin	acos	atan	atan2	sinh
cosh	tanh	asinh	acosh	atanh
erf	erfc	tgamma	lgamma	ceil
floor	fmod	remainder	fmax	fmin
fdim	copysign	trunc	round	nearbyint
Supported Testing Operations
<	>	<=	>=	==
!=	and	or	not	isfinite
isinf	isnan	isnormal	signbit
Supported Mathematical Constants
E	LOG2E	LOG10E	LN2	LN10
PI	PI_2	PI_4	1_PI	2_PI
2_SQRTPI	SQRT2	SQRT1_2	INFINITY	NAN
Supported Boolean Constants
TRUE	FALSE