OK, I realize that what I am asking here is not likely to have a
answer within the C standard. Nonetheless, it is not specific
to any particular platform, so I'll hazard the question anyway.
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
Allin Cottrell
Wake Forest University
21  4165 
>OK, I realize that what I am asking here is not likely to have a answer within the C standard. Nonetheless, it is not specific
to any particular platform, so I'll hazard the question anyway.
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
NO.
However, many implementations use IEEE floating point, which has a
oddball value (or set of values) called a NaN (Not A Number). If
it is available on your implementation, this is a reasonable candidate
for an invalid value. Further, arithmetic with a NaN almost always
results in a NaN.
double x;
... put a value in x ...;
if (x != x ) { ... you have a NaN here ... ; }
(some compilers might get this wrong, though.)
Some ways to get hold of a NaN include 0.0/0.0 and log(0.0). Note
that the "most portable" way does NOT involve overlaying a double
with bytes and stuffing something into the bytes.
Other possibilities include using a very large positive or negative
value, which cannot possibly be a valid value. For example, 1.0e30
is likely not a valid value for an electric bill balance, but it
might get you in the news if you mistakenly send one out for that
amount anyway. 1.0e30 is also within the ANSI C minimum range for
float and double.
Gordon L. Burditt OK, I realize that what I am asking here is not likely to have a
answer within the C standard. Nonetheless, it is not specific
to any particular platform, so I'll hazard the question anyway.
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
NO.
However, many implementations use IEEE floating point, which has a
oddball value (or set of values) called a NaN (Not A Number). If
it is available on your implementation, this is a reasonable candidate
for an invalid value. Further, arithmetic with a NaN almost always
results in a NaN.
Yep. Import is the *almost*; can give you some cheesy errors.
Nice story on the side: A colleague of mine once had the problem that
a "matrix" he was working with suddenly seemed only able to hold 0.0
as values. After searching for some time he came to me and we went
through with the debugger, finding that at one particular point the
"matrix" (still filled with zeros) scaled with 1/inf and all the zeros
got into a sort of NaN state but did not print as NaNs as all other NaNs
would have...
Not the same problem, I know, but I think it is good to know that
these things still can happen with IEEE FPs...
double x;
... put a value in x ...;
if (x != x ) { ... you have a NaN here ... ; }
(some compilers might get this wrong, though.)
Some ways to get hold of a NaN include 0.0/0.0 and log(0.0). Note
that the "most portable" way does NOT involve overlaying a double
with bytes and stuffing something into the bytes.
Or you can use the isnan() macro from <math.h>
(I am not sure at the moment whether this is only there in C99 or not)
Other possibilities include using a very large positive or negative
value, which cannot possibly be a valid value. For example, 1.0e30
is likely not a valid value for an electric bill balance, but it
might get you in the news if you mistakenly send one out for that
amount anyway. 1.0e30 is also within the ANSI C minimum range for
float and double.
On another note: If you only want to flag that there is some
invalid value out there, you can use an errno-like mechanism and
check in a test mode after every assignment, perhaps even aborting
the program after throwing out the necessary info using assert(0).
Easier to do in a portable way.
If you really want to use you actual double values and are fairly
sure that you will only use IEEE doubles, produce a NaN and then
write to the lower 32 Bit of the mantissa whatever you think
befitting to signal the specific condition, e.g. 0xdeadbeef.
However, this information might not get to you as expected if there
are intermediate steps where the value gets loaded into some register
and written back.
Cheers
Michael
Allin Cottrell wrote:
OK, I realize that what I am asking here is not likely to have a
answer within the C standard. Nonetheless, it is not specific
to any particular platform, so I'll hazard the question anyway.
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
Instead of -999.0, use either HUGE_VAL or -HUGE_VAL, from math.h.
--
pete
In <cj***********@f1n1.spenet.wfu.edu> Allin Cottrell <co******@wfu.edu> writes: A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
Before IEEE 754, typical floating point representations had no invalid
bit patterns. A single rule was used for interpreting any bit pattern
(with the possible exception of all bits 0, which could be interpreted
as an exact representation of 0.0, regardless of the rule).
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
If you can afford in-band signalling, by all means, use it. DBL_MIN and
DBL_MAX are the most likely a priori candidates.
OTOH, if you can afford assuming IEEE 754 floating point (the PDP-11 is
dead, the VAX is dead, IBM mainframes might still be posing a problem)
you can choose Inf or NaN for this purpose. C99 has methods for testing
for them (isinf, isnan), but I don't know how portable they are to C89
implementations. Ditto for isfinite, which checks that a floating point
value is neither infinite nor a NaN.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
.... Before IEEE 754, typical floating point representations had no invalid
bit patterns. A single rule was used for interpreting any bit pattern
(with the possible exception of all bits 0, which could be interpreted
as an exact representation of 0.0, regardless of the rule).
What were typical floating point representations? I know that the
CDC Cyber, Cray 1, Vax and Gould all had a floating point bit pattern
that would never be generated by a valid operation, except perhaps on
overflow or things like that.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
... Before IEEE 754, typical floating point representations had no invalid
bit patterns. A single rule was used for interpreting any bit pattern
(with the possible exception of all bits 0, which could be interpreted
as an exact representation of 0.0, regardless of the rule).
What were typical floating point representations? I know that the
CDC Cyber, Cray 1, Vax and Gould all had a floating point bit pattern
that would never be generated by a valid operation, except perhaps on
overflow or things like that.
I'm not aware of any bit pattern that wouldn't represent a valid value for
the IBM 360, PDP-11 and the VAX. Ditto for certain representations used
on systems with no floating point hardware support.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes:
[...] OTOH, if you can afford assuming IEEE 754 floating point (the PDP-11 is
dead, the VAX is dead, IBM mainframes might still be posing a problem)
you can choose Inf or NaN for this purpose. C99 has methods for testing
for them (isinf, isnan), but I don't know how portable they are to C89
implementations. Ditto for isfinite, which checks that a floating point
value is neither infinite nor a NaN.
The VAX isn't entirely dead; I have an account on one running OpenVMS
6.2. At my previous job, we had a mix of VAX and Alpha boxes running
production code under OpenVMS, but they may have switched over to just
Alphas since then. (The Alpha, which is also approaching the end of
its lifetime, supports both VAX and IEEE floating-point formats.)
Cray has its own non-IEEE floating-point format as well, but most
(all?) of their newer systems use IEEE.
My knowledge is incomplete, but I suspect that IBM mainframes are the
last major holdout of non-IEEE floating-point.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
... Before IEEE 754, typical floating point representations had no invalid
bit patterns. A single rule was used for interpreting any bit pattern
(with the possible exception of all bits 0, which could be interpreted
as an exact representation of 0.0, regardless of the rule).
What were typical floating point representations? I know that the
CDC Cyber, Cray 1, Vax and Gould all had a floating point bit pattern
that would never be generated by a valid operation, except perhaps on
overflow or things like that.
I'm not aware of any bit pattern that wouldn't represent a valid value for
the IBM 360, PDP-11 and the VAX. Ditto for certain representations used
on systems with no floating point hardware support.
Note that I wrote "not generated", not "invalid". In IEEE there are also
no invalid bitpatterns. But whatever, from the PDP11/04/34/45/55/60
processor hndbook, 1978-1979, DEC 1978, page 250 (also valid for the VAX):
"The Undefined Variable
The undefined variable is any bit pattern with a sign bit of one and a
biased exponent of zero. The term undefined variable is used to
indicate that these bit patterns are not assigned a corresponding
floating point arithmetic value. An undefined variable is frequently
referred to as '-0' elsewhere in this chapter."
I do not have an IBM POP, but I think it will also generate only one
form of zero as the result of an operation, so that machine has also
many bit patterns that are not generated and can be used to indicate
an undefined variable. And I think that most software implementations
also represent 0.0 in a single way out of the many choices. Actually
I do only know two machines that have *no* pattern that cannot be
generated. One is the Electrologica X8 that prefers to generate -0.0,
but on occasion generates +0.0, and an old ICL machine that had no
representation for 0.0 (also a joy of course).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
pete wrote: Allin Cottrell wrote: I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
Instead of -999.0, use either HUGE_VAL or -HUGE_VAL, from math.h.
Thank to all for the suggestions. It seems that the above, or
DBL_MAX/DBL_MIN are probably the best bets for my situation.
Allin Cottrell
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes:
[...] OTOH, if you can afford assuming IEEE 754 floating point (the PDP-11 is
dead, the VAX is dead, IBM mainframes might still be posing a problem)
you can choose Inf or NaN for this purpose. C99 has methods for testing
for them (isinf, isnan), but I don't know how portable they are to C89
implementations. Ditto for isfinite, which checks that a floating point
value is neither infinite nor a NaN.
The VAX isn't entirely dead; I have an account on one running OpenVMS
6.2.
By this argument, the PDP-11 (or even the PDP-8) isn't entirely dead,
either.
The point is that VAX hardware hasn't been manufactured for almost a
decade, so any serious shop using VAXen has already migrated to something
else, even if the VAXen are still kept running until they break, for
one reason or another.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
...
> Before IEEE 754, typical floating point representations had no invalid
> bit patterns. A single rule was used for interpreting any bit pattern
> (with the possible exception of all bits 0, which could be interpreted
> as an exact representation of 0.0, regardless of the rule).
What were typical floating point representations? I know that the
CDC Cyber, Cray 1, Vax and Gould all had a floating point bit pattern
that would never be generated by a valid operation, except perhaps on
overflow or things like that.
I'm not aware of any bit pattern that wouldn't represent a valid value for
the IBM 360, PDP-11 and the VAX. Ditto for certain representations used
on systems with no floating point hardware support.
Note that I wrote "not generated", not "invalid".
I couldn't care less: you wrote "not generated" in reply to a post of mine
that didn't contain these words.
In IEEE there are also no invalid bitpatterns.
"Invalid" should be read in the context of the thread, i.e. not
representing any floating point value.
But whatever, from the PDP11/04/34/45/55/60
processor hndbook, 1978-1979, DEC 1978, page 250 (also valid for the VAX):
"The Undefined Variable
The undefined variable is any bit pattern with a sign bit of one and a
biased exponent of zero. The term undefined variable is used to
indicate that these bit patterns are not assigned a corresponding
floating point arithmetic value. An undefined variable is frequently
referred to as '-0' elsewhere in this chapter."
Why do they refer to it as -0 if it's not assigned a value?
I do not have an IBM POP, but I think it will also generate only one
form of zero as the result of an operation, so that machine has also
many bit patterns that are not generated and can be used to indicate
an undefined variable. And I think that most software implementations
also represent 0.0 in a single way out of the many choices. Actually
I do only know two machines that have *no* pattern that cannot be
generated. One is the Electrologica X8 that prefers to generate -0.0,
but on occasion generates +0.0, and an old ICL machine that had no
representation for 0.0 (also a joy of course).
The OP was looking for a bit pattern that could be reliably used
*everywhere* as not corresponding to any floating point value.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
....But whatever, from the PDP11/04/34/45/55/60
processor hndbook, 1978-1979, DEC 1978, page 250 (also valid for the VAX):
"The Undefined Variable
The undefined variable is any bit pattern with a sign bit of one and a
biased exponent of zero. The term undefined variable is used to
indicate that these bit patterns are not assigned a corresponding
floating point arithmetic value. An undefined variable is frequently
referred to as '-0' elsewhere in this chapter."
Why do they refer to it as -0 if it's not assigned a value?
Ask them. Anyhow, using such a value in an operation results in a trap.
The OP was looking for a bit pattern that could be reliably used
*everywhere* as not corresponding to any floating point value.
Not entirely true. He was asking for a value that could be used to
distinguish non-initialized valiables from initialized vairables
(note the mention of -999.0 commonly being used). A value that is
never generated by the processor could serve very well for such a
purpose.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: The OP was looking for a bit pattern that could be reliably used
*everywhere* as not corresponding to any floating point value.
Not entirely true. He was asking for a value that could be used to
distinguish non-initialized valiables from initialized vairables
(note the mention of -999.0 commonly being used). A value that is
never generated by the processor could serve very well for such a
purpose.
How do you store such a "value" in a variable in the first place?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: > The OP was looking for a bit pattern that could be reliably used
> *everywhere* as not corresponding to any floating point value.
Not entirely true. He was asking for a value that could be used to
distinguish non-initialized valiables from initialized vairables
(note the mention of -999.0 commonly being used). A value that is
never generated by the processor could serve very well for such a
purpose.
How do you store such a "value" in a variable in the first place?
By constructing it as an array of unsigned char, for example. The
phrase "never generated by the processor" is a mildly sloppy, but IMHO
sufficiently clear, way of saying "never generated by the processor
using any floating-point operation".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: The OP was looking for a bit pattern that could be reliably used
*everywhere* as not corresponding to any floating point value.
Not entirely true. He was asking for a value that could be used to
distinguish non-initialized valiables from initialized vairables
(note the mention of -999.0 commonly being used). A value that is
never generated by the processor could serve very well for such a
purpose.
How do you store such a "value" in a variable in the first place?
You are dense. Obviously I meant "never generated by the floating-point
part of the processor".
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
> In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
> >In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
> > > The OP was looking for a bit pattern that could be reliably used
> > > *everywhere* as not corresponding to any floating point value.
> >
> >Not entirely true. He was asking for a value that could be used to
> >distinguish non-initialized valiables from initialized vairables
> >(note the mention of -999.0 commonly being used). A value that is
> >never generated by the processor could serve very well for such a
> >purpose.
>
> How do you store such a "value" in a variable in the first place?
You are dense.
Nope.
Obviously I meant "never generated by the floating-point part of the
processor".
And this is how I interpreted it. But you called it a "value" and
objected to my treating it as a bit pattern. So, please make up your
mind.
I use "value" and "bit pattern" here interchangably. It was *not*
your use of "bit pattern" I objected to. It was your use of
"not corresponding to any floating point value" I objected to.
My usage was consistent to the OP's:
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
And, unless I'm missing something, you've been unable to produce such a
bit pattern, so your contributions to this thread have consisted of pure
noise...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
.... I use "value" and "bit pattern" here interchangably. It was *not*
your use of "bit pattern" I objected to. It was your use of
"not corresponding to any floating point value" I objected to.
My usage was consistent to the OP's:
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
And, unless I'm missing something, you've been unable to produce such a
bit pattern, so your contributions to this thread have consisted of pure
noise...
The OP continues with:
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
a bit pattern not generated by the floating point processor serves his
purpose very well.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
...I use "value" and "bit pattern" here interchangably. It was *not*
your use of "bit pattern" I objected to. It was your use of
"not corresponding to any floating point value" I objected to.
My usage was consistent to the OP's:
A C double can be aliased by an array of unsigned char, to which
any desired byte pattern may be written. Is there any somewhat
portable way of assigning a byte pattern such that the result
will, with very high probability, _not_ count as a valid double?
And, unless I'm missing something, you've been unable to produce such a
bit pattern, so your contributions to this thread have consisted of pure
noise...
The OP continues with:
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
a bit pattern not generated by the floating point processor serves his
purpose very well.
But you still have been unable to produce one, so you're merely generating
more noise.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
.... The OP continues with:
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
a bit pattern not generated by the floating point processor serves his
purpose very well.
But you still have been unable to produce one, so you're merely generating
more noise.
Darn. I have written that I know such patterns exist for the PDP 11, Vax,
Gould, Cray 1, CDC Cyber, and I know of only two processors for which they
definitely do not exist. So I have no idea what you are intending to say
here.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
> So I have no idea what you are intending to say here.
He's just being an asshole know-it-all, as usual.
In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes: In article <cj**********@sunnews.cern.ch> Da*****@cern.ch (Dan Pop) writes: In <I4********@cwi.nl> "Dik T. Winter" <Di********@cwi.nl> writes:
...The OP continues with:
I ask because I'm in search of a mechanism for flagging "missing
values" in an array of doubles. I'm aware that the "best" (fully
portable) way probably involves setting up an ancillary array, or
making the basic data-type not a straight double but a struct of
some sort. But in context this would be a royal pain. One
common solution is to flag "missing" with a specific value such
as -999.0. I'm wondering if that can be improved upon without
resorting to a wider data type.
a bit pattern not generated by the floating point processor serves his
purpose very well.
But you still have been unable to produce one, so you're merely generating
more noise.
Darn. I have written that I know such patterns exist for the PDP 11, Vax,
Gould, Cray 1, CDC Cyber, and I know of only two processors for which they
definitely do not exist. So I have no idea what you are intending to say
here.
One such bit pattern that works *portably*. Which is what the OS was
asking about.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Simon Reye |
last post by:
Is there a way to force a floating point value to be invalid? I'm
reading floating points from a device and every now and then I get an
invalid number, but it is too few and far between for me to...
|
by: Vinny |
last post by:
I have a few floating point questions/issues I wish to ask. An answer or
discussion would be nice too :) Any links discussion the subject would be
nice too..
1. How do I generate an underflow...
|
by: Anton Noll |
last post by:
We are using Visual Studio 2003.NET (C++) for the development
of our software in the fields digital signal processing and
numerical acoustics.
One of our programs was working correctly if we are...
|
by: jeff regoord |
last post by:
A user inputs a float value. The scanf() function gets the value.
However, I need to create an error handler with an if else statement
saying invalid input if the input is not a number. Does...
|
by: aegis |
last post by:
how can I take the fractional part of a floating point value
such that I can store that value into an integer type?
float foo = 6.180;
now take the fractional part
such that you can store 180...
|
by: tings |
last post by:
An article states: "In floating point maths, where if you divide by a
sufficiently large number sufficiently often, you will always be able to
reach a value too small to distinguish from zero,...
|
by: marko.suonpera |
last post by:
I'm using the Newmat library where element access in ColumnVector type
is defined as follows:
typedef double Real;
Real& ColumnVector::operator()(int m)
{
REPORT
if (m<=0 || mnrows)...
|
by: mathieu |
last post by:
Hi,
I am working on an IO library, and I am reading a binary blob which
represent a floating point. I would like to know what is the correct
way to interpret it. For integer type using a...
|
by: pcauchon |
last post by:
When I try to run this code on my machine (iMac with MacOS 10.5), I
get very strange results. I am using this compiler:
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
The first...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
