[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: 
Tue, 09 Sep 2008 13:42:33 0400 
On 9Sep2008, Jaroslav Hajek wrote:
 On Tue, Sep 9, 2008 at 4:24 AM, John W. Eaton <address@hidden> wrote:
 > On 8Sep2008, 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 octinttypes.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 octinttypes.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 64bit 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 octinttypes.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 mixedtype 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 64bit ints? OK, if we can't come up with a
portable way to implement 64bit operations on all systems, then I
think we will need specializations for the 64bit 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
 Re: mixed type operations in Octave, (continued)
 mixed type operations in Octave, John W. Eaton, 2008/09/08
 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 <=
 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, 2008/09/10
 Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/10