Home > Archive > Fortran > March 2006 > Formatted IO of huge/tiny values
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Formatted IO of huge/tiny values
|
|
| Janne Blomqvist 2006-03-16, 3:57 am |
| Hi,
I have a faint recollection that the standard mentions something about
being able to read back what one has written using the same format (as
long as the format is "big enough" etc.). But I didn't find anything
like that when I searched. Perhaps it was only the corresponding thing
about unformatted?
However if the above is true, there is the possible problem that if
huge(1.0_somekind) or tiny(1.0_somekind) are not exactly representable
in decimal, writing these values causes the written values to be
rounded out of the range, and as a consequence reading them back in
fails, unless special precautions are taken in the IO library.
Is a standard conforming processor required to handle this rather
obscure corner case?
--
Janne Blomqvist
| |
| robert.corbett@sun.com 2006-03-16, 7:56 am |
|
Janne Blomqvist wrote:
> Hi,
>
> I have a faint recollection that the standard mentions something about
> being able to read back what one has written using the same format (as
> long as the format is "big enough" etc.). But I didn't find anything
> like that when I searched.
The Fortran standard offers no such assurance.
> Perhaps it was only the corresponding thing
> about unformatted?
>
> However if the above is true, there is the possible problem that if
> huge(1.0_somekind) or tiny(1.0_somekind) are not exactly representable
> in decimal, writing these values causes the written values to be
> rounded out of the range, and as a consequence reading them back in
> fails, unless special precautions are taken in the IO library.
Every binary floating-point value is exactly representable as a decimal
value. However, that is not enough to ensure getting the same value
back as is written.
> Is a standard conforming processor required to handle this rather
> obscure corner case?
No. A standard conforming processor is not required to get the value
1.0 given the input 1.0. The committee would tell you it is a "quality
of
implementation" (QOI) issue.
Bob Corbett
| |
| Richard E Maine 2006-03-16, 6:59 pm |
| Janne Blomqvist <foo@bar.invalid> wrote:
> I have a faint recollection that the standard mentions something about
> being able to read back what one has written using the same format (as
> long as the format is "big enough" etc.). But I didn't find anything
> like that when I searched.
That's because it isn't there - nothing even vaguely related. You might
have been  by some people who argue that this is a
"requirement", but by that they mean their personal requirement rather
than one of the standard.
I don't happen to personally have a requirement like this; I think that
perfect last-bit accuracy is for unformatted. True, unformatted is in
principle nonportable (though in practice, you can do pretty well with
some case), but then last-bit acccuracy is also non-portable to the
extent that bit-level representations need not even be the same.
> Perhaps it was only the corresponding thing about unformatted?
Perhaps, but I'd lay more odds on you having read things where people
didn't clearly distinguish personal versus standard requirements.
Unformatted gives you last-bit accuracy, but it isn't expressed that
way. Mostly the issue of accuracy doesn't come up in unformatted because
there is no conversion to be inaccurate. Since the bits are just copied,
they aren't going to go wrong (short of something like hardware
failure). Well, the standard doesn't quite say "bits are copied" in
those words, but close enough.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-03-16, 6:59 pm |
| Richard E Maine wrote:
> Janne Blomqvist <foo@bar.invalid> wrote:
>
>
> That's because it isn't there - nothing even vaguely related. You
> might have been by some people who argue that this is a
> "requirement", but by that they mean their personal requirement rather
> than one of the standard.
Well, it *is* a requirement. And it's a standard requirement.
It's just not a Fortran standard requirement. The IEEE float
standard requires that processors provide for this capability.
Now, I think it *ought* to be a Fortran standard requirement
for list-directed. And I've said many times that implementations
should do so whether the standard requires it or not. And that
implementations that claim to be IEEE float compliant should
meet that standard's specification for binary to decimal (and
back) conversions during formatted I/O.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Joe Krahn 2006-03-16, 6:59 pm |
| James Giles wrote:
> Richard E Maine wrote:
>
>
>
> Well, it *is* a requirement. And it's a standard requirement.
> It's just not a Fortran standard requirement. The IEEE float
> standard requires that processors provide for this capability.
>
Does "provide for this capability" mean that there is at least one
format that works for input and output, or does it specify that ALL
formats meet this requirement?
> Now, I think it *ought* to be a Fortran standard requirement
> for list-directed. And I've said many times that implementations
> should do so whether the standard requires it or not. And that
> implementations that claim to be IEEE float compliant should
> meet that standard's specification for binary to decimal (and
> back) conversions during formatted I/O.
Apparently other people think so. Intel Fortran seems to follow this
idea; at least for some formats, it accepts an input format that should
only be valid for output.
For people who want reversible formats, I think it would be better to
avoid incompatible standard formats rather than extend the allowed
formats. It should be sufficient to summarize which forms can be used
reversibly.
Joe Krahn
| |
| Richard E Maine 2006-03-16, 6:59 pm |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Now, I think it *ought* to be a Fortran standard requirement
> for list-directed.
I tend to think exactly the opposite - that list-directed is for
quick&dirty work. People shouldn't use it if they care about fine
details. And I tend to personally prefer that list-directed err in the
direction of legibility by not having overly high precision.
But no way am I going to argue the point. I have stated my personal
preference. I acknowledge that it is just a personal perference. I'm not
going to try to justify it or defend it. Done. End of my comments on the
subject.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| James Giles 2006-03-16, 6:59 pm |
| Joe Krahn wrote:
....
> Does "provide for this capability" mean that there is at least one
> format that works for input and output, or does it specify that ALL
> formats meet this requirement?
It means that at least one format must be provided that
satisfies the property. However, it turns out that if the
decimal representation carries at least a certain number
of digits (9 for IEEE single; 17 for IEEE double), and
the conversion meets the IEEE requirements for conversions
to that form, you'll meet the requirement. It's unliklely
that you'll find a Fortran implementation that won't give
you the correct IEEE single precision value after writing
out 9 digits and reading them back in. It's unlikely, but
permitted by the Fortran standard.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2006-03-16, 6:59 pm |
| Richard E Maine wrote:
....
> I tend to think exactly the opposite - that list-directed is for
> quick&dirty work. People shouldn't use it if they care about fine
> details. And I tend to personally prefer that list-directed err in the
> direction of legibility by not having overly high precision.
We obviously have a different definition of "legibility".
Concealing information is not legibility. It's anti-legibility.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-03-16, 6:59 pm |
| James Giles <jamesgiles@worldnet.att.net> wrote:
(snip)
[color=darkred]
(snip)
[color=darkred]
> Well, it *is* a requirement. And it's a standard requirement.
> It's just not a Fortran standard requirement. The IEEE float
> standard requires that processors provide for this capability.
> Now, I think it *ought* to be a Fortran standard requirement
> for list-directed. And I've said many times that implementations
> should do so whether the standard requires it or not.
I don't believe it should do it normally for list directed,
though I am not against having the ability to do it.
Java requires it in its normal conversions, and it makes ugly
looking data.
For human readable output it is nice not to print 0.2 as
0.19999999999999999999999999 or some such, which it seems
likely to do.
Maybe an OPEN statement option or something like that, would
be fine.
-- glen
| |
| Joe Krahn 2006-03-16, 6:59 pm |
| James Giles wrote:
> Richard E Maine wrote:
> ...
>
>
>
> We obviously have a different definition of "legibility".
> Concealing information is not legibility. It's anti-legibility.
>
I think the legibility applies better to short forms. Legibility refers
to the ability to read what is written. So, short forms are more legible
but less precise.
Personally, I think list-directed I/O should aim to be quick but not
dirty, meaning everything should be written to full precision.
However, it would be nice if list-directed I/O had some options to fit
both uses, quick + dirty or quick - dirty.
Joe
| |
| James Giles 2006-03-16, 6:59 pm |
| Joe Krahn wrote:
> James Giles wrote:
....
>
> I think the legibility applies better to short forms. Legibility
> refers to the ability to read what is written. So, short forms are
> more legible but less precise.
Well, I guess I'm too much of a pedant (computing is a
pedantic business). But to me, at least as far as programming
goes, legibility is the ease with which you can tell what's
going on. Readability is the ease of merely reading it.
To the extent they're correllated (greatly) there need be
no distinction between the two. But, neither is necessarily
correllated to brevity. Terseness is just as bad as verbosity.
Some compromise is almost always needed. (My prose tends
to be too verbose, but I'm too lazy to edit.)
In any case, I'd say that concealing information may often be
more readable, but I wouldn't agree that it's more legible.
You can pick different words if you like. But the difference
in concepts is what's important. And I oppose that which
makes it harder to decipher what's going on.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Joe Krahn 2006-03-17, 3:57 am |
| James Giles wrote:
> Joe Krahn wrote:
>
>
> ...
>
>
>
> Well, I guess I'm too much of a pedant (computing is a
> pedantic business). But to me, at least as far as programming
> goes, legibility is the ease with which you can tell what's
> going on. Readability is the ease of merely reading it.
> To the extent they're correllated (greatly) there need be
> no distinction between the two. But, neither is necessarily
> correllated to brevity. Terseness is just as bad as verbosity.
> Some compromise is almost always needed. (My prose tends
> to be too verbose, but I'm too lazy to edit.)
>
> In any case, I'd say that concealing information may often be
> more readable, but I wouldn't agree that it's more legible.
> You can pick different words if you like. But the difference
> in concepts is what's important. And I oppose that which
> makes it harder to decipher what's going on.
>
I guess you could say that a terse form makes the printout more legible,
but the actual result less legible. Maybe the lesson is that legible can
be a bit ambiguous between the concepts of readability and decipherability.
Joe
| |
| Clive Page 2006-03-17, 3:57 am |
| In message <1hcardp.1w7jbpsaeuq6sN%nospam@see.signature>, Richard E
Maine <nospam@see.signature> writes
>I tend to think exactly the opposite - that list-directed is for
>quick&dirty work. People shouldn't use it if they care about fine
>details. And I tend to personally prefer that list-directed err in the
>direction of legibility by not having overly high precision.
For what it's worth, I agree with Richard that list-directed should not
be encouraged for serious use. But I can see that there may be
situations where you really want to read a number previously written
number without altering its value and where unformatted I/O won't work.
I'd like to suggest that maybe in a future standard that the Gw.d format
should be defined to do this, given suitable values of w and d? G is
rarely used (in my experience, anyway) and essentially means that you
specify the field width and number of decimal places but leave the
details to the Fortran run-time system.
--
Clive Page
| |
| glen herrmannsfeldt 2006-03-17, 7:57 am |
| James Giles wrote:
(snip)
> In any case, I'd say that concealing information may often be
> more readable, but I wouldn't agree that it's more legible.
> You can pick different words if you like. But the difference
> in concepts is what's important. And I oppose that which
> makes it harder to decipher what's going on.
In a quick test adding 0.01 in a loop resulted in 0.029999999999999999
after three iterations. I didn't go through the calculations to see if
the closest IEEE representation to 0.03 is actually closer to
0.029999999999999999, but that should be enough to get the idea across.
Until IEEE 854 machines are produced, this problem will be around.
99.99% of the time 0.03 is what I want to see. I would even say that
any algorithm that depends on the LSB of a floating point number is
defective. In those 0.01% of the cases where you do need to know the
difference, use formatted output.
-- glen
| |
| Dan Nagle 2006-03-17, 7:57 am |
| Hello,
glen herrmannsfeldt wrote:
<snip>
> Until IEEE 854 machines are produced, this problem will be around.
Isn't 854 obsolete? Isn't it's functionality (non-binary radix)
subsumed under the Real Soon Now 754r?
(radix 10 being the non-binary case of interest)
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| I certainly agree that there should be some format specifier that means
'minimum-lenght human readable output (as opposed to unformated) so
that writing, followed by reading in results in the same binary number
(this is the g95 setting for list directed output as far as I know).
This formatted output would be processor dependent, but very
meaningful, and AFAICT missing in the current standard.
Joost
| |
| Richard E Maine 2006-03-17, 6:58 pm |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> In those 0.01% of the cases where you do need to know the
> difference, use formatted output.
I said that I won't comment any more on the main subject of this
thread... and I won't do that.
But I will add my standard knee-jerk reply to the incorrect terminology.
List-directed formatting is a form of formatted. The appropriate
contrast is something like list-directed formatting versus explicit
formatting - not list-directed versus formatted.
Yes, I know that you really know. But other people who read the forum
don't necessarily, and might get mislead. I have helped multiple people
who have done something like open a file with form='unformatted' because
they wanted to use list-directed. So the incorrect terminology leads to
incorrect programs here - it is not purely a matter of pedandtry.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-03-18, 3:56 am |
| Richard E Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
[color=darkred]
> I said that I won't comment any more on the main subject of this
> thread... and I won't do that.
> But I will add my standard knee-jerk reply to the incorrect terminology.
> List-directed formatting is a form of formatted. The appropriate
> contrast is something like list-directed formatting versus explicit
> formatting - not list-directed versus formatted.
Oops. Well, it was a little late but that's no excuse.
> Yes, I know that you really know. But other people who read the forum
> don't necessarily, and might get mislead. I have helped multiple people
> who have done something like open a file with form='unformatted' because
> they wanted to use list-directed. So the incorrect terminology leads to
> incorrect programs here - it is not purely a matter of pedandtry.
I don't think you will ever find me call list directed "unformatted", if
that helps any.
-- glen
| |
| glen herrmannsfeldt 2006-03-18, 3:56 am |
| Dan Nagle wrote:
> glen herrmannsfeldt wrote:
> <snip>
[color=darkred]
> Isn't 854 obsolete? Isn't it's functionality (non-binary radix)
> subsumed under the Real Soon Now 754r?
> (radix 10 being the non-binary case of interest)
I am not so sure what the differences between 754R and 854 are. Since
the ideas started under 854 (as far as I know) I didn't think it was too
far off to mention that number. 754R sounds too close to 754, and
people might not notice the difference.
I recently heard that for extra bit efficiency some of the high bits of
the exponent and fraction are shared. With modern hardware it will
likely be close enough in speed that it will be hard to measure any
difference.
-- glen
| |
| Dan Nagle 2006-03-18, 7:56 am |
| Hello,
glen herrmannsfeldt wrote:
> Dan Nagle wrote:
>
>
>
>
>
>
> I am not so sure what the differences between 754R and 854 are. Since
> the ideas started under 854 (as far as I know) I didn't think it was too
> far off to mention that number. 754R sounds too close to 754, and
> people might not notice the difference.
>
> I recently heard that for extra bit efficiency some of the high bits of
> the exponent and fraction are shared. With modern hardware it will
> likely be close enough in speed that it will be hard to measure any
> difference.
>
> -- glen
754r is different from 754, adding 128-bit real to 32-bit and 64-bit.
754r also adds a radix-10 format (which, IIUC, is the source
of the delay in publication).
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| glen herrmannsfeldt 2006-03-18, 6:58 pm |
| Dan Nagle wrote:
(snip)
> 754r is different from 754, adding 128-bit real to 32-bit and 64-bit.
> 754r also adds a radix-10 format (which, IIUC, is the source
> of the delay in publication).
Yes, but it sounds too much the same.
I don't mind so much the revisions with a year after them.
In that case, it is easy to see which is old and which is new
(though sometimes the delay confuses that).
Though including radix-10 format in 754R instead of 854 probably
increases the chance of actually seeing a processor with it.
-- glen
| |
| James Giles 2006-03-18, 6:58 pm |
| glen herrmannsfeldt wrote:
>...
> Though including radix-10 format in 754R instead of 854 probably
> increases the chance of actually seeing a processor with it.
I was thinking the reverse. Radix-10 increases the
complexity of an implementation without much benefit
in compensation. In fact, even with correct rounding
and the other such features one would expect from an
IEEE standard, radix-10 will still accumulate error
during a long calculation several times faster than
binary. So, knowledgeable users won't be all that
keen on it anyway.
That's just an inherent problem as the radix increases.
You can compensate partially by making your source
code more complex (turning single simple operations
into sequences intended to preserve precision better).
But if you do that, you lose the maintainability of
the code along with any speed you might have hoped
to retain.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Dan Nagle 2006-03-18, 6:58 pm |
| Hello,
James Giles wrote:
> glen herrmannsfeldt wrote:
>
> I was thinking the reverse. Radix-10 increases the
> complexity of an implementation without much benefit
> in compensation. In fact, even with correct rounding
> and the other such features one would expect from an
> IEEE standard, radix-10 will still accumulate error
> during a long calculation several times faster than
> binary. So, knowledgeable users won't be all that
> keen on it anyway.
>
> That's just an inherent problem as the radix increases.
> You can compensate partially by making your source
> code more complex (turning single simple operations
> into sequences intended to preserve precision better).
> But if you do that, you lose the maintainability of
> the code along with any speed you might have hoped
> to retain.
IIUC, radix-10 is for business, where the ratio
of calculation to format conversion is very low.
For example, read a formatted number, multiply
to convert dollars to pounds, write the formatted result.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| James Giles 2006-03-18, 6:58 pm |
| Dan Nagle wrote:
....
> IIUC, radix-10 is for business, where the ratio
> of calculation to format conversion is very low.
>
> For example, read a formatted number, multiply
> to convert dollars to pounds, write the formatted result.
I would have thought business would do better with
fixed-decimal though. I don't think IEEE ever thought
of standardizing hardware fixed-decimal. Might have
been a more interesting idea.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-03-21, 3:57 am |
| Dan Nagle wrote:
> James Giles wrote:
[color=darkred]
[color=darkred]
The ALU is such a small part of modern processors that I doubt
anyone would see the difference. It gets a little harder for divide,
but it might be that even there it doesn't matter much.
[color=darkred]
It depends a lot on the algorithm. Remember that fewer exponent bits
are required for the same exponent range, so those bits are available as
fraction bits. It is easier for most people to understand the effects
of decimal rounding and such, as most of us have been doing it longer.
It is usual to report results in journal articles in decimal, and the
precision effects of decimal haven't caused many problems there. There
might still be enough people around used to IBM hex based floating point
to understand the accumulated error problems.
[color=darkred]
[color=darkred]
> IIUC, radix-10 is for business, where the ratio
> of calculation to format conversion is very low.
That should be true for fixed point. It is less obvious for floating
point. To me, it might be worthwhile avoiding all the questions from
people wondering why they get strange rounding from binary floating point.
> For example, read a formatted number, multiply
> to convert dollars to pounds, write the formatted result.
IBM hardware has done 31 digit add, subtract, product, and dividend for
over 40 years. 31 digits of fixed point should be enough for most of
those problems. Floating point is for problems with relative error,
fixed point for problems with absolute error.
-- glen
| |
| James Giles 2006-03-21, 7:57 am |
| glen herrmannsfeldt wrote:
>
> It depends a lot on the algorithm. [...]
Quite so. But, the proper algorithms for decimal are
much more complex than the algorithms for binary, and
take more operations. Even something as simple as
(X+Y)/2 will accumulate error maybe 3 to 5 times
as fast in decimal than in binary. Yes, there is a
way to rewrite the expression to keep decimal more
competitive (though it never wins), but in general it
requires more operations (maybe even a conditional).
If even such simple expressions need to be rewitten,
what of the kinds of thing real numerical computations
do?
> [...] Remember that fewer exponent
bits
> are required for the same exponent range, so those bits are available
> as fraction bits. [...]
Well, it won't be so for the IEEE decimals. For example, the
IEEE single precision decimal carries 7 decimal digits and
an exponent range of + or minus 95. That means that the
size of one ULP compared to the number itself varies from
10^(-6) to 10^(-7) for such numbers. While the binary
IEEE single carries 24 bits and the relative size of one ULP
is between about 10^-(6.92) and about 10^(-7.22). More than
half the representable decimals have a worse relative error
than the worst that binary does.
Things are even worse than that. Because the distribution of
leading digits in actual calculations is not uniform, more values
are near the least precise end of the range: Benford's law. So,
decimal intermediates more often have a one ULP size near 10^(-6)
while binary intermediates spend more time near 10^(-6.92).
And, because of the increased rate at which roundoff accumulates
in decimal, it needs maybe even a couple of extra digits for
a long calculation just to end up keeping even. Instead, it's
the better part of a whole digit less precise. (And, given
that even household machines now boast billions of operations
a second, a long calculation isn't all that long any more.
Eventually, for a *really* long calculation, decimal loses
even if it carries lots more digits.)
Yes, the binary representation has a narrower exponent range,
but fewer calculations run afowl of that than accumulated roundoff.
> [...] It is easier for most people to understand the effects
> of decimal rounding and such, as most of us have been doing it longer.
Understanding why you're doing worse is no help if your
algorithm is unstable with decimal even though the same
algorithm is comfortably stable with binary.
> It is usual to report results in journal articles in decimal, and the
> precision effects of decimal haven't caused many problems there.
That's because results printed on a page are static. They
are the output of a program, not values of the ongoing
computation. Converting the better results from a binary
calculation into decimal will give better answers than
carrying out the whole calculation in decimal. The only
exceptions to that are those calculations in which rounding
seldom occurs. All your counter-examples "demonstrating"
the superiority of decimal involve operations that avoid
rounding in decimal yet have rounding in binary - contrived
calculations. In real calculations, rounding occurs in nearly
every operation for both bases.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2006-03-22, 8:05 am |
| James Giles wrote:
(snip regarding FLOAT DECIMAL)
> Quite so. But, the proper algorithms for decimal are
> much more complex than the algorithms for binary, and
> take more operations. Even something as simple as
> (X+Y)/2 will accumulate error maybe 3 to 5 times
> as fast in decimal than in binary. Yes, there is a
> way to rewrite the expression to keep decimal more
> competitive (though it never wins), but in general it
> requires more operations (maybe even a conditional).
> If even such simple expressions need to be rewitten,
> what of the kinds of thing real numerical computations
> do?
The last iteration of a Newton-Raphson square root is
done as X+(X-Y)/2. (It is for hexadecimal, also.)
It might even be better in binary (the rounding can be different),
and it is just one more subtraction.
> exponent range, so those bits are available as fraction bits.[...]
> Well, it won't be so for the IEEE decimals. For example, the
> IEEE single precision decimal carries 7 decimal digits and
> an exponent range of + or minus 95. That means that the
> size of one ULP compared to the number itself varies from
> 10^(-6) to 10^(-7) for such numbers. While the binary
> IEEE single carries 24 bits and the relative size of one ULP
> is between about 10^-(6.92) and about 10^(-7.22). More than
> half the representable decimals have a worse relative error
> than the worst that binary does.
So you don't give any value to the larger exponent range?
Binary floating point to get to +/-95 would have two fewer
fraction bits. Note also that in both cases you can't guarantee
seven digits.
(snip)
> Yes, the binary representation has a narrower exponent range,
> but fewer calculations run afowl of that than accumulated roundoff.
and many that don't probably should be done in fixed point, anyway.
[color=darkred]
> Understanding why you're doing worse is no help if your
> algorithm is unstable with decimal even though the same
> algorithm is comfortably stable with binary.
>
>
[color=darkred]
> That's because results printed on a page are static. They
> are the output of a program, not values of the ongoing
> computation.
(snip)
Well, often they are the result of a series of calculations explicitly
done in the article. Their is a long history of keeping sigfigs
(significant figures) in calculations, that is, decimal digits.
I suppose one could have sigbits, but I haven't seen that yet.
I don't remember the numbers for double precision, but I believe they
are somewhat better, and likely to be used much more (as it is in
binary). I doubt binary will disappear. People will choose in any
case, though it does get complicated to mix them inside one program.
-- glen
| |
| James Giles 2006-03-22, 7:03 pm |
| glen herrmannsfeldt wrote:
> James Giles wrote:
....
>
> and many that don't probably should be done in fixed point, anyway.
Including nearly all of your examples "proving" the superiority
of decimal floating point. Decimal is dismal for float. It's
all right for fixed point I suppose.
> [...] I doubt binary will disappear. People will choose in any
> case, though it does get complicated to mix them inside one program.
I doubt decimal will appear - at least in serious numerical
computation. The advent of decimal hardware will just
make yet another thing to warn students not to do.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Joe Krahn 2006-03-22, 7:03 pm |
| I haven't followed the whole thread but...
It should be obvious that binary floats are superior as long as all
calculations are done in binary. Binary simply gives the finest possible
control of significant digits, including how much to use for the exponent.
Decimal can only be more accurate by the advantage of avoiding
conversion to and from binary form, or if you happen to be doing math
that naturally fits base-10 better.
If only our ancestors had decided to count with fingers and not thumbs,
we would have base-8 numbers, and the idea that base-10 math is better
would be irrelevant.
Joe
| |
| James Giles 2006-03-22, 7:03 pm |
| Joe Krahn wrote:
....
> If only our ancestors had decided to count with fingers and not
> thumbs, we would have base-8 numbers, and the idea that base-10 math
> is better would be irrelevant.
If we had eight fingers (or didn't use the thumbs) the debate
wouldn't occur for anohter reason: all base 8 fractions are
representable in binary. Since binary has otherwise superior
properties we would use binary floating point and be quite
happy with the octal results. The evolutionary accident that
we had ten fingers does damage to the craft of numerical
computing.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Joe Krahn 2006-03-22, 7:03 pm |
| James Giles wrote:
> Joe Krahn wrote:
> ...
>
>
>
> If we had eight fingers (or didn't use the thumbs) the debate
> wouldn't occur for anohter reason: all base 8 fractions are
> representable in binary. Since binary has otherwise superior
> properties we would use binary floating point and be quite
> happy with the octal results. The evolutionary accident that
> we had ten fingers does damage to the craft of numerical
> computing.
>
That's what I meant. I thought the compatibility of base 8 and base 2
was obvious. But, maybe a good thing that you expanded the idea a bit.
But, the simple meaning is true as well. People would only argue that
base-12 was better if we had another finger per hand.
Actually, it seems that switching to an octal system for daily use would
make sense. A small period of adjustment to benefit the rest of human
existence. But, we can't even get people to switch from SAE to Metric.
Joe
| |
| glen herrmannsfeldt 2006-03-22, 7:03 pm |
| Joe Krahn <krahn-at-niehs.nih.gov@x.y.z> wrote:
> Decimal can only be more accurate by the advantage of avoiding
> conversion to and from binary form, or if you happen to be doing math
> that naturally fits base-10 better.
> If only our ancestors had decided to count with fingers and not thumbs,
> we would have base-8 numbers, and the idea that base-10 math is better
> would be irrelevant.
Well, we could have adopted the Mesopotamian or Babylonian base 60.
-- glen
|
|
|
|
|