On 2015/03/11 16:36:44, Keith wrote:
On Wed, 11 Mar 2015 02:10:29 -0700, <mailto:[email protected]> 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/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
