Octave 2.1.61 available for ftp

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave 2.1.61 available for ftp

John W. Eaton-6
Octave 2.1.61 is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  -rw-r--r--  1 1005  5500705 Nov  5 18:41 octave-2.1.61.tar.gz
  -rw-r--r--  1 1005  4328394 Nov  5 18:41 octave-2.1.61.tar.bz2
  -rw-r--r--  1 1005    40900 Nov  5 18:44 octave-2.1.60-2.1.61.patch.gz
  -rw-r--r--  1 1005    34372 Nov  5 18:44 octave-2.1.60-2.1.61.patch.bz2

  2fe3bd8465948609bfd65d96d24ee309  octave-2.1.61.tar.gz
  66416e4c219dd1f2a83ec45c6958396b  octave-2.1.61.tar.bz2
  9bcdfa5c486756b35df991c140346e3f  octave-2.1.60-2.1.61.patch.gz
  1e1ef60d3233d55a9a6f57b62714f0ad  octave-2.1.60-2.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 user-defined 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 64-bit 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 user-defined 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


Reply | Threaded
Open this post in threaded view
|

Octave 2.1.61 available for ftp

John W. Eaton-6
On  5-Nov-2004, I wrote:

| I know of one problem that should probably be fixed before we
| declare a new recommended snapshot:
|
|   * Comparison operations for 64-bit 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 user-defined 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 built-in matrix objects (real,
complex, character) as the current method still appears to work
pair-wise 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 user-defined
types and {horz,vert}cat functions, but perhaps it could still be used
if the list only contains the built-in matrix types.

jwe


Reply | Threaded
Open this post in threaded view
|

integer concatenation (was: Octave 2.1.61 available for ftp)

John W. Eaton-6
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


Reply | Threaded
Open this post in threaded view
|

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

David Bateman-3
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  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                                [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 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


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.61 available for ftp

David Bateman-3
In reply to this post by John W. Eaton-6
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 user-defined 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 built-in matrix objects (real,
> complex, character) as the current method still appears to work
> pair-wise 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 user-defined
> types and {horz,vert}cat functions, but perhaps it could still be used
> if the list only contains the built-in 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 pt-mat.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

octave-2.1.50:3> a = randn(1,1e6); tic; b = [a;a]; toc
ans = 0.37588

octave-cvs: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 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


Reply | Threaded
Open this post in threaded view
|

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

HALL, BENJAMIN            PW
In reply to this post by John W. Eaton-6
Here's what R14 does

>> a = [int8(1), int16(2)];
Warning: Concatenation with dominant (left-most) integer class may overflow
other operands on conversion to return class.
>> b = [int16(1), int8(2)];
Warning: Concatenation with dominant (left-most) 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  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


Reply | Threaded
Open this post in threaded view
|

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

David Bateman-3
In reply to this post by David Bateman-3
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  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                                [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 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                                [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 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


Reply | Threaded
Open this post in threaded view
|

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

John W. Eaton-6
In reply to this post by HALL, BENJAMIN PW
On 10-Nov-2004, Hall, Benjamin <[hidden email]> wrote:

| Here's what R14 does
|
| >> a = [int8(1), int16(2)];
| Warning: Concatenation with dominant (left-most) integer class may overflow
| other operands on conversion to return class.
| >> b = [int16(1), int8(2)];
| Warning: Concatenation with dominant (left-most) 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