Re: integer concatenation (was: Octave 2.1.61 available for ftp)

[David Bateman]

Forget it, it was my CVS that was out of sync... It builds now...

D.

According to David Bateman <address@hidden> (on 11/10/04):
> John,
> 
> There appears to be a problem with the CVS, as trying to build this
> I get error on linking liboctinterp.so. These are of the form
> 
> ../src/liboctinterp.so: undefined reference to 
> `operator==(octave_int<unsigned long long> const&, octave_int<signed char> 
> const&)'
> ../src/liboctinterp.so: undefined reference to 
> `operator<=(octave_int<unsigned long long> const&, octave_int<short> const&)'
> ../src/liboctinterp.so: undefined reference to `operator>=(octave_int<signed 
> char> const&, octave_int<unsigned> const&)'
> 
> and lots more like it... Is there a file missing from the CVS? Or maybe
> its me that is out of sync and I should do a clean CVS checkout..
> 
> Cheers
> David
> 
> 
> According to John W. Eaton <address@hidden> (on 11/10/04):
> > On  9-Nov-2004, I wrote:
> > 
> > | On  5-Nov-2004, I wrote:
> > | 
> > | |   * Things like [int32(1), int16(1)] will fail.  Concatenation
> > | |     operations like this should return an object of the smaller type
> > | |     (int16 in this case).
> > | 
> > | This is not yet fixed, though it seems it should not be too hard to
> > | add.  I will try to take a look at it, but perhaps David could say
> > | whether it will require more than adding some concat functions.
> > 
> > I've implemented this feature.
> > 
> > While doing that, I found that the return type is not the smaller of
> > the two types, but it is the type of the first argument in the pair.
> > This means that
> > 
> >   [int8(1), int16(2)]
> > 
> > returns an int8 object, but
> > 
> >   [int16(1), int8(2)]
> > 
> > returns an int16 object.  The exception (you knew there had to be one,
> > right?) is that if you concatenate a double object and an intN object,
> > the the result is always the intN type.  This means that
> > 
> >   [int8(1), 2]
> > 
> > and
> > 
> >   [1, int8(2)]
> > 
> > both return int8 objects.
> > 
> > Will someone please verify that this is still the way that Matlab R14
> > behaves?
> > 
> > I didn't bother trying to define complex/intN concatenation because we
> > don't have complex intN objects.  I see no compelling reason to add
> > them, but someone will probably eventually complain that Octave is
> > completely useless because it does not have that feature.
> > 
> > My changes for concat are checked in.
> > 
> > Are there any other important bugs that need to be fixed before
> > making a 2.1.62 snapshot?
> > 
> > jwe
> 
> -- 
> David Bateman                                address@hidden
> Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
> 91193 Gif-Sur-Yvette FRANCE
> 
> The information contained in this communication has been classified as: 
> 
> [x] General Business Information 
> [ ] Motorola Internal Use Only 
> [ ] Motorola Confidential Proprietary

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary