Octave 3.0

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

Octave 3.0

John W. Eaton-6
I'd like to try to come up with a list of must-have items for the next
major release of Octave, then we can start making sure that all those
items are done (not necessarily complete, but at least implemented
well enough to be usable).

My current top 10 list is, more or less in order of importance:

  * some support for MPI

  * N-dimensional arrays

  * sparse matrices

  * clean up the load-save mess

  * extend cell arrays, struct arrays, and function handles to also be
    N-dimensional

  * 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...

  * [ ... ] should concatenate array-like objects other than matrices

  * inline functions

  * private functions

  * bring the manual up to date


Yes, this is a relatively large list, but I think it is possible to do
most of these things in the next six months or so.

It will probably help Octave a lot to have all of these things in a
new "stable"[2] release.  Perhaps that can happen by sometime this
coming (northern) summer (that would only be about a year later than I
had hoped for the last time I tried making a list like this).

Comments?

Thanks,

jwe


  [1] MPI is at the top because we have some code that is almost ready
      to be checked in.  The manual is at the bottom because I usually
      don't like working on it unless I can focus only on the manual
      for a few weeks.

  [2] Even if we call it "stable" I don't expect to try to do some
      kind of split "stable" vs. "development" releases unless someone
      steps forward to maintain the stable release.  It simply takes
      too much effort (for me, anywya) to try to maintain two
      branches.


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Paul Kienzle
John W. Eaton wrote:

>My current top 10 list is, more or less in order of importance:
>  
>
* Define an oct-file API so that oct-files will work
without recompilation throughout the 3.x series?

Paul Kienzle
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Per Persson
In reply to this post by John W. Eaton-6

On Saturday, February 22, 2003, at 02:47 AM, John W. Eaton wrote:

> I'd like to try to come up with a list of must-have items for the next
> major release of Octave, then we can start making sure that all those
> items are done (not necessarily complete, but at least implemented
> well enough to be usable).

[snip]

> Yes, this is a relatively large list, but I think it is possible to do
> most of these things in the next six months or so.

I'm a bit reluctant to speak up on this since what I am about to say is
i) not strictly a must-have ii) probably not doable in the above
timeframe iii) I'm completely tied down for the next 5-6 months so I
can't participate, but here goes:

I'd really like to see some kind of plotting API/abstract
class/interface whatever that sits between octave and any present
and/or future plotting solution.
I know this has been dicussed before, but mostly in the context of GUIs
and stuff. Certainly, it would be nice to have a similar solution for
all kinds of fancy widgets but the plotting part could probably be done
separately from buttons and sliders etc.

Just my 0.02 euro

/Per



Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

John W. Eaton-6
On 22-Feb-2003, Per Persson <[hidden email]> wrote:

| I'd really like to see some kind of plotting API/abstract
| class/interface whatever that sits between octave and any present
| and/or future plotting solution.

Maybe for 4.0?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

John W. Eaton-6
In reply to this post by Paul Kienzle
On 22-Feb-2003, Paul Kienzle <[hidden email]> wrote:

| * Define an oct-file API so that oct-files will work
| without recompilation throughout the 3.x series?

Provided that they stick to that API, I assume, with no guarantees if
they use any function from Octave's internals.

I think we can try for this, and it seems like a reasonable goal, but
it might cause some trouble.  What if instead we made the following
guarantee, for the version scheme major.minor.patch:

  * If the patch level changes, binary compatibility for .oct files is
    guaranteed.

  * If the minor version changes, you might have to recompile, but the
    interfaces won't change.

  * If the major version changes, then there may even be changes in
    the API at the source level, so you may need to fix your code just
    to recompile.

But until we have 3.0, we continue with the current method of (almost)
anything goes from one snapshot to the next.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Ole Jacob Hagen-2
In reply to this post by John W. Eaton-6
Hi.

As you might already know I'm making a new graphics handler to Octave.
It can be found at http://www.sourceforge.net/projects/oplot.

The feature of Oplot++, will satisfy the features mentioned in "Graphics and GUIs with Matlab" 2. edition.
This is a very ambitious project, but it's very rewarding to make it.
I've started a week ago, and I will try to get some functions to be ready medio March (12.-14. March).

My project is a part of the Zherlock project, and is a serious project. My developing will not suddenly stop as e.g kmatplot and goctave did.
We are actually trying to get more people to help on my valuable work.

Comments?

Cheers,

Ole




On Fri, 21 Feb 2003 19:47:55 -0600
"John W. Eaton" <[hidden email]> wrote:

> I'd like to try to come up with a list of must-have items for the next
> major release of Octave, then we can start making sure that all those
> items are done (not necessarily complete, but at least implemented
> well enough to be usable).
>
> My current top 10 list is, more or less in order of importance:
>
>   * some support for MPI
>
>   * N-dimensional arrays
>
>   * sparse matrices
>
>   * clean up the load-save mess
>
>   * extend cell arrays, struct arrays, and function handles to also be
>     N-dimensional
>
>   * 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...
>
>   * [ ... ] should concatenate array-like objects other than matrices
>
>   * inline functions
>
>   * private functions
>
>   * bring the manual up to date
>
>
> Yes, this is a relatively large list, but I think it is possible to do
> most of these things in the next six months or so.
>
> It will probably help Octave a lot to have all of these things in a
> new "stable"[2] release.  Perhaps that can happen by sometime this
> coming (northern) summer (that would only be about a year later than I
> had hoped for the last time I tried making a list like this).
>
> Comments?
>
> Thanks,
>
> jwe
>
>
>   [1] MPI is at the top because we have some code that is almost ready
>       to be checked in.  The manual is at the bottom because I usually
>       don't like working on it unless I can focus only on the manual
>       for a few weeks.
>
>   [2] Even if we call it "stable" I don't expect to try to do some
>       kind of split "stable" vs. "development" releases unless someone
>       steps forward to maintain the stable release.  It simply takes
>       too much effort (for me, anywya) to try to maintain two
>       branches.
______________________________________________________
Få den nye Yahoo! Messenger på http://no.messenger.yahoo.com/
Nye ikoner og bakgrunner, webkamera med superkvalitet og dobbelt så morsom


Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Lippert, Ross A.
In reply to this post by John W. Eaton-6

I think it is important to separate those items which are on this list
for the sake of MATLAB compatibility and those items on this list which
are for the general improvement of the package.  For example, MATLAB's
N-dimensional arrays are a convenient storage class, but they don't
interface with the mathematical operations very well.  Many times people
think they want an N-dimensional array because they are dealing with,
say a 3D mesh, but I think one quickly finds that it is more worthwhile
to keep these values in a 1D vector and the does 'reshape' as necessary.

An implementor trying to create
support for N-d arrays finds himself able to support things like sum and
prod, and .*, and various .m files, once he makes some painful changes to
their interfaces, only to find that * can never be defined well (though
perhaps if one used the notion of tensorial contraction one could get
something cool -- last time I checked MATLAB did nothing, but maybe that
has changed).

* Maybe I am just shooting my mouth off, but is there anyone out there who
makes any serious use of N-d arrays in their MATLAB work?

** On the other hand, if this is a move to further increase octave's .m
compatability, then it is necessary, however awful.

As for sparse matrices, I have gotten a lot of mileage out of a DLD function
Paul Kienzle and I came up with called idxop which does the following:
   y = idxop(idx,x,['sum'|'prod'|'max'|'min'])
where idx is an index vector whose length is equal to the number of rows of x
and the resulting y is essentially given by
   y = zeros(max(idx),size(x,2))+[0|1|-inf|inf]
   for i=1:size(x,1),
      y(idx(i),:) = [plus|times|max|min] ( y(idx(i),:), x(i,:) )
   endfor
This single function allows for a variety of sparse operations to occur on
regular vectors/matrices without the need for a sparse data structure.  The
advantage of doing things in terms of sparse ops and not sparse data is that
quite often the operations one wishes to perform are a mix of sparse and
dense ops (e.g. you have a graph laplacian on a disconnected graph and you
wish to form the dense laplacian for each graph component and take its
eigenvalues).  It is my belief that in practise, one spends quite a bit
of time doing 'sparse' and 'full' when using MATLAB sparse matrix functions
just so they can do a sparse op on their data at some point in the compute.

Again * and ** apply.

Private functions would be a nice way to clean up the ever growing octave
namespace, whether MATLAB allows this currently or not.

MPI support would raise a lot of eyebrows.  It is something my PhD advisor
was once trying to shoe-horn into a customized version of MATLAB, but with
little support from the mathworks.  Such a feature would really differentiate
octave.

An ABI for plotting isn't a bad idea at all.  Openning the door for a
gnuplot replacement would be wonderful.  Not that that isn't a mountain of
work to do.



-r

-----Original Message-----
From: John W. Eaton [mailto:[hidden email]]
Sent: Friday, February 21, 2003 8:48 PM
To: octave-maintainers mailing list
Subject: Octave 3.0


