| View previous topic :: View next topic |
| Author |
Message |
Chip Coldwell
Guest
|
 Posted: Sat Oct 20, 2007 12:19 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
 |
|
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
| Quote: | Chip Coldwell wrote:
(snip)
Personally, I am of the opinion that any
operation that returns a floating point value should return NaN if any
operand is NaN -- NaN is like a trap door that once you have fallen in
you cannot come back out. Otherwise, the possibility exists that a
calculation will have gone off course undetectably.
The possibly also exists that at went NaN needlessly.
I would say that, at least for some operations, the programmer
should have the choice.
For comparison, consider compilers that give up on the first
syntax error and those that try to keep compiling to give the
programmer the most information per compilation run.
There must be at least some cases where some result is better
than all NaN at the end of a long calculation.
|
NaN already does this. You have always had the option of trapping
floating point exceptions such that your process halts on the first
invalid operand (e.g. max(x,NaN)) or continues with NaN plugged in
where there cannot be a more meaningful number (e.g. log(0)). At the
end of hours of computation, maybe some of your results are
meaningful, but at least the ones that are not are clearly marked as
such.
Getting back to Nick's point, the question is what does NaN mean? If
it means "invalid operand" such as sqrt(-1) or log(0), then I can
think of no reason why max(x,sqrt(-1)) should be anything other than
NaN. If it means "no value was supplied", well that's different, but
that's a new meaning to attach to NaN than I ever heard previously.
| Quote: | Also, as Nick mentions, NaN isn't the best choice for a missing
value in many statistical calculations, but it is used because
it is there. Maybe a new type of NaN for statistical calculation
could be added?
|
Well, let's call it NaV ("not a value"). Then
max(x,NaV) = x
min(x,NaV) = x
(x > NaV) is true (to be consistent with max)
(x < NaV) is true (to be consistent with min)
(NaV > NaV) is ?
(NaV == NaV) is ?
There are spare bits in the NaN representation that could be used to
differentiate between NaN and NaV at the risk of breaking backward
combatibility.
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England |
|
| |
|
 Back to top |
Nick Maclaren
Guest
|
| Posted: Sat Oct 20, 2007 12:42 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
In article <rzpir52j4ja.fsf@bogart.boston.redhat.com>,
Chip Coldwell <coldwell@gmail.invalid> writes:
|>
|> Well, let's call it NaV ("not a value"). Then
|>
|> max(x,NaV) = x
|> min(x,NaV) = x
|> (x > NaV) is true (to be consistent with max)
|> (x < NaV) is true (to be consistent with min)
|> (NaV > NaV) is ?
|> (NaV == NaV) is ?
Not really. In the traditional and mathematically consistent model,
NaVs percolate much like NaNs, but are subordinate to them. E.g.
NaV+NaN = NaN. The ONLY difference is in reduction operations.
In those, only non-NaVs are considered. count() gives the count of
non-NaVs. Most others return a NaN (sic) if there are only NaVs,
and use only the non-NAVs otherwise. var() requires two non-NAVs.
Etc.
|> There are spare bits in the NaN representation that could be used to
|> differentiate between NaN and NaV at the risk of breaking backward
|> combatibility.
Yes. But, given the degree of brokenness in current software support,
I doubt that many people would notice.
Regards,
Nick Maclaren. |
|
| |
|
| Back to top |
glen herrmannsfeldt
Guest
|
| Posted: Sat Oct 20, 2007 1:11 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
Chip Coldwell wrote:
(snip)
| Quote: | Personally, I am of the opinion that any
operation that returns a floating point value should return NaN if any
operand is NaN -- NaN is like a trap door that once you have fallen in
you cannot come back out. Otherwise, the possibility exists that a
calculation will have gone off course undetectably.
|
The possibly also exists that at went NaN needlessly.
I would say that, at least for some operations, the programmer
should have the choice.
For comparison, consider compilers that give up on the first
syntax error and those that try to keep compiling to give the
programmer the most information per compilation run.
There must be at least some cases where some result is better
than all NaN at the end of a long calculation.
Also, as Nick mentions, NaN isn't the best choice for a missing
value in many statistical calculations, but it is used because
it is there. Maybe a new type of NaN for statistical calculation
could be added?
-- glen |
|
| |
|
| Back to top |
Greg Lindahl
Guest
|
| Posted: Sat Oct 20, 2007 1:19 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
In article <rzpy7dygc1a.fsf@bogart.boston.redhat.com>,
Chip Coldwell <coldwell@gmail.invalid> wrote:
| Quote: | Testing for NaN is not an
expensive operation, as was already pointed out in this thread.
|
It would make max() significantly slower, which is why few (or no?)
compilers do it that way. And, you know, we had this entire
conversation at least once before.
-- greg |
|
| |
|
| Back to top |
Chip Coldwell
Guest
|
| Posted: Sat Oct 20, 2007 1:25 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
lindahl@pbm.com (Greg Lindahl) writes:
| Quote: | In article <rzpy7dygc1a.fsf@bogart.boston.redhat.com>,
Chip Coldwell <coldwell@gmail.invalid> wrote:
Testing for NaN is not an
expensive operation, as was already pointed out in this thread.
It would make max() significantly slower, which is why few (or no?)
compilers do it that way. And, you know, we had this entire
conversation at least once before.
|
Could you supply a pointer?
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England |
|
| |
|
| Back to top |
Nick Maclaren
Guest
|
| Posted: Sat Oct 20, 2007 1:29 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
In article <47191166$1@news.meer.net>, lindahl@pbm.com (Greg Lindahl) writes:
|> In article <rzpy7dygc1a.fsf@bogart.boston.redhat.com>,
|> Chip Coldwell <coldwell@gmail.invalid> wrote:
|>
|> > Testing for NaN is not an
|> > expensive operation, as was already pointed out in this thread.
|>
|> It would make max() significantly slower, which is why few (or no?)
|> compilers do it that way. And, you know, we had this entire
|> conversation at least once before.
If you are allowed to get the wrong answer, you can make programs
run arbitrarily fast.
While it does make the cases where it is the correct action faster,
it makes the more common ones where it is the wrong one slower.
What sort of code do YOU favour?
#define bluemax(x,y) (isnan(x)||isnan(y)?NAN:max((x),(y))
#define bygraves(x,y) ((x)>=(y)?(x) (x)<(y)?(y):NAN))
or what?
Regards,
Nick Maclaren. |
|
| |
|
| Back to top |
glen herrmannsfeldt
Guest
|
| Posted: Sat Oct 20, 2007 1:56 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
Chip Coldwell wrote:
(snip)
| Quote: | If you want "max(x,NaN) = x", then
float max(float x, float y)
{
if (isnan(x))
return y;
else if (isnan(y))
return x;
else return (x > y ? x : y);
}
and we're done, right? We have a broken programming language
intrinsic built upon flawless hardware. Testing for NaN is not an
expensive operation, as was already pointed out in this thread. The
question in my mind is what should the behavior of the IEEE 754/854
compliant FPU (or vector coprocessor, e.g. SSE) be?
|
Can it be done with conditional load on processors that
do that? max is easy to implement with conditional load, load
the first value, then conditional load the second if it is
greater (and maybe if equal) to the first. It gets a lot
more complicated if you want NaN to work out right.
Note that C89 doesn't even have max, but expects:
#define MAX(a,b) ((a)>(b)?(a)b))
-- glen |
|
| |
|
| Back to top |
Terje Mathisen
Guest
|
| Posted: Sat Oct 20, 2007 2:47 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
Chip Coldwell wrote:
| Quote: | I am cross-posting on comp.arch.arithmetic in the hopes that someone
there can shed some light on this issue. To summarize, the question
is whether
max(x,NaN)
should return x or NaN. The IEEE 754r standard clearly states that it
should return x; there seems to be a growing consensus on c.l.f that
this is completely bogus.
|
We discussed this issue a while ago, mostly we seemed to agree with you.
The key problem is that some people would like NaN to mean:
"There is no value here, nothing to see. Please move on!"
and this is a more or less orthogonal issue to the Not a Number which is
the result of several undefined mathematical operations.
Trying to make NaN ("because it is what we have") do something which it
was never designed for is a stupid idea, imho.
Personally, I am of the opinion that any
| Quote: | operation that returns a floating point value should return NaN if any
operand is NaN -- NaN is like a trap door that once you have fallen in
you cannot come back out. Otherwise, the possibility exists that a
calculation will have gone off course undetectably.
|
Exactly the way I believe NaN should work.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| |
|
| Back to top |
Chip Coldwell
Guest
|
| Posted: Sat Oct 20, 2007 3:23 am Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
| Quote: | Chip Coldwell wrote:
I am cross-posting on comp.arch.arithmetic in the hopes that someone
there can shed some light on this issue. To summarize, the question
is whether
max(x,NaN)
should return x or NaN. The IEEE 754r standard clearly states that it
should return x; there seems to be a growing consensus on c.l.f that
this is completely bogus.
We discussed this issue a while ago, mostly we seemed to agree with you.
|
Yes, I found some of this here
http://groups.google.com/group/comp.arch.arithmetic/browse_thread/thread/5d3e430672844b68/444fa172ae3efef5
| Quote: | The key problem is that some people would like NaN to mean:
"There is no value here, nothing to see. Please move on!"
and this is a more or less orthogonal issue to the Not a Number which
is the result of several undefined mathematical operations.
Trying to make NaN ("because it is what we have") do something which
it was never designed for is a stupid idea, imho.
|
Yes. What they want is some other sentinel value. Unfortunately,
IIUC, all the possibilities are spoken for.
For an example of current practice, take the Intel SIMD MAXPD (Return
Maximum Packed Double-Precision Floating Point Values) instruction.
Here's what it says:
"If a value in the second operand [source] is an SNaN, that SNaN is
forwarded unchaged to the destination (that is, a QNaN version of the
SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the
second operand (source operand), either a NaN or a valid
floating-point value, is written to the result. If instead of this
behavior, it is required that the NaN source operand (from either the
first or second operand) be returned, the action of the MAXPD can be
emulated using a sequence of instructions, such as, a comparison
followed by AND, ANDN and OR."
I think they've managed to violate all the published standards with
that one.
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England |
|
| |
|
| Back to top |
Terje Mathisen
Guest
|
| Posted: Sat Oct 20, 2007 10:31 pm Post subject: Re: Fortran / IEEE 754: MAXVAL and INF, NaN |
|
|
Chip Coldwell wrote:
| Quote: | For an example of current practice, take the Intel SIMD MAXPD (Return
Maximum Packed Double-Precision Floating Point Values) instruction.
Here's what it says:
|
I have actually read all of those manuals, x86 asm being almost a way of
life for me.
| Quote: |
"If a value in the second operand [source] is an SNaN, that SNaN is
forwarded unchaged to the destination (that is, a QNaN version of the
SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the
second operand (source operand), either a NaN or a valid
floating-point value, is written to the result. If instead of this
behavior, it is required that the NaN source operand (from either the
first or second operand) be returned, the action of the MAXPD can be
emulated using a sequence of instructions, such as, a comparison
followed by AND, ANDN and OR."
I think they've managed to violate all the published standards with
that one.
|
The MAXPD opcode description sounds more like a "This is what we managed
to implement within the transistor/time budget. Deal with it!" than a
useful standard.
When I read that description the first time, I concluded that what they
meant to say was "We don't handle NaN's here, so don't write code that
depends on them."
....
Actually, there is a useful way to use this opcode safely, and that is
for a saturating range check, where the first operand is the limit to be
tested against:
I.e. SIMD code like this
;; xmm0 has the pair of results from a series of calculations,
;; now bracket them:
movapd xmm1,[lower_limit]
maxpd xmm1, xmm0
movapd xmm0,[higher_limit]
minpd xmm0, xmm1
This sequence will leave any incoming NaNs in xmm0, all other values
will be brought into the [lower_limit..higher_limit] range.
With working opcodes, or no NaN handling, the code would be simpler &
faster:
maxpd xmm0,[lower_limit]
minpd xmm0,[higher_limit]
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| |
|
| Back to top |
Guest
|
| Posted: Fri Jun 20, 2008 7:47 pm Post subject: Re: How do I find out what C's long double is? |
|
|
float.h also #defines FLT_EPSILON, DBL_EPSILON, and LDBL_EPSILON
where:
FLT_EPSILON is the smallest float such that 1.0F+FLT_EPSILON != 1.0F
DBL_EPSILON is the smallest double such that 1.0F+DBL_EPSILON != 1.0
LDBL_EPSILON is the smallest long double such that 1.0L
+LDBL_EPSILON != 1.0L
Presuming radix 2 floating-point:
The number of bits of significand in a float, including a hidden MS
bit, if there is one, is 1-log2(FLT_EPSILON).
The number of bits of significand, in a double, including a hidden
MS
bit, if there is one is 1-log2(DBL_EPSILON).
The number of bits of significant, in a long double, including a
hidden MS bit, if there is one is 1-log2(LDBL_EPSILON).
If you don't have a reliable log2() function which give you an exact
integer when its argument is 2 raised to a negative integer power, you
might look into using the standard C library functions frexpf() (for
float), frexp() (for double), and frexpl() (for long double).
For example
int exponent;
double significand;
if (frexp(DBL_EPSILON, &exponent) == 0.5)
{
int log2_dbl_epsilon, significand_bits;
log2_dbl_epsilon = exponent - 1;
printf("log2(DBL_EPSILON) = %d\n", log2_dbl_epsilon);
significand_bits = 1 - log2_dbl_epsilon;
printf("A double has %d bits of significand.\n",
significand_bits);
}
else
printf("DBL_EPSILON is not an integral power of 2.);
-Michael |
|
| |
|
| Back to top |
|
