On Mon, Jul 11, 2005 at 10:11:44PM -0300, João Rafael Nicola wrote:
This is a snipped of chord_length_parameterize:
gdouble tot_len = u[len - 1]; g_return_if_fail( tot_len != 0 ); if (finite(tot_len)) { for (unsigned i = 1; i < len; ++i) { u[i] /= tot_len; } } else { /* We could do better, but this probably never happens anyway. */ for (unsigned i = 1; i < len; ++i) { u[i] = i / (gdouble) ( len - 1 ); } }In both cases, u[len-1] should be very near 1.0, but not necessarily equals 1.0.
Surely x / x is exactly equal to 1.0 when x is a positive integer? On what platform does this `else' case fail?
The `if' case is another `x / x' case, but with weaker constraints on x: we've tested above that it's non-zero and (in the 0.41 version you've pasted above) not +/-inf.
tot_len is read from u[], which is presumably in memory, so we should be safe from issues from architectures like x86 where registers are wider than `double's in memory.
I would guess that the bug is rather that someone has erroneously replaced the original `isfinite' test with `finite', which differs for NaN. This bug has already been corrected in CVS.
I have previously come across a problem under windows where there was a number with strange properties; I think the windows libc printf showed it as something like `0.#' or something like that (involving a zero and I think a hash character).
João, rather than forcing the last element to be 1.0, can you change the assertion code to something like:
if (u[len - 1] != 1) { g_warning("expecting last element to equal 1, but found %17g"); }
and report here what it gives? Btw, I suggest trying current CVS, which is near to being released as 0.42.
Meanwhile, I'll try to check that the current code still respects documented preconditions.
pjrm.