headers
Andy Adler | 2 Aug 2004 20:51
Picon
Favicon

Re: Help with [] for defined types

David,

Thanks for your help with this stuff. I still have some questions.

On Wed, 28 Jul 2004, David Bateman wrote:

> To get a reasonable speed the concatenation function precalcuates the
> size of the return type and then dimensions the return value before
> inserting the data into it. As the functions in pt-mat.cc
> (tree_matrix::rvalue) and data.cc (do_cat) know nothing of the types
> its concatenations (it hands that role off to do_catop), it uses a
> resize of the octave_value itself. For this reason you have to define
> in make_sparse.h something like
>
> #ifdef HAVE_OCTAVE_CONCAT
> octave_value
> octave_sparse::resize (const dim_vector& dv) const
> {
>   if (dv.length() > 2)
>     {
>       error ("Can not resize sparse matrix to NDArray");
>       return octave_value ();
>     }
>   SuperMatrix retval (*this);
>
>   // Do the magic needed to change the number of rows and columns while
>   // leaving the elements of retval alone //
>
>   return new octave_sparse (retval);
> }
(Continue reading)

Permalink | Reply | 835 comments |
headers
David Bateman | 3 Aug 2004 13:54

Re-implementation of inline functions

Dear All,

Coming back to the Octave 3.0 ToDo list, the things on it that haven't
yet been addressed are

  * some support for MPI
  * sparse matrices
  * finish implementation of cell arrays and struct arrays:
      -- cell(idx) = [] to delete elements
      -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
      -- allow [x{:}] = f (...) to work
      -- and other little details like this...
  * inline functions
  * private functions
  * bring the manual up to date

Two of the things on this list that interest me, are inline and
private functions [I hope that someone else has some interest
in the other points :-) ].

As I don't understand all that needs to be done for private functions
yet, I thought I'd attack the question of inline functions and see
what I could do. There is already a reasonable implementation within
octave-forge, but it has the disadvantage that it defines as many user
defined functions in the symbol table as there are inline functions,
and can implement the argnames and vectorize functions in a matlab
compatiable manner.

I re-implemented the same ideas in version in octave-forge as an
octave_value class. However, to get the function I extract its
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Bateman | 3 Aug 2004 15:29

Re: Help with [] for defined types

Hi Andy,

According to Andy Adler <adler <at> site.uottawa.ca> (on 08/02/04):
> I've done this, and it seems to be being called twice, the first time
> with dv=[0,0] and the second time with the right output size, but
> 
> echo 's=sparse(diag([1,3],1)); p=[s,s]' | octave -qfH
> DEBUG:sparse( void)
> installing sparse type at type-id = 40
> install sm_sm
> DEBUG:sparse - matrix_to_sparse
> DEBUG:sparse( SuperMatrix A)
> DEBUG:sparse_resize                  <--- calls sparse([1;2],[2;3],[1;3],0,0)
> DEBUG:sparse - assemble_sparse
> error: sparse row index out of range  <-- error because rows,cols= 0,0
> DEBUG:sparse( SuperMatrix A)
> DEBUG:sparse_resize                  <--- calls sparse([],[],[],3,6)
> DEBUG:sparse( SuperMatrix A)
> DEBUG:sparse destructor
> DEBUG:sparse destructor
> error: evaluating assignment expression near line 1, column 28
> 
> I don't understand why octave_sparse::resize is being called twice here
> Am I missing something?

The explanation is in the comment in tree_matrix::rvalue, which states

      // The line below might seem crazy, since we take a copy
      // of the first argument, resize it to be empty and then resize
      // it to be full. This is done since it means that there is no
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Eaton | 3 Aug 2004 19:23
Picon

Re-implementation of inline functions

On  3-Aug-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| Coming back to the Octave 3.0 ToDo list, the things on it that haven't
| yet been addressed are
| 
|   * some support for MPI

There is some work happening on this now.

|   * sparse matrices

Not sure about this.  My impression is that the current sparse code in
octave-forge would need some significant cleanup to be included in the
core Octave and that we might want to switch to using UMFPACK instead
of SuperLU (see for example the notes by Paul Kienzle here:
http://www.octave.org/mailing-lists/octave-maintainers/2002/219).

|   * finish implementation of cell arrays and struct arrays:
|       -- cell(idx) = [] to delete elements
|       -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
|       -- allow [x{:}] = f (...) to work
|       -- and other little details like this...

I've done some work on some of these problems but have not had time to
finish them.  The third item is a bit tricky and may require some
changes to the interface of the octave_value::subsasgn method, so this
is a priority for me if we are going to try to minimize internal
interface changes for the 3.x series.

|   * inline functions
(Continue reading)

Permalink | Reply | 8 comments |
headers
John W. Eaton | 3 Aug 2004 19:35
Picon

Re: How to implement IPT strel.m ?

[I'm moving this to the maintainers list.  --jwe]

On  3-Aug-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| Octave doesn't have classes. The fact is in discussion with Paul
| Kienzle, I've thought about the problem a bit. Implementing all of the
| infrastructure for classes in octave is pretty easy with the code that
| already exists.  What seems to me to be the hard bit is modifiying
| Octave itself so that the directory " <at> class" is interpret as a private
| directory that contains all of the functions specific to the class.
| 
| I'm not sure I understand all that would have to change within Octave
| to support private directories and so don't won't to tackle this
| problem, until I either completely understand how to implement private
| directories or someone has already done it.

The  <at> class directory hack is similar to the private function
subdirectory hack.  It will require some changes to the file lookup
code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
kpathsearch code and converted it C++ (use C++ strings, new/delete,
etc.) in anticipation of having to modify it to handle these new
features that are specific to Octave.  Also, I never liked the fact
that there was no clean separation between the basic file lookup code
and the TeX-specific features of the kpathsearch code.  Now the code
for file lookup that is actually used in Octave is much smaller than
before.  It is only about 3200 lines long in the file kpse.cc and the
file in CVS has about 600 lines that are not currently used, so it
could be even smaller.  We should be able to adapt this code and the
symbol lookup code in Octave's symbol table to do the right thing when
looking for functions once we define the proper search order.
(Continue reading)

Permalink | Reply | 3 comments |
headers
John W. Eaton | 3 Aug 2004 21:56
Picon

Squeeze works differently in Matlab

On  2-Jul-2004, Andy Adler <adler <at> site.uottawa.ca> wrote:

| I'm trying to get some code to run under Matlab and Octave,
| and I note that 'squeeze' works differently, if there is only
| one non-singleton dimention:
| 
| Matlab:
|     >> squeeze(rand(2,1,3))
|     ans =
|         0.4447    0.7919    0.7382
|         0.6154    0.9218    0.1763
| 
|     >> squeeze(rand(1,1,3))
|     ans =
|         0.4057
|         0.9355
|         0.9169
| 
| Octave (2.1.57 - today's CVS):
|     octave:1> squeeze(rand(2,1,3)) # This is OK
|     ans =
|       0.47701  0.72476  0.80614
|       0.64084  0.87862  0.71905
| 
|     octave:2> squeeze(rand(1,1,3)) # This is transposed wrt Matlab
|     ans =
|       0.839686  0.112393  0.016944

I also see that squeeze has no effect on 2-d arrays so that squeezing
a row vector does not convert it to a column vector.  Hmm.  So to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Bateman | 4 Aug 2004 09:40

Re: How to implement IPT strel.m ?

According to John W. Eaton <jwe <at> bevo.che.wisc.edu> (on 08/03/04):
> 
> The  <at> class directory hack is similar to the private function
> subdirectory hack.  It will require some changes to the file lookup
> code (in liboctave/pathsearch.cc).  Some time ago, I pared down the
> kpathsearch code and converted it C++ (use C++ strings, new/delete,
> etc.) in anticipation of having to modify it to handle these new
> features that are specific to Octave.  Also, I never liked the fact
> that there was no clean separation between the basic file lookup code
> and the TeX-specific features of the kpathsearch code.  Now the code
> for file lookup that is actually used in Octave is much smaller than
> before.  It is only about 3200 lines long in the file kpse.cc and the
> file in CVS has about 600 lines that are not currently used, so it
> could be even smaller.  We should be able to adapt this code and the
> symbol lookup code in Octave's symbol table to do the right thing when
> looking for functions once we define the proper search order.

Exactly. Any ideas what the right search order is. Do private functions
take precedence? What about those in a class? And what about structures
like  <at> class1/ <at> class2 that Matlab permits? Do they make any sense without
Simulink? Should we support them?

> I think the other tricks in supporting classes will be integrating the
> dispatch code with the core of Octave and supporing the strange class
> relationship hierarchy that Matlab has with "inferiorto" and
> "superiorto" (this will affect the way function searches are performed
> given the type of the first argument).

The stuff like superiorto, subsref, etc could be done with the
octave_value class that handles the function overloading. Stuff like
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Bateman | 4 Aug 2004 10:29

Re: Re-implementation of inline functions

According to John W. Eaton <jwe <at> bevo.che.wisc.edu> (on 08/03/04):
> On  3-Aug-2004, David Bateman <David.Bateman <at> motorola.com> wrote:
> 
> | Coming back to the Octave 3.0 ToDo list, the things on it that haven't
> | yet been addressed are
> | 
> |   * some support for MPI
> 
> There is some work happening on this now.

Ok...

> 
> |   * sparse matrices
> 
> Not sure about this.  My impression is that the current sparse code in
> octave-forge would need some significant cleanup to be included in the
> core Octave and that we might want to switch to using UMFPACK instead
> of SuperLU (see for example the notes by Paul Kienzle here:
> http://www.octave.org/mailing-lists/octave-maintainers/2002/219).

Also read the speed comparisions on the site

http://www.cise.ufl.edu/research/sparse/umfpack

UMFPACK is significantly faster than SuperLU. The site above also contains
the latest v4.3 of UMFPACK.

As the code is octave-forge has the distinction of existing and working 
already with octave, its probably the best starting point. Perhaps the
(Continue reading)

Permalink | Reply | 4 comments |
headers
John W. Eaton | 4 Aug 2004 20:33
Picon

cell(idx) = [] (was: Re: Re-implementation of inline functions)

On  4-Aug-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| > |   * finish implementation of cell arrays and struct arrays:
| > |       -- cell(idx) = [] to delete elements
| > |       -- a(1).x = 1; a(2).x = 2; a.x => c.s. list, [a.x] => num array
| > |       -- allow [x{:}] = f (...) to work
| > |       -- and other little details like this...
| > 
| > I've done some work on some of these problems but have not had time to
| > finish them.  The third item is a bit tricky and may require some
| > changes to the interface of the octave_value::subsasgn method, so this
| > is a priority for me if we are going to try to minimize internal
| > interface changes for the 3.x series.

| The first one seems pretty easy to me as the change is isolated to
| the '(' case of subsref for cell arrays, and examples of how to 
| treat this case already exist for NDArrays.

I think we need a special type (or some other way) to represent [] so
that it can be distinguished from "zeros (0, 0)".

jwe
Permalink | Reply | 1 comment |
headers
John W. Eaton | 4 Aug 2004 20:59
Picon

Re: Re-implementation of inline functions

On  4-Aug-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| The implementation I sent treats inline functions as function handles.
| See that is_function_handle returns true. Now that you made the changes
| to the octave_fcn_handle class I should probably make the octave_fcn_inline
| class inherit from octave_fcn_handle.
| 
| However I haven't implemented the syntax
| 
|  <at>  ( ARG_LIST ) EXPR
| 
| I don't have the latest release of Matlab and so not sure how this syntax 
| is treated. Is it an inline function or is it a function handle? Also is
| the presence of the "( )" what makes the difference between this and a
| normal function handle?

I also don't have a copy of the latest release of Matlab, so I am
going by the docs from the MathWorks web site.  This syntax is
metioned in the description of function handles, so I believe it
returns a function handle with no name, or a name like "<anonymous
function>" or something, though I don't know precisely since there is
no example for that in the docs.

| Yes, inline could be a special case of function handles in this case.
| However, we'd need someway of specifying that the function handle 
| points to a real physical function or to an inlined expression. We'd also
| need to adapt the function handle class to include a few extra privates
| to allow the function formula and argnames to work correctly.

Yes, you would probably want to cache the extra information.  I was
(Continue reading)

Permalink | Reply | 1 comment |

Gmane