Re: mixed type operations in Octave

[John W. Eaton]

On  9-Sep-2008, Jaroslav Hajek wrote:

| On Tue, Sep 9, 2008 at 4:24 AM, John W. Eaton <address@hidden> wrote:
| > On  8-Sep-2008, Jaroslav Hajek wrote:
| >
| > | I'm working on a patch to improve integer arithmetics in Octave.
| >
| > What do you mean by improve?  Make them faster?  I think that's OK,
| > but is it really worth the effort?
| >
| I mean:
| 1. Provide int64 arithmetics.
| 2. Make them faster (while, of course, preserving the saturation
| semantics and the warnings). Use integer arithmetics where possible.
| The primary target for speed are the homogeneous operations.
| 3. Complete the warnings. I don't get why Matlab possibly gripes at
| conversion int32(0.5) but always accepts int32(1) + 0.5 silently. I
| want to make Octave possibly warn here.
| 4. Restructure the classes in oct-inttypes.h somewhat, replace macros
| with templates where appropriate, reduce code duplication.

OK.  I'd suggest attacking each of these separately.  Maybe do the
cleanup of oct-inttypes.h first.

How do you propose to avoid the conversion to double and still provide
the saturation semantics?  Do the operation in the next widest integer
type?  Something else?

| Of course, it's Matlab versus common sense again. But I didn't want to
| go any farther than making 64-bit arithmetics work, and I think that
| most of the behaviour is already clear in Matlab, just not
| implemented. The problem is just that the obvious way of implementing
| int + double does not work well for int64.

| I am all for simply not providing mixed integer ops. It's just that
| they are defined in oct-inttypes.h, and so I thought they might be
| used somewhere.

OK.  I think the templates could easily be rewritten so that they only
work when both operands have the same type.

| The easiest solution is to just leave the templates there using the
| current approach, and not care that they don't work for octave_int64.
| Or put them away, and if they happen to be used anywhere in the
| sources (I didn't check yet), then replace the usage with an explicit
| conversion. I'll rather do this, if you're fine with it, as it seems
| nasty to leave broken code around.

How is the code broken?

| The mixed-type comparisons will of
| course remain, as there is no problem with these.
| 
| The question is what to do with int64 OP double. Options I see:
| 
| 1. leave the current (broken) way. Losing some digits with high numbers.

Is this what you mean when you say broken above, that the templates
won't work properly for 64-bit ints?  OK, if we can't come up with a
portable way to implement 64-bit operations on all systems, then I
think we will need specializations for the 64-bit types that throw
errors.

| 2. forbid it, and wait what Matlab will do (but I think they're bound
| to do something close to 3)
| 3. use long double if possible (x86), and if not, emulate.
| 
| which one do you prefer? Now that I think of it, 3 is probably the
| best in terms of completeness as well as consistency with Matlab,
| though likely the most laborious.

I think 3 would be fine, if you want to tackle it.  I just don't think
of it as a high priority project.

jwe