octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #54572] int64 does not saturate correctly in n


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54572] int64 does not saturate correctly in negative direction
Date: Thu, 30 Aug 2018 16:02:44 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0

Follow-up Comment #42, bug #54572 (project octave):

@JWE, I see all the changes you've made to get rid of the
OCTAVE_HAVE_FAST_INT_OPS and to generally clean up the style.  I've recompiled
the code.  No BIST errors, and the timing looks about the same, maybe even a
little faster by a few percent in some cases.  (Could be the use of ternary
conditionals.)

So, I'd consider this bug report complete.  However, I saw the following
change for multiplication overflow and it caught my eye:


template <>
int64_t
octave_int_arith_base<int64_t, true>::mul_internal (int64_t x, int64_t y)
{
  // The signed case is far worse.  The problem is that even if neither
  // integer fits into signed 32-bit range, the result may still be OK.
  // Uh oh.


Looking at the changes there it seems to me this is also using a
post-int-overflow-operation, in fact a rather complex one at that.  I wonder
if we could use the same "check-ahead-of-time" approach that is done with the
add() and sub() routines.  If x or y equals 0, then the result is 0.  So,
assuming the x != 0 and y != 0 case, can't we just use a simple


if (MAX_INT / x < y)
  u = MAX_INT
else
  u = x * y;


It uses a division, but given how complex the current approach seems, the
division might still be faster.

We'd have to account for the sign of x and sign of y, which will have a
nuanced MIN_INT/MAX_INT, maybe rounding up/down, kind of thing, but that
should be straightforward.  Do you want to investigate since you seem on a
roll with oct-inttypes code?  :-)  Or should I have a try?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54572>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]