Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
U
uva
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Taddeüs Kroes
uva
Commits
7a7b83d6
Commit
7a7b83d6
authored
Feb 09, 2011
by
Taddeüs Kroes
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Finished question 3.
parent
366afca4
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
32 additions
and
0 deletions
+32
-0
simmod/ass1/report.tex
simmod/ass1/report.tex
+32
-0
No files found.
simmod/ass1/report.tex
View file @
7a7b83d6
...
...
@@ -104,6 +104,10 @@ Type & Operator & Million ops/sec \\
\section
{
Summation
}
% {{{
\label
{
sec:Summation
}
We've calculated
$
\sum
_{
i
=
1
}^{
N
}
\frac
{
1
}{
i
}$
for
$
N
=
10
^
8
$
and
$
N
=
2
\cdot
10
^
8
$
using a forward and backward summation approach, with data types
\texttt
{
float
}
and
\texttt
{
double
}
. The results of this are in the table below.
\begin{table}
[H]
\begin{tabular}
{
l|lll
}
Type
&
N
&
Forward
&
Backward
\\
...
...
@@ -116,6 +120,34 @@ Type & N & Forward & Backward \\
\caption
{
Results of various summation approaches on floats and doubles.
}
\end{table}
\noindent
\textbf
{
Observations
}
\begin{itemize}
\item
Since the results for the
\texttt
{
double
}
datatype are eaqual for both
the forward and backward summation approach, we can say that these are the
correct results.
\item
For the
\texttt
{
float
}
data type, we observe that the backward approach
yields a higher result than the forward approach. This can be explained as
follows. When using the forward approach, we start with a small
$
i
$
, thus
with a large
$
1
/
i
$
. This means that the initial value of
\texttt
{
sum
}
is
large. The value will keep growing untill the significance of
$
1
/
i
$
is too
small to add to the result. From this point, no more
$
1
/
i
$
will be added to
the result because the significane of the individual numbers is too small.
However, the sum of the ignored numbers would be a large enough number to
add to the result. This is why the backward approach yields a higher number:
the sum of the ignored numbers is computed and later the larger numbers
are added. The remaining inprecision is probably due to rounding problems and
the fact that
$
1
/
10
^
8
$
and a range of larger numbers are represented as
zeroes in
\texttt
{
float
}
representation and therefore not added to the
result. This problem does not occur when using the
\texttt
{
double
}
data type
which has a higher precision, therefore yielding the (correct) higher
result.
\item
We can see that both approaches yield the same result for
$
N
=
10
^
8
$
and
$
N
=
2
\cdot
10
^
8
$
when using the
\texttt
{
float
}
data type. This is due
to the same problem as described above: all numbers in
$
[
\frac
{
1
}{
10
^
8
}
,
\frac
{
1
}{
2
\cdot
10
^
8
}
]
$
are also represented as zero and therefore not added
to the result.
\end{itemize}
% }}}
\end{document}
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment