Re: mixed type operations in Octave

[Jaroslav Hajek]

On Wed, Sep 10, 2008 at 8:06 PM, John W. Eaton <address@hidden> wrote:
> 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.
>

I know what you mean, and I agree, but 64-bit int arithmetics is,
IMHO, better described as a feature that is not *yet* in Matlab. I
think we can safely bet that it will, at some point, and maybe quite
soon, be implemented, and it is also fairly clear *how* it will be
implemented.
The question is - is it worth to go ahead and risk minor
incompatibilities, or is it better to wait for Mathworks?

Btw. I know that Matlab compatibility is what many users want, but I'm
curious how many users, and how much do they want it? In other words,
it could be interesting to try to get some numbers. I'm thinking about
setting up a "user feedback" webpage on Savannah, containing some
questionnaires and such stuff, to let users express their preferences.
To let users know, we could include a simple "user_feedback" command
in Octave that would launch the page in a browser or something
similar. Also, a note could be added to the windows installer. Perhaps
that would give us interesting information about what users want from
Octave.

cheers


> 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
>
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz