Internal representation of doubles

[jdog1016]

Recently I coded something for a class that uses a LOT of doubles with
precision out to the thousands place. I did most of the arithmetic by
multiplying each by a thousand and converting to an int, but not all of
it. In any case, coding it under FreeBSD, I didn't have any problems.
However, when I moved it Linux and compiled, I got drastically
different numbers. I eventually fixed the problem by multiplying
everything by 1000 and storing as ints, and then converting back when
printing to the screen, but I'm not sure even now if I fully understand
why this happened. Is this a compiler thing? I was using 3.3.3 on
freebsd and 3.3.2 on linux... Or is this an OS thing?

[Victor Bazarov]

jd******@gmail.com wrote:

Recently I coded something for a class that uses a LOT of doubles with
precision out to the thousands place. I did most of the arithmetic by
multiplying each by a thousand and converting to an int, but not all of
it. In any case, coding it under FreeBSD, I didn't have any problems.
However, when I moved it Linux and compiled, I got drastically
different numbers.
You'd have to define "drastically".
I eventually fixed the problem by multiplying
everything by 1000 and storing as ints, and then converting back when
printing to the screen, but I'm not sure even now if I fully understand
why this happened. Is this a compiler thing? I was using 3.3.3 on
freebsd and 3.3.2 on linux... Or is this an OS thing?

It can be all of those things, and a hardware thing. It does sound weird,
though. Most probably it's the rounding that was different. It could be
a simple truncation on one and true rounding on the other. And the
rounding could be towards nearest value, towards zero, etc.

BTW, why did you have to do the "multiply by 1000 and convert to int"
dance?

V

[jdog1016]

Well, by multiplying by 1000 and converting to int, it seemed to make
the rounding a little more consistent. Its one of these things where
my output needs to match my professors exactly and through thousands of
iterations of arithmetic with a few numbers, small differences in
rounding compounded to produce large differences.

[Victor Bazarov]

jd******@gmail.com wrote:

Well, by multiplying by 1000 and converting to int, it seemed to make
the rounding a little more consistent. Its one of these things where
my output needs to match my professors exactly and through thousands of
iterations of arithmetic with a few numbers, small differences in
rounding compounded to produce large differences.

Ah... In this case you should put additional code into your program
that in the beginning will ask for the desired output and then when
the program is finished, will just output precisely what was desired.
Come to think of it, the code between inputting the "right" numbers
and outputting them could simply be "sleep(10000);"...

V

[E. Mark Ping]

In article <11********************@z14g2000cwz.googlegroups.c om>,
jd******@gmail.com <jd******@gmail.com> wrote:

Well, by multiplying by 1000 and converting to int, it seemed to make
the rounding a little more consistent. Its one of these things where
my output needs to match my professors exactly and through thousands of
iterations of arithmetic with a few numbers, small differences in
rounding compounded to produce large differences.

That is the nature of limited precision arithmetic. People confuse it
for real number arithmetic all the time. If this is important to you,
you can find a primer entitled: "What Every Computer Scientist Should
Know About Floating-Point Arithmetic"

HTML version here:
http://docs.sun.com/source/806-3568/ncg_goldberg.html

It's important to know that the C++ language does not specify
implementation details sufficiently for a professor to require results
to be the same everywhere. That is intentional, as different
architectures are free to decide how to implement FP arithmetic
without making it impossible for compilers on those architectures to
use FP hardware.
--
Mark Ping
em****@soda.CSUA.Berkeley.EDU

[Lionel B]

<[e-mail]> wrote...

[...] Its one of these things where
my output needs to match my professors exactly and through thousands of
iterations of arithmetic [...].

Option 1: Run the same code as your professor on the same hardware running the same software

Option 2: Explain to your professor the niceties of floating-point arithmetic

;-)

--
Lionel B

[Mark Stijnman]

jd******@gmail.com wrote:

Well, by multiplying by 1000 and converting to int, it seemed to make
the rounding a little more consistent. Its one of these things where
my output needs to match my professors exactly and through thousands of iterations of arithmetic with a few numbers, small differences in
rounding compounded to produce large differences.

Seems to me that by explicitly rounding to the 3rd decimal, *you* are
the one introducing the rounding errors. Unless you realy *need* data
that is confined to a limited precision, like currency (only 2 decimal
places), currency exchange rates (5) or integer data, all rounding
should be done as late in the process as possible - i.e., only at the
end. Up to that point, why not profit from all the accuracy your
platform can give you in a double variable?

As to compounding roundoff errors accumulating in a large difference,
you may want to check whether your algorithm as a whole is stable. If
it were stable, small changes in initial conditions should only yield
small changes in the end result. Small roundoff errors would then not
be able to propagate far.

regards Mark

[jdog1016]

I think my professor is well aware of how floating point arithmetic
works, and its quirks. His suggestion for solving the problem was to
simply do the same thing that he did (and he told us how he did it, and
gave us example input and ouput). Also, since we had to submit
statically compiled binaries, along with source, compilers will not be
an issue.

I guess when I said "exactly" the same, I didnt' really mean that. It
just needs to be very close. He's a pretty reasonable guy.

It is true that I am causing such "rounding errors" or whatever they
are by explicitly rounding to the third decimal, but this was his
approach, so he recommended we do the same for consistency, especially
since precision beyond the thousands place was trivial.

Thank you all for your comments.