[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mixed type operations in Octave
From: |
Jaroslav Hajek |
Subject: |
Re: mixed type operations in Octave |
Date: |
Tue, 9 Sep 2008 08:05:17 +0200 |
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.
I personally think that 1. alone is worth the effort, and that was my
original aim. But I realized that the current implementation (convert
to double, do OP, convert back) would not work for 64-bit integers,
and is not particularly fast anyway for 32-bit and smaller ints
either.
> If you want to change the semantics so that they make better sense (or
> at least are more like the semantics of similar operations in other
> languages) then I think I'd have to vote no against doing that since
> it will just be confusing for most users if integer operations work
> differently in Octave and Matlab. Also, while it might be tempting to
> make mixed type operations work, it is a bit risky since whatever we
> choose could end up being done differently in some future version of
> Matlab.
>
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.
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. 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.
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.
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- Re: mixed type operations in Octave, (continued)
- Re: mixed type operations in Octave, soren, 2008/09/08
- 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 <=
- 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, 2008/09/10
- Re: mixed type operations in Octave, Jaroslav Hajek, 2008/09/10