[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoid floating-point compares on Stem:head_positions; issue 4310 (is
|
From: |
dak |
|
Subject: |
Re: Avoid floating-point compares on Stem:head_positions; issue 4310 (issue 217720043 by address@hidden) |
|
Date: |
Wed, 11 Mar 2015 18:14:37 +0000 |
On 2015/03/11 16:36:44, Keith wrote:
On Wed, 11 Mar 2015 02:10:29 -0700, <mailto:address@hidden> wrote:
> _How_ do we arrive at different versions of 3.0 here, or at GCC
> considering 3.0 > 3.0 ?
Probably we get different numbers that are close to 3.00... or 2.99...
The head positions are individually multiplied by staff-space in
Grob::get_offset() and then divided by staff-space
Staff_symbol_referencer::internal_get_position() and at magstep=2
staff-space is
2^(1/3)
I think a standard-conforming implementation should give bit-identical
floating-point results for these parallel computations,
No, not at all. In C++, any computation may be carried out at any
precision at least as high as that of the operands. Only when the
results are stored in a variable (or possibly explicitly cast to some fp
type) is it guaranteed that the precision is not higher than specified.
If we indeed do the equivalent of n*x/x, we are no longer guaranteed
that starting from an integer n we arrive at an integer, and when we do
this in two separate code paths, one calculation may end up as an
integer while another doesn't.
If we want to be safe about preserving integers, we must not scale back
and forth with some non-integer factor.
That's a not really fun part of the C standard. We might use some gcc
option like -fstore-floats or something similar to avoid that if we
can't clean up our code sufficiently. But the scaling back-and-forth
seems bad in its own right.
https://codereview.appspot.com/217720043/