Re: mixed type operations in Octave

[John W. Eaton]

On 10-Sep-2008, Jaroslav Hajek wrote:

| On Tue, Sep 9, 2008 at 10:38 PM, John W. Eaton <address@hidden> wrote:
| > On  9-Sep-2008, 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, non-int). 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 up-to-date numbers now.
| 
| >From the old results, I see that in adding two signed 32-bit integers
| there was 113% speed-up with version 1 compared to current
| implementation and 173% with version 2 (the speed-up 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
| 64-bit 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