[gimp/gimp-2-8] Bug 788461 - Selection with a Fixed size is created with an ...
- From: N/A <ell src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gimp/gimp-2-8] Bug 788461 - Selection with a Fixed size is created with an ...
- Date: Thu, 5 Oct 2017 21:50:59 +0000 (UTC)
commit ac0719f938825e99d73fc1f8e785a924d6317be0
Author: Ell <ell_se yahoo com>
Date: Thu Oct 5 17:35:10 2017 -0400
Bug 788461 - Selection with a Fixed size is created with an ...
... off-by one size in special cases
The last commit wasn't drastic enough. We changed SIGNED_ROUND()
to use RINT(), which, in turn, may use rint(). However, rint()
effectively breaks ties to even, so that we get stuff like
'rint (1.5) - rint (0.5) == 2.0 - 0.0 == 2.0'. This can't be
good--it's entirely possible that we're bitten by this in other
cases without noticing.
Avoid rint() entirely in RINT(), and always use 'floor (x) + 0.5'
instead, which always breaks ties up. Hopefully, this doesn't
break anything else...
(cherry picked from commit 80a526861fb16e72046a61a01b77f9451b5dd2a1)
libgimpmath/gimpmath.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/libgimpmath/gimpmath.h b/libgimpmath/gimpmath.h
index 5925004..b7f5d6a 100644
--- a/libgimpmath/gimpmath.h
+++ b/libgimpmath/gimpmath.h
@@ -64,7 +64,13 @@ G_BEGIN_DECLS
* This macro rounds its argument @x to an integer value in floating
* point format. Use RINT() instead of rint().
**/
-#ifdef HAVE_RINT
+#if defined (HAVE_RINT) && 0
+/* note: rint() depends on the current floating-point rounding mode. when the
+ * rounding mode is FE_TONEAREST, it, in parctice, breaks ties to even. this
+ * is different from 'floor (x + 0.5)', which breaks ties up. in other words
+ * 'rint (2.5) == 2.0', while 'floor (2.5 + 0.5) == 3.0'. this is asking for
+ * trouble, so let's just use the latter.
+ */
#define RINT(x) rint(x)
#else
#define RINT(x) floor ((x) + 0.5)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]