[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mixed type operations in Octave
From: 
John W. Eaton 
Subject: 
Re: mixed type operations in Octave 
Date: 
Wed, 10 Sep 2008 14:06:20 0400 
On 10Sep2008, Jaroslav Hajek wrote:
 On Tue, Sep 9, 2008 at 10:38 PM, John W. Eaton <address@hidden> wrote:
 > On 9Sep2008, Jaroslav Hajek wrote:
 >
 >  Addition and subtraction can be done using just the native operations.
 >  For instance, addition can be done like this:
 > 
 >  T add (T x, T y)
 >  {
 >  T u;
 >  if (x >= 0)
 >  {
 >  u = std::numeric_limits<T>::max ()  x;
 >  if (y > u)
 >  ftruncate = true;
 >  else
 >  u = y;
 >  }
 >  else
 >  {
 >  u = std::numeric_limits<T>::min ()  x;
 >  if (y < u)
 >  ftruncate = true;
 >  else
 >  u = y;
 >  }
 >  return x + u;
 >  }
 >
 > Where is ftruncate declared and how is it used?

 I converted the single int flag to individual boolean flags for each
 exception (truncate, nan, nonint). After all, they were always used
 separately.
OK, I forgot about exceptions.
 > Maybe you would also want to check x == 0 and y == 0? Something like

 Why? It's handled in the code above. But I can try and report the
 benchmark results.
It seems like it would be faster to avoid the extra operations when
either x or y is exactly zero.
 > BTW, how much faster are we talking about here?

 I already did some benchmarks, but I have changed the code
 significantly since, so I don't have uptodate numbers now.

 >From the old results, I see that in adding two signed 32bit integers
 there was 113% speedup with version 1 compared to current
 implementation and 173% with version 2 (the speedup is measured as
 `old_time / new_time  1' (in %)). This may not correspond exactly to
 the codes above. Also, especially with version 2, it somewhat depends
 on how often the overflow occurs (normally, it occurs infrequently,
 and I think this gives version 2 another speed advantage on
 architectures using branch prediction).
OK.
 > Although speed is nice, I think it would be better to spend time
 > working on missing features first.
 >
 Well, as I said before, it did start as a hunt for missing feature
 (int64 arithmetics). And I realized that the present method (using
 doubles) would not work, and when I wrote addition and subtraction for
 64bit ints, I could just as well make it a template and use it for
 other integers, especially if it would improve performance, which it
 did, etc.
By "missing features" I was thinking of things that are present in
Matlab but not Octave, so they would be missed by people trying to
port code from Matlab to Octave. I think we see a lot more complaints
about those kinds of things than we do about features that are just
generally missing from both Octave and Matlab.
But if you've already done most of the work, then I don't see why we
can't include it. I would prefer to see it done in stages if
possible. Also, we really must have configure checks to make sure the
assumptions required for your code to work are valid.
 Maybe you're right, all this may really be quite useless. Perhaps
 someone can comment on whether they use (or want to use) integer
 arithmetics in Octave, and whether they care about its speed?
It could certainly help for image processing, since reading an image
gives you an integer matrix.
jwe
 Re: mixed type operations in Octave, (continued)
 mixed type operations in Octave, John W. Eaton, 2008/09/08
 Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/09
 Re: mixed type operations in Octave, John W. Eaton, 2008/09/09
 Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/09
 Re: mixed type operations in Octave, John W. Eaton, 2008/09/09
 Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/10
 Re: mixed type operations in Octave,
John W. Eaton <=
 Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/10