Skip to content

Commit

Permalink
Merge pull request FPBench#2 from FPBench/fpbench1.1
Browse files Browse the repository at this point in the history 
Draft version of FPBench 1.1 standards.
  • Loading branch information
@pavpanchekha
pavpanchekha authored Aug 16, 2018
2 parents 7824443 + ceffd83 commit 539c4e0
Show file tree
Hide file tree
Showing 6 changed files with 1,055 additions and 7 deletions.
1 change: 1 addition & 0 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down
168 changes: 168 additions & 0 deletions spec/examples-1.1.html
View file
Original file line number Diff line number Diff line change
@@ -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>
Loading

0 comments on commit 539c4e0

Please sign in to comment.