On Wed, Mar 6, 2013 at 6:28 PM, John Reiser <jrei...@bitwagon.com> wrote:
>> long double i;
>
>> for(i=1.L ; i < 1.00000000001L ; i=nextafterl(i, 5.L))
>
>> On valgrind it just hangs (e.g. if you pass in a |double| casted to
>> |long double| into |nextafterl()|'s first argument and then cast the
>> |long double| result to |double| then the result is usually identical
>> to the input value... as result the algorithm is stuck in an endless
>> loop).
>
> Noticing the unexpected i == nextafter(i, ...) is one of the checks
> performed by higher-quality software when verifying the execution environment
> before launching into lengthy computations that depend on that environment.
Huh ? My example never used "==" anywhere (first guess is that the
mail body encoding used "==" to represent a single '=' character) ...
and using '"==" to compare a floating-point value against another
value is likely not going to generate the results you may expect...
... which is more or less a deja-vu since we had that topic in the
AT&T AST/ksh93 development list:
---------- Forwarded message ----------
From: Roland Mainz <roland.ma...@nrubsig.org>
Date: Fri, Feb 8, 2013 at 12:48 PM
Subject: [ast-users] Floating-point arithmetic, rounding and testing
for equality... / was: Re: Fwd: Floating point oddities with pow()?
Accuracy problem?
Cc: ast-users <ast-us...@research.att.com>, ast-develop...@research.att.com
[snip]
> What we're facing here seems that different implementations of a libm
> function may result different results at the last digits, right? Is
> there a function to test how accurate the libm functions are, and is
> there a libm function which tests for equality in a specified
> precision?
Testing whether two _floating_point_-values are equal is a tricky
business (e.g. the C99/ksh93 operator "==" is usually of little use...
;-( ) because of the rounding errors or (AFAIK in your case when the
i387 version of IEEE 754-2008 floating-point values are used) extra
precision caused by the issue that |long double| is 80bit on x86/AMD64
but some machine instructions have extra bits available during
calculation (like the new FMA instructions vs. a "manual"
multiply–accumulate operation... or |pow()| vs. manual "power of" ...)
or the registers have more bits than they store in memory.
Another issue may be (or often is) the base10<---->base2 conversion
which causes rounding errors when strings are converted to IEEE
754-2008 floating-point values and back. As "fix" C99 ([1]) added the
printf "%a" format to represent floating-point values in a hexadecimal
floating-point representation which can be used (with your example) to
"visualise" the issue that the difference is usually off by one or two
bits at the trailing end.
Keeping the email short (due lack of time... I may try a more detailed
answer when I have time) ... the standards only define |isgreater()|,
|isgreaterequal()|, |islessequal()|, |islessgreater()|,
|isunordered()| but intentionally no |isequal()| because the same
operation using different implementations is usually unlikely to
result in _exactly_ the same result.
A quick&&dirty implementation for a |isequal()| (maybe a better term
may be |isnearequal()|) may look like this (ksh93 syntax):
-- snip --
# test whether values in variables "a" and "b" are
# "equal" with a precision of 0.000001
if (( fabs(a - b) < 0.000001 )) ; then
-- snip --
(yes yes... I'm using the wrong mathematical terms (e.g. "precision" ?
"resolution" ? "distance" ?) in this case... please correct me... ;-(
)
[1]=ksh93 supports C99 "hexfloat" via it's printf builtin (note that
you have to use $ float varname ; ... ; printf "%a\n" varname # and
NOT $ float varname ; ... ; printf "%a\n" ${varname} # because the
${varname} means that the internal IEEE 754-2008 floating-point value
is converted to a base10 floating-point string value first and THEN
passed to the printf builtin utility) and via $ typeset -lX varname #
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-users mailing list
ast-us...@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-users
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
