

Octave 2.1.61 is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleedingedge:
rwrr 1 1005 5500705 Nov 5 18:41 octave2.1.61.tar.gz
rwrr 1 1005 4328394 Nov 5 18:41 octave2.1.61.tar.bz2
rwrr 1 1005 40900 Nov 5 18:44 octave2.1.602.1.61.patch.gz
rwrr 1 1005 34372 Nov 5 18:44 octave2.1.602.1.61.patch.bz2
2fe3bd8465948609bfd65d96d24ee309 octave2.1.61.tar.gz
66416e4c219dd1f2a83ec45c6958396b octave2.1.61.tar.bz2
9bcdfa5c486756b35df991c140346e3f octave2.1.602.1.61.patch.gz
1e1ef60d3233d55a9a6f57b62714f0ad octave2.1.602.1.61.patch.bz2
Thanks again to David Bateman for all his hard work to get this
snapshot ready.
This version includes many new features, including integer data types,
inline functions, function handles, concatenation of structs, cell
arrays and userdefined types, and better compatibility with the
leading brand.
Although I believe that 2.1.61 will be quite useable, there have been
many changes and experience says that any number of unexpected problems
could show up just after the tar file hits the ftp site, so 2.1.57
remains the recommended version for now.
I know of one problem that should probably be fixed before we
declare a new recommended snapshot:
* Comparison operations for 64bit integers will not work correctly
for large values (> 2^53) because we are converting to double to
do the conversions.
and two more that would be nice to fix:
* Things like [int32(1), int16(1)] will fail. Concatenation
operations like this should return an object of the smaller type
(int16 in this case).
* Concatenation of simple matrix objects should use a more memory
efficient method as was done in earlier versions of Octave (but
the new code has the distinct advantage of allowing concatenation
for userdefined types, so we can't simply revert to the previous
method).
As always, if your favorite bug is still not fixed, please report it.
jwe


On 5Nov2004, I wrote:
 I know of one problem that should probably be fixed before we
 declare a new recommended snapshot:

 * Comparison operations for 64bit integers will not work correctly
 for large values (> 2^53) because we are converting to double to
 do the conversions.
This job is done now, but probably needs a little more testing.
 and two more that would be nice to fix:

 * 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.
 * Concatenation of simple matrix objects should use a more memory
 efficient method as was done in earlier versions of Octave (but
 the new code has the distinct advantage of allowing concatenation
 for userdefined types, so we can't simply revert to the previous
 method).
David Bateman improved the concat functions, but it is still not clear
to me whether the current method is as efficient as the original
method for concatenation of the builtin matrix objects (real,
complex, character) as the current method still appears to work
pairwise for expressions like
[a, b, c, d, e]
so more temporaries are formed than should be needed if we were
working on the entire list at once (the original code scanned the
entire list to determine the size and type of the result, then created
an object to hold it, then filled it with a series of insert
operations). I understand that this won't work well for userdefined
types and {horz,vert}cat functions, but perhaps it could still be used
if the list only contains the builtin matrix types.
jwe


On 9Nov2004, I wrote:
 On 5Nov2004, 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


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 < [hidden email]> (on 11/10/04):
> On 9Nov2004, I wrote:
>
>  On 5Nov2004, 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 [hidden email]
Motorola CRM +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 GifSurYvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


According to John W. Eaton < [hidden email]> (on 11/09/04):
>  * Concatenation of simple matrix objects should use a more memory
>  efficient method as was done in earlier versions of Octave (but
>  the new code has the distinct advantage of allowing concatenation
>  for userdefined types, so we can't simply revert to the previous
>  method).
>
> David Bateman improved the concat functions, but it is still not clear
> to me whether the current method is as efficient as the original
> method for concatenation of the builtin matrix objects (real,
> complex, character) as the current method still appears to work
> pairwise for expressions like
>
> [a, b, c, d, e]
>
> so more temporaries are formed than should be needed if we were
> working on the entire list at once (the original code scanned the
> entire list to determine the size and type of the result, then created
> an object to hold it, then filled it with a series of insert
> operations). I understand that this won't work well for userdefined
> types and {horz,vert}cat functions, but perhaps it could still be used
> if the list only contains the builtin matrix types.
The code is effectively no different than the previous concatenation code
now, with two exceptions.
We don't resize the first argument and concatenate the others into as
previous, but resize to zero, then the right size and concatenate all
of the objects into this empty matrix. I did this as it turns out that
resize_no_fill is slower than insert, due to the fact that
resize_no_fill does a large amount of error checking of the indexes.
Secondly, previously in ptmat.cc the copy of the final matrix was
defined locally and all other matrices concatenated into
this. However, now this matrix is passed to catop, so as you say a
temporary copy of the octave_value container of this matrix is
made. However the underlying ArrayRep value should be the same and so,
the overhead should be minimal.
As for speed, I still have a copy of 2.1.50 and comparing that for
speed against the code in the CVS I see the current code as much faster.
Taking ten trial and only considering the fastest one I get the following
octave2.1.50:3> a = randn(1,1e6); tic; b = [a;a]; toc
ans = 0.37588
octavecvs:6> a = randn(1,1e6); tic; b = [a;a]; toc
ans = 0.31921
So, yes there is a little memory overhead for the octave_value containers
of the temporary values, but its not too great. Also the speed of the new
code is about 20% faster for the "[]" operator due to the fact it doesn't
use resize_no_fill..
Cheers
David

David Bateman [hidden email]
Motorola CRM +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 GifSurYvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Here's what R14 does
>> a = [int8(1), int16(2)];
Warning: Concatenation with dominant (leftmost) integer class may overflow
other operands on conversion to return class.
>> b = [int16(1), int8(2)];
Warning: Concatenation with dominant (leftmost) integer class may overflow
other operands on conversion to return class.
>> c = [int8(1), 2];
>> d = [1, int8(2)];
>> whos
Name Size Bytes Class
a 1x2 2 int8 array
ans 1x2 2 int8 array
b 1x2 4 int16 array
c 1x2 2 int8 array
d 1x2 2 int8 array
Grand total is 10 elements using 12 bytes
and, of course, it does the intN / complex concatenations
>> e = [1 int8(3+2i)];
>> f = [3+2i, int8(4)];
>> whos e f
Name Size Bytes Class
e 1x2 4 int8 array (complex)
f 1x2 4 int8 array (complex)
Grand total is 4 elements using 8 bytes
Original Message
From: John W. Eaton [mailto: [hidden email]]
Sent: Tuesday, November 09, 2004 10:24 PM
To: octave maintainers mailing list
Subject: integer concatenation (was: Octave 2.1.61 available for ftp)
On 9Nov2004, I wrote:
 On 5Nov2004, 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


Forget it, it was my CVS that was out of sync... It builds now...
D.
According to David Bateman < [hidden email]> (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 < [hidden email]> (on 11/10/04):
> > On 9Nov2004, I wrote:
> >
> >  On 5Nov2004, 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 [hidden email]
> Motorola CRM +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
> 91193 GifSurYvette FRANCE
>
> The information contained in this communication has been classified as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary

David Bateman [hidden email]
Motorola CRM +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 GifSurYvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


On 10Nov2004, Hall, Benjamin < [hidden email]> wrote:
 Here's what R14 does

 >> a = [int8(1), int16(2)];
 Warning: Concatenation with dominant (leftmost) integer class may overflow
 other operands on conversion to return class.
 >> b = [int16(1), int8(2)];
 Warning: Concatenation with dominant (leftmost) integer class may overflow
 other operands on conversion to return class.
 >> c = [int8(1), 2];
 >> d = [1, int8(2)];
 >> whos
 Name Size Bytes Class

 a 1x2 2 int8 array
 ans 1x2 2 int8 array
 b 1x2 4 int16 array
 c 1x2 2 int8 array
 d 1x2 2 int8 array

 Grand total is 10 elements using 12 bytes
OK. Should we also issue a warning?
 and, of course, it does the intN / complex concatenations

 >> e = [1 int8(3+2i)];
 >> f = [3+2i, int8(4)];
 >> whos e f
 Name Size Bytes Class

 e 1x2 4 int8 array (complex)
 f 1x2 4 int8 array (complex)

 Grand total is 4 elements using 8 bytes
I don't expect that Octave will have integer complex values any time
soon.
Thanks,
jwe