I'd like to try to come up with a list of must-have items for the next
major release of Octave, then we can start making sure that all those
items are done (not necessarily complete, but at least implemented
well enough to be usable).

My current top 10 list is, more or less in order of importance:

  * some support for MPI

  * N-dimensional arrays

  * sparse matrices

  * clean up the load-save mess

  * extend cell arrays, struct arrays, and function handles to also be
    N-dimensional

  * 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...

  * [ ... ] should concatenate array-like objects other than matrices

  * inline functions

  * private functions

  * bring the manual up to date


Yes, this is a relatively large list, but I think it is possible to do
most of these things in the next six months or so.

It will probably help Octave a lot to have all of these things in a
new "stable"[2] release.  Perhaps that can happen by sometime this
coming (northern) summer (that would only be about a year later than I
had hoped for the last time I tried making a list like this).

Comments?

Thanks,

jwe


  [1] MPI is at the top because we have some code that is almost ready
      to be checked in.  The manual is at the bottom because I usually
      don't like working on it unless I can focus only on the manual
      for a few weeks.

  [2] Even if we call it "stable" I don't expect to try to do some
      kind of split "stable" vs. "development" releases unless someone
      steps forward to maintain the stable release.  It simply takes
      too much effort (for me, anywya) to try to maintain two
      branches.



Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Alois Schlögl-2
In reply to this post by John W. Eaton-6


In a recent mail, you ranked 10 features for the next stable release. I'd like
to comment on two topics:

 * N-dimension array:
For multivariate signal analysis, n-dim array are very important. (e.g.
multivariate autoregressive parameters are a sequence of matrices; and
repeations of multichannel recordings). I'm able to handle this type of data
with the current octave (i.e. two-dimensional matrices) using some workarounds
(e.g. see TSA/MVAR). For this reason, N-dimensional arrays are not an important
topic. It is not crucial, if the implementation of N-dim is delayed. In the
list, N-dim arrays can be moved further down to a less important position.


 * Sparse matrices:
An important issue is the matrix multiplication of full and sparse matrices.
See the following example:

x = [-inf, -1, 0, 1, inf,nan];
sx= sparse(x);
full(x'*x)
full(sx'*sx)

The point is that under some circumstances (0*inf, 0*-inf, 0*nan), matrix
multiplications of full and sparse matrices give different results.
SPARSE can be used to control the desired behavior. Therefore, SPARSE is
important and, currently, there is no workaround. IMHO, SPARSE has top
priority.

These are my few thougths,
   Alois



> My current top 10 list is, more or less in order of importance:
>
>   * some support for MPI
>
>   * N-dimensional arrays
>
>   * sparse matrices
>
>   * clean up the load-save mess
>
>   * extend cell arrays, struct arrays, and function handles to also be
>     N-dimensional
>
>   * 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...
>
>   * [ ... ] should concatenate array-like objects other than matrices
>
>   * inline functions
>
>   * private functions
>
>   * bring the manual up to date

--


Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Andy Adler
On Wed, 26 Feb 2003, Schloegl Alois wrote:

>  * Sparse matrices:
> An important issue is the matrix multiplication of full and sparse matrices.
> See the following example:
>
> x = [-inf, -1, 0, 1, inf,nan];
> sx= sparse(x);
> full(x'*x)
> full(sx'*sx)
>
> The point is that under some circumstances (0*inf, 0*-inf, 0*nan), matrix
> multiplications of full and sparse matrices give different results.
> SPARSE can be used to control the desired behavior. Therefore, SPARSE is
> important and, currently, there is no workaround. IMHO, SPARSE has top
> priority.

Have you looked at the sparse matrix functions in octave-forge?
Are there any specific features lacking in that package?

Andy


Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Alois Schlögl-2
Zitat von Andy Adler <[hidden email]>:

> On Wed, 26 Feb 2003, Schloegl Alois wrote:
> >  * Sparse matrices:
> > An important issue is the matrix multiplication of full and sparse
> matrices.
> > See the following example:
> >
> > x = [-inf, -1, 0, 1, inf,nan];
> > sx= sparse(x);
> > full(x'*x)
> > full(sx'*sx)
> >
> > The point is that under some circumstances (0*inf, 0*-inf, 0*nan), matrix
> > multiplications of full and sparse matrices give different results.
> > SPARSE can be used to control the desired behavior. Therefore, SPARSE is
> > important and, currently, there is no workaround. IMHO, SPARSE has top
> > priority.
>
> Have you looked at the sparse matrix functions in octave-forge?
> Are there any specific features lacking in that package?
>
> Andy


Andy,

I was referring to John's priority list. IMO, it is a good thing, if sparse
arrays become part of core octave.

Unfortunately, I've only access to some outdated versions of Octave (2.1.40),
without a recent version of octave-forge. Hence, I can not say whether I miss a
specific feature in your sparse package. Only, the following example should
return the result below:


x = [-inf, -1, 0, 1, inf,nan];
sx= sparse(x);
full(x'*x)
full(sx'*sx)



ans =

   Inf   Inf   NaN  -Inf  -Inf   NaN
   Inf     1     0    -1  -Inf   NaN
   NaN     0     0     0   NaN   NaN
  -Inf    -1     0     1   Inf   NaN
  -Inf  -Inf   NaN   Inf   Inf   NaN
   NaN   NaN   NaN   NaN   NaN   NaN


ans =

   Inf   Inf     0  -Inf  -Inf   NaN
   Inf     1     0    -1  -Inf   NaN
     0     0     0     0     0     0
  -Inf    -1     0     1   Inf   NaN
  -Inf  -Inf     0   Inf   Inf   NaN
   NaN   NaN     0   NaN   NaN   NaN

Alois



--


Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Andy Adler
On Fri, 28 Feb 2003, Schloegl Alois wrote:
> I was referring to John's priority list. IMO, it is a good thing, if sparse
> arrays become part of core octave.
>
> Unfortunately, I've only access to some outdated versions of Octave (2.1.40),
> without a recent version of octave-forge. Hence, I can not say whether I miss a
> specific feature in your sparse package. Only, the following example should
> return the result below:
>
I get exactly your results:

octave:1> x = [-inf, -1, 0, 1, inf,nan];
octave:2> sx= sparse(x);
octave:3> full(x'*x)
ans =

   Inf   Inf   NaN  -Inf  -Inf   NaN
   Inf     1     0    -1  -Inf   NaN
   NaN     0     0     0   NaN   NaN
  -Inf    -1     0     1   Inf   NaN
  -Inf  -Inf   NaN   Inf   Inf   NaN
   NaN   NaN   NaN   NaN   NaN   NaN

octave:4> full(sx'*sx)
ans =

   Inf   Inf     0  -Inf  -Inf   NaN
   Inf     1     0    -1  -Inf   NaN
     0     0     0     0     0     0
  -Inf    -1     0     1   Inf   NaN
  -Inf  -Inf     0   Inf   Inf   NaN
   NaN   NaN     0   NaN   NaN   NaN

andy


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Joao Cardoso-2
In reply to this post by Alois Schlögl-2
On Wednesday 26 February 2003 21:47, Schloegl Alois wrote:
| In a recent mail, you ranked 10 features for the next stable release.
| I'd like to comment on two topics:
|
|  * N-dimension array:
| For multivariate signal analysis, n-dim array are very important.
| (e.g. multivariate autoregressive parameters are a sequence of
| matrices; and repeations of multichannel recordings). I'm able to
| handle this type of data with the current octave (i.e.
| two-dimensional matrices) using some workarounds (e.g. see TSA/MVAR).
| For this reason, N-dimensional arrays are not an important topic. It
| is not crucial, if the implementation of N-dim is delayed. In the
| list, N-dim arrays can be moved further down to a less important
| position.

Of course each one priorities are different.

Recently I had to redirect someone for using Tela instead of Octave
because of N-dimension arrays.

Joao


Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Paul Kienzle
In reply to this post by Lippert, Ross A.
Lippert, Ross A. wrote:

>I think it is important to separate those items which are on this list
>for the sake of MATLAB compatibility and those items on this list which
>are for the general improvement of the package.  For example, MATLAB's
>N-dimensional arrays are a convenient storage class, but they don't
>interface with the mathematical operations very well.  Many times people
>think they want an N-dimensional array because they are dealing with,
>say a 3D mesh, but I think one quickly finds that it is more worthwhile
>to keep these values in a 1D vector and the does 'reshape' as necessary.
>
reshape as currently implemented requires a matrix copy,
but that would be easy to fix.

There is something to be said for convenient data
structures, especially if it is convenient to operate
with slices.  The results are going to be more readable
than tricky indexing and reshaping operations.  It's
not clear to me that Matlab does the right thing --- not
while squeeze/reshape are required to transform a
slice using a matrix operation.

>* Maybe I am just shooting my mouth off, but is there anyone out there who
>makes any serious use of N-d arrays in their MATLAB work?
>
>** On the other hand, if this is a move to further increase octave's .m
>compatability, then it is necessary, however awful.
>
>As for sparse matrices, I have gotten a lot of mileage out of a DLD function
>Paul Kienzle and I came up with called idxop which does the following:
>   y = idxop(idx,x,['sum'|'prod'|'max'|'min'])
>where idx is an index vector whose length is equal to the number of rows of x
>and the resulting y is essentially given by
>   y = zeros(max(idx),size(x,2))+[0|1|-inf|inf]
>   for i=1:size(x,1),
>      y(idx(i),:) = [plus|times|max|min] ( y(idx(i),:), x(i,:) )
>   endfor
>This single function allows for a variety of sparse operations to occur on
>regular vectors/matrices without the need for a sparse data structure.  The
>advantage of doing things in terms of sparse ops and not sparse data is that
>quite often the operations one wishes to perform are a mix of sparse and
>dense ops (e.g. you have a graph laplacian on a disconnected graph and you
>wish to form the dense laplacian for each graph component and take its
>eigenvalues).  It is my belief that in practise, one spends quite a bit
>of time doing 'sparse' and 'full' when using MATLAB sparse matrix functions
>just so they can do a sparse op on their data at some point in the compute.
>
>Again * and ** apply.
>
* applies until you can provide recipes for
common 3-D and sparse operations that
unsophisticated users can apply --- yes you
can program everything in machine code but
macro assemblers sure help a lot.  The octave
wiki is a good forum for doing this:
    http://www.scarymath.org/octave

** applies while there exists interesting
code on the web that you want to use
without having to rewrite.

>Private functions would be a nice way to clean up the ever growing octave
>namespace, whether MATLAB allows this currently or not.
>
Not enough I expect.  To get that you need something
like namespace support.

>MPI support would raise a lot of eyebrows.  It is something my PhD advisor
>was once trying to shoe-horn into a customized version of MATLAB, but with
>little support from the mathworks.  Such a feature would really differentiate
>octave.
>
Has anyone looked at the PVM project for scilab?



Reply | Threaded
Open this post in threaded view
|

RE: Octave 3.0

Lippert, Ross A.
In reply to this post by John W. Eaton-6
(this post is long than I thought it would be.
contents:
  re: zero-copy reshape (and its myriad uses)
  re: sparse matrices
  re: matlab compatability
  re: MPI and PVM
)

re: zero-copy reshape
>reshape as currently implemented requires a matrix copy,
>but that would be easy to fix.
I agree that a copy is inconvenient.  Usually it is not an issue
since the other ops are more expensive than the copy.

But, one thing that I think could be really cool on this topic
is to abstract the block of doubles allocated to a matrix/vector
from the way the block is indexed, supporting multiple
views for the same data, e.g.:
 B = A'
or
 B = reshape(A,prod(size(A)),1)
would allocate no new memory for B, just create a new 'view'.  A new
block only gets allocated when one writes to an entry of B.  This
kind of view business should be compatable with the basic BLAS ops
since they allow transpose bits and strides to be set appropriately.

I noticed that GSL supports this trick, to the extent that
 v = A(1,:)
is just another view.  I'm not sure if they handle
 B = A([1 3 4],:)
as a view, and I don't see how one could do a gemm on such a B
without forcing a tmp copy.

BTW I am not an advocate of GSL-ing octave.  I've looked at some
of the GSL sources, and I'm not as impressed with the implementation
as I am with the interface.

>There is something to be said for convenient data
>structures, especially if it is convenient to operate
>with slices.  The results are going to be more readable
IMHO I'd change 'especially' to 'only'.  Sometimes the operations
we think we want aren't the right ones, and when we figure out what
ops we want, we figure out better representations for our data.

>than tricky indexing and reshaping operations.  It's
>not clear to me that Matlab does the right thing --- not
>while squeeze/reshape are required to transform a
>slice using a matrix operation.
Definitely.  I think it is very hard to work out what one
really should have basic ops on multidimensional data.  One
ugly, but sensible, thing one should have is something like
 C = CONTRACT(A,B,[2 3],[4 1])
where C(a,b,c) = SUM_{xy} A(a,x,y)*B(y,b,c,x)
but that's kind of nasty.  On the other hand one also can do
 C = reshape( reshape(A,na,nx*ny)*reshape( reshape(B,ny*nb*nc,nx)' ,nx*ny,nb*nc) ,na,nb,nc)
which is also kind of nasty, but at least it introduces no new ops
to the language.

And yes, you have to have the cock-eyed view of
matrices like I have , so you are right that this is for the
sophisticated user and not for everyone.  Maybe being forced
to do things like this makes one sophisticated.  Maybe I'd just
too proud of myself for tricks like this.

If zero-copy reshape/transpose were implemented, and some support
for inline functions were around, then perhaps one could just
write .m scripts to support N-D arrays and sparse matrices.

re: sparsity
For sparse matrices, I agree that idxop is definitely for sophisticates
and wrapping it up might require making some sort of special 'struct'
with some kind of overloading.  I'm kind of partial to some special
OO struct type which has a special field which says 'I have functions
in me', and then when someone does A*B and the interpreter sees that one
of them is a struct, and instead of the usual 'I don't know what to do with
structs' error message, it can check for the OO flag and look in the struct
fields for 'times' to pull out the appropriate functions.  This is a
nice way to take advantage of the fact that functions are first-class
(or nearly first class) objects in octave, and I think it is better than
MATLABs "greedy overloading by directory name" crap.

function s = sparse(A)
  [i,j,a] = find(A);
  s.OO = true;
  s.i = i;  s.j = j; s.a = a;
  s.times = sparse_times;
  s.plus  = sparse_plus;
  ...
endfunction

BTW just one last thing on idxop.  The thing that really necessitates it
is the fact that += doesn't do 'the right thing' (which may not be right
to some people) when the LHS is multiply indexed:
 v = zeros(2,1);
 v([1 2 2]) += 5
currently sets v = [5 5] instead of [5 10].  A sparse multiply could then
be
 [i,j,a] = find(A);
 y = zeros(size(A,1),1)
 y(i) += a.*x(j)
I had this argument before with some people on this list (and I'm content tha
my position may not be the right one), and I am aware that it would require
some serious fiddling with octave sources to do it my way.  Then there is
the issue of not having a max= or a min= operator for the other idxops,
though one might co-opt &= and |= for these services.

re: MATLAB compatability
The bit about rewriting code on the web is a really good one, for
which I don't have a good answer.  MATLAB has allowed people to
write some obnoxious things, and for octave to support that code
it needs to support some of these obnoxious things.  Perhaps, it
can be done with little change to octave other than some mods to
the basic operations then wrapped up in .m's.  That would be nice.

My point is that octave presents an opportunity not just to be
compatable with MATLAB, but to go that extra mile and do things
smarter than MATLAB.  (BTW another personal example of this is that
octave includes the LAPACK sylvester equation solver, which, to my
shock, MATLAB doesn't, and I was solving sylvester equations a lot
at one point and probably will need to again in the future).  I'd
like to see new features put in because it is a good idea, whether
from MATLAB or elsewhere, with a MATLAB-like interface when
applicable.

re: MPI and PVM
>Has anyone looked at the PVM project for scilab?
Three years ago I wrote some PVM DLD functions for octave.  The mkoctfile
script has become way more handy and useful for these purposes (either
that or I have learned how to use mkoctfile).  I had a lot of fun creating
matrices on one octave process and passing them to another octave process.
It was a fun toy, but it was a hack.  If someone would like to unhack it
it is at
http://www.eskimo.com/~ripper/research/pvmoct.html

I had thought of doing the same for MPI, but that whole ARGV thing made
me stop.


-r
-----Original Message-----
From: Paul Kienzle [mailto:[hidden email]]
Sent: Saturday, March 01, 2003 7:32 AM
To: Lippert, Ross A.
Cc: octave-maintainers mailing list
Subject: Re: Octave 3.0


Lippert, Ross A. wrote:

>I think it is important to separate those items which are on this list
>for the sake of MATLAB compatibility and those items on this list which
>are for the general improvement of the package.  For example, MATLAB's
>N-dimensional arrays are a convenient storage class, but they don't
>interface with the mathematical operations very well.  Many times people
>think they want an N-dimensional array because they are dealing with,
>say a 3D mesh, but I think one quickly finds that it is more worthwhile
>to keep these values in a 1D vector and the does 'reshape' as necessary.
>
reshape as currently implemented requires a matrix copy,
but that would be easy to fix.

There is something to be said for convenient data
structures, especially if it is convenient to operate
with slices.  The results are going to be more readable
than tricky indexing and reshaping operations.  It's
not clear to me that Matlab does the right thing --- not
while squeeze/reshape are required to transform a
slice using a matrix operation.

>* Maybe I am just shooting my mouth off, but is there anyone out there who
>makes any serious use of N-d arrays in their MATLAB work?
>
>** On the other hand, if this is a move to further increase octave's .m
>compatability, then it is necessary, however awful.
>
>As for sparse matrices, I have gotten a lot of mileage out of a DLD function
>Paul Kienzle and I came up with called idxop which does the following:
>   y = idxop(idx,x,['sum'|'prod'|'max'|'min'])
>where idx is an index vector whose length is equal to the number of rows of x
>and the resulting y is essentially given by
>   y = zeros(max(idx),size(x,2))+[0|1|-inf|inf]
>   for i=1:size(x,1),
>      y(idx(i),:) = [plus|times|max|min] ( y(idx(i),:), x(i,:) )
>   endfor
>This single function allows for a variety of sparse operations to occur on
>regular vectors/matrices without the need for a sparse data structure.  The
>advantage of doing things in terms of sparse ops and not sparse data is that
>quite often the operations one wishes to perform are a mix of sparse and
>dense ops (e.g. you have a graph laplacian on a disconnected graph and you
>wish to form the dense laplacian for each graph component and take its
>eigenvalues).  It is my belief that in practise, one spends quite a bit
>of time doing 'sparse' and 'full' when using MATLAB sparse matrix functions
>just so they can do a sparse op on their data at some point in the compute.
>
>Again * and ** apply.
>
* applies until you can provide recipes for
common 3-D and sparse operations that
unsophisticated users can apply --- yes you
can program everything in machine code but
macro assemblers sure help a lot.  The octave
wiki is a good forum for doing this:
    http://www.scarymath.org/octave

** applies while there exists interesting
code on the web that you want to use
without having to rewrite.

>Private functions would be a nice way to clean up the ever growing octave
>namespace, whether MATLAB allows this currently or not.
>
Not enough I expect.  To get that you need something
like namespace support.

>MPI support would raise a lot of eyebrows.  It is something my PhD advisor
>was once trying to shoe-horn into a customized version of MATLAB, but with
>little support from the mathworks.  Such a feature would really differentiate
>octave.
>
Has anyone looked at the PVM project for scilab?




Reply | Threaded
Open this post in threaded view
|

Re: Octave 3.0

Etienne Grossmann-4

  Hello,

  this is just to add my 2c to the multi-dimensional array
discussion. In fact, these 2c come from the manpage of pdl (Perl Data
Language - pdl.sourceforge.org), which support arbitray number of
dimensions, slices that are not copied, dimension reshuffling etc.

======================================================================
NAME
       PDL::Slices -- Stupid index tricks

SYNOPSIS
         use PDL;
         $a = ones(3,3);
         $b = $a->slice('-1:0,(1)');
         $c = $a->dummy(2);


DESCRIPTION
       This package provides many of the powerful PerlDL core index manipula­
       tion routines. These routines are usually two-way so you can get a
       unit matrix by

        $a = zeroes(1000,1000);
        $a->diagonal(0,1) ++;

       which is usually fairly efficient. See PDL::Indexing and PDL::Tips for
       more examples.

       These functions are usually two-way:

        $b = $a->slice("1:3");
        $b += 5;               # $a is changed!

       If you want to force a copy and no "flow" backwards, you need

        $b = $a->slice("1:3")->copy;
        $b += 5;               # $a is not changed.
======================================================================

  Cheers,

  Etienne

On Mon, Mar 03, 2003 at 09:49:32AM -0500, Lippert, Ross A. wrote:
# (this post is long than I thought it would be.
# contents:
#   re: zero-copy reshape (and its myriad uses)
#   re: sparse matrices
#   re: matlab compatability
#   re: MPI and PVM
# )
#
# re: zero-copy reshape
# >reshape as currently implemented requires a matrix copy,
# >but that would be easy to fix.
# I agree that a copy is inconvenient.  Usually it is not an issue
# since the other ops are more expensive than the copy.
#
# But, one thing that I think could be really cool on this topic
# is to abstract the block of doubles allocated to a matrix/vector
# from the way the block is indexed, supporting multiple
# views for the same data, e.g.:
#  B = A'
# or
#  B = reshape(A,prod(size(A)),1)
# would allocate no new memory for B, just create a new 'view'.  A new
# block only gets allocated when one writes to an entry of B.  This
# kind of view business should be compatable with the basic BLAS ops
# since they allow transpose bits and strides to be set appropriately.
#
# I noticed that GSL supports this trick, to the extent that
#  v = A(1,:)
# is just another view.  I'm not sure if they handle
#  B = A([1 3 4],:)
# as a view, and I don't see how one could do a gemm on such a B
# without forcing a tmp copy.
#
# BTW I am not an advocate of GSL-ing octave.  I've looked at some
# of the GSL sources, and I'm not as impressed with the implementation
# as I am with the interface.
#
# >There is something to be said for convenient data
# >structures, especially if it is convenient to operate
# >with slices.  The results are going to be more readable
# IMHO I'd change 'especially' to 'only'.  Sometimes the operations
# we think we want aren't the right ones, and when we figure out what
# ops we want, we figure out better representations for our data.
#
# >than tricky indexing and reshaping operations.  It's
# >not clear to me that Matlab does the right thing --- not
# >while squeeze/reshape are required to transform a
# >slice using a matrix operation.
# Definitely.  I think it is very hard to work out what one
# really should have basic ops on multidimensional data.  One
# ugly, but sensible, thing one should have is something like
#  C = CONTRACT(A,B,[2 3],[4 1])
# where C(a,b,c) = SUM_{xy} A(a,x,y)*B(y,b,c,x)
# but that's kind of nasty.  On the other hand one also can do
#  C = reshape( reshape(A,na,nx*ny)*reshape( reshape(B,ny*nb*nc,nx)' ,nx*ny,nb*nc) ,na,nb,nc)
# which is also kind of nasty, but at least it introduces no new ops
# to the language.
#
# And yes, you have to have the cock-eyed view of
# matrices like I have , so you are right that this is for the
# sophisticated user and not for everyone.  Maybe being forced
# to do things like this makes one sophisticated.  Maybe I'd just
# too proud of myself for tricks like this.
#
# If zero-copy reshape/transpose were implemented, and some support
# for inline functions were around, then perhaps one could just
# write .m scripts to support N-D arrays and sparse matrices.
#
# re: sparsity
# For sparse matrices, I agree that idxop is definitely for sophisticates
# and wrapping it up might require making some sort of special 'struct'
# with some kind of overloading.  I'm kind of partial to some special
# OO struct type which has a special field which says 'I have functions
# in me', and then when someone does A*B and the interpreter sees that one
# of them is a struct, and instead of the usual 'I don't know what to do with
# structs' error message, it can check for the OO flag and look in the struct
# fields for 'times' to pull out the appropriate functions.  This is a
# nice way to take advantage of the fact that functions are first-class
# (or nearly first class) objects in octave, and I think it is better than
# MATLABs "greedy overloading by directory name" crap.
#
# function s = sparse(A)
#   [i,j,a] = find(A);
#   s.OO = true;
#   s.i = i;  s.j = j; s.a = a;
#   s.times = sparse_times;
#   s.plus  = sparse_plus;
#   ...
# endfunction
#
# BTW just one last thing on idxop.  The thing that really necessitates it
# is the fact that += doesn't do 'the right thing' (which may not be right
# to some people) when the LHS is multiply indexed:
#  v = zeros(2,1);
#  v([1 2 2]) += 5
# currently sets v = [5 5] instead of [5 10].  A sparse multiply could then
# be
#  [i,j,a] = find(A);
#  y = zeros(size(A,1),1)
#  y(i) += a.*x(j)
# I had this argument before with some people on this list (and I'm content tha
# my position may not be the right one), and I am aware that it would require
# some serious fiddling with octave sources to do it my way.  Then there is
# the issue of not having a max= or a min= operator for the other idxops,
# though one might co-opt &= and |= for these services.
#
# re: MATLAB compatability
# The bit about rewriting code on the web is a really good one, for
# which I don't have a good answer.  MATLAB has allowed people to
# write some obnoxious things, and for octave to support that code
# it needs to support some of these obnoxious things.  Perhaps, it
# can be done with little change to octave other than some mods to
# the basic operations then wrapped up in .m's.  That would be nice.
#
# My point is that octave presents an opportunity not just to be
# compatable with MATLAB, but to go that extra mile and do things
# smarter than MATLAB.  (BTW another personal example of this is that
# octave includes the LAPACK sylvester equation solver, which, to my
# shock, MATLAB doesn't, and I was solving sylvester equations a lot
# at one point and probably will need to again in the future).  I'd
# like to see new features put in because it is a good idea, whether
# from MATLAB or elsewhere, with a MATLAB-like interface when
# applicable.
#
[snip]


--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne