[LCP]Rounding questions

[Chuck Martin]

On Fri, Sep 06, 2002 at 08:57:34PM +1000, Greg Black wrote:
> Chuck Martin wrote:
> | On Fri, Sep 06, 2002 at 07:21:46AM +1000, Greg Black wrote:
> | > panoply.  None of the BSD systems I have access to here has
> | > this.
> | 
> | If this is true, I probably don't want to use round() then.
> 
> I'd say that was a good decision :-)

Well, since I've taken over maintaining this public domain program,
I've received e-mail from users of both FreeBSD and OpenBSD that
are using it, and I sure don't want to break it for them.

>      part of the program.  If you can't create a small sample
>      program with the problem, it usually means that you haven't
>      yet understood the nature of the problem.

I'll have to agree with that.

> It's best to track this down through the most original code that
> can illustrate the problem in case it's a bug that needs to be
> reported to the original author.

This program has a list of authors a mile long, and I don't have any
idea how to contact them (most in the list have no e-mail addresses,
and the ones that do have the old bang path style addresses), or to
determine which one is responsible for any particular section of the
code.

> present.  First, and always when debugging, make sure that all
> compiler optimisations are OFF.  If the problem disappears, it's
> an optimiser bug, so you're done.

I hadn't considered the possibility that it might be related to the
compiler optimisations.  Turning off the optimisations seems to have
cured the problem, so I guess I'll have to leave them off in the
Makefile.

> As somebody else mentioned, FPU registers and C doubles are not
> the same size in i386 machines, so subtle differences may arise
> because of that.  And sometimes math library functions do odd
> things unless you turn the right knobs (see the IEEE-754 doco
> for your system for more on this).

Yes, I've run into the FPU problems before, and ended up leaving
a couple of unnecessary fflush(stdout)'s in the code to force
the FPU stack to be popped, which I wasn't happy with, but I didn't
know of another solution.  I hadn't thought that it might be related
to optimisation in the compiler.  Now that I have optimisation turned
off, I tried removing those, and the old bugs are gone, too.  Of
course, the size of the binary is also increased by about 24%, and
I'm not sure about the speed.  Is it better to leave optimisation
off, or to leave in unnecessary system calls that force things to
work with optimisation on?  (Of course, I had those "unnecessary"
system calls documented as to why they were there so no one would
try to remove them in the future.)

Chuck