adopting functions from Octave-forge

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

adopting functions from Octave-forge

John W. Eaton-6
Is anyone maintaining a list of functions that have been moved from
Octave to Octave-forge?  If so, where is it kept?  I'd like to add to
it as more functions are adopted.

Ignoring sparse functions, we currently have the following overlap:

  builtin   dispatch       hankel    mu2lin     randn       struct  
  cellstr   dispatch_help  isa     ndims rmfield     tf2zp    
  char    double         isequal   orient     setdiff     toeplitz
  chol    fieldnames     isfield   polyder    sortrows    tril  
  complex   full   ismember  polyderiv  str2double  triu  
  deal    gammaln        issparse  polygcd    strcmpi     unique  
  detrend   gammaln        isunix    print strmatch    unix  
  dispatch  grid   lin2mu    rand strncmp     zp2tf  

Some of these may still be different in Octave-forge, so the list
should also keep the current status of the function so that we don't
end up with two diverging versions of each of these.

jwe































Reply | Threaded
Open this post in threaded view
|

[OctDev] Re: adopting functions from Octave-forge

Quentin Spencer
John W. Eaton wrote:

>Is anyone maintaining a list of functions that have been moved from
>Octave to Octave-forge?  If so, where is it kept?  I'd like to add to
>it as more functions are adopted.
>  
>

Did you mean moved from octave-forge to octave?

>Ignoring sparse functions, we currently have the following overlap:
>
>  builtin   dispatch       hankel    mu2lin     randn       struct  
>  cellstr   dispatch_help  isa     ndims rmfield     tf2zp    
>  char    double         isequal   orient     setdiff     toeplitz
>  chol    fieldnames     isfield   polyder    sortrows    tril  
>  complex   full   ismember  polyderiv  str2double  triu  
>  deal    gammaln        issparse  polygcd    strcmpi     unique  
>  detrend   gammaln        isunix    print strmatch    unix  
>  dispatch  grid   lin2mu    rand strncmp     zp2tf  
>
>Some of these may still be different in Octave-forge, so the list
>should also keep the current status of the function so that we don't
>end up with two diverging versions of each of these.
>  
>

Maybe we should use the wiki for this. However, I'm under the impression
that the wiki has become much less active since the security was
tightened. Maybe we need to consider a new way of dealing with it.
Fedora Extras makes very good use of a wiki for collaborating on things.
Users must create an account and have edit permission explicitly
approved by someone. If the approval system for this were simple enough
(moderator receives an e-mail with link to approve), I'm sure it
wouldn't be too much of a burden to maintain.

-Quentin



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: adopting functions from Octave-forge

John W. Eaton-6
On 29-Sep-2005, Quentin Spencer wrote:

| John W. Eaton wrote:
|
| >Is anyone maintaining a list of functions that have been moved from
| >Octave to Octave-forge?  If so, where is it kept?  I'd like to add to
| >it as more functions are adopted.
|
| Did you mean moved from octave-forge to octave?

Yes, sorry about the mixup.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: adopting functions from Octave-forge

Andy Adler
In reply to this post by John W. Eaton-6
John,

I have begin looking at adapting some files from
your list for inclusion in octave. As I understand it,
the coding style needs to match octave's.

I've modified conv2.cc. Could you take a look to see if I
need to do anything else?

http://cvs.sourceforge.net/viewcvs.py/octave/octave-forge/main/image/conv2.cc?rev=HEAD

If this is acceptable, they I'll go any modify my other
code.

--
Andy Adler <[hidden email]> 1(613)562-5800x6218

On Thu, 29 Sep 2005, John W. Eaton wrote:

> Is anyone maintaining a list of functions that have been moved from
> Octave to Octave-forge?  If so, where is it kept?  I'd like to add to
> it as more functions are adopted.
>
> Ignoring sparse functions, we currently have the following overlap:
>
>   builtin   dispatch       hankel    mu2lin     randn       struct
>   cellstr   dispatch_help  isa     ndims rmfield     tf2zp
>   char    double         isequal   orient     setdiff     toeplitz
>   chol    fieldnames     isfield   polyder    sortrows    tril
>   complex   full   ismember  polyderiv  str2double  triu
>   deal    gammaln        issparse  polygcd    strcmpi     unique
>   detrend   gammaln        isunix    print strmatch    unix
>   dispatch  grid   lin2mu    rand strncmp     zp2tf
>
> Some of these may still be different in Octave-forge, so the list
> should also keep the current status of the function so that we don't
> end up with two diverging versions of each of these.
>
> jwe
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] adopting functions from Octave-forge

Paul Kienzle-3
In reply to this post by John W. Eaton-6
Given the minimal time I have for maintaining octave-forge
and in particular, for making sure that it stays in sync with
octave, I propose we delete what we can.

mu2lin and lin2mu: check the octave mailing list for bug
reports.  IIRC the octave-forge version is more compatible
with matlab.

tf2zp and zp2tf: check the octave mailing list for bug
reports.  IIRC there are some cases which fail in octave
but not in octave-forge.

rand, randn, randp, rande: much faster in octave-forge than in
octave, more bits of randomness and longer sequence. poisson_rnd
or whatever it is called now should call randp.

grid: octave-forge allows finer control of the grid such as
the number of tic marks and which axes they are shown for.

detrend: extra/nan and extra/tsa need to be resolved by Alois

chol: check whether octave-forge is faster, and whether it is
enough faster.


Eliminate the following:

polyder, polyderiv, polygcd, sortrows, isequal,cellstr
unique,ismember,setdiff, strcmpi, strmatch, strncmp, print
complex double char full sparse isspace. gammaln,
builtin,dispatch,dispatch_help,
fieldnames, isfield, rmfield,isa

hankel, toeplitz, tril, triu: these were attempts to trade
memory for speed.  I believe the speed gain is only for small
matrices which don't need it.  I think we should turf these.

- Paul

On Sep 29, 2005, at 12:12 PM, John W. Eaton wrote:

> Is anyone maintaining a list of functions that have been moved from
> Octave to Octave-forge?  If so, where is it kept?  I'd like to add to
> it as more functions are adopted.
>
> Ignoring sparse functions, we currently have the following overlap:
>
>   builtin   dispatch       hankel    mu2lin     randn       struct
>   cellstr   dispatch_help  isa     ndims rmfield     tf2zp
>   char    double         isequal   orient     setdiff     toeplitz
>   chol    fieldnames     isfield   polyder    sortrows    tril
>   complex   full   ismember  polyderiv  str2double  triu
>   deal    gammaln        issparse  polygcd    strcmpi     unique
>   detrend   gammaln        isunix    print strmatch    unix
>   dispatch  grid   lin2mu    rand strncmp     zp2tf
>
> Some of these may still be different in Octave-forge, so the list
> should also keep the current status of the function so that we don't
> end up with two diverging versions of each of these.
>
> jwe
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Octave-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] adopting functions from Octave-forge

David Bateman-3
Paul Kienzle wrote:

> Given the minimal time I have for maintaining octave-forge
> and in particular, for making sure that it stays in sync with
> octave, I propose we delete what we can.
>
> mu2lin and lin2mu: check the octave mailing list for bug
> reports.  IIRC the octave-forge version is more compatible
> with matlab.
>
> tf2zp and zp2tf: check the octave mailing list for bug
> reports.  IIRC there are some cases which fail in octave
> but not in octave-forge.
>
> rand, randn, randp, rande: much faster in octave-forge than in
> octave, more bits of randomness and longer sequence. poisson_rnd
> or whatever it is called now should call randp.
>
> grid: octave-forge allows finer control of the grid such as
> the number of tic marks and which axes they are shown for.
>
> detrend: extra/nan and extra/tsa need to be resolved by Alois
>
> chol: check whether octave-forge is faster, and whether it is
> enough faster.

I'll be getting rid of the chol stuff in octave-forge when I get to do
the same polymorphic solver code for the full matrices that I have for
the sparse matrices.. So get rid of it..

>
>
> Eliminate the following:
>
> polyder, polyderiv, polygcd,

I think I ported the differences from, this to octave...

> sortrows, isequal,cellstr
> unique,ismember,setdiff, strcmpi, strmatch, strncmp, print
> complex double char full sparse isspace. gammaln,
> builtin,dispatch,dispatch_help,
> fieldnames, isfield, rmfield,isa
>
> hankel, toeplitz, tril, triu: these were attempts to trade
> memory for speed.  I believe the speed gain is only for small
> matrices which don't need it.  I think we should turf these.

Be careful dumping these, like polyder, etc there might be some subtile
changes that are useful. They should each be examined carefully before
dumping them.

There are other problems with triu/tril in octave-forge for sparse
matrices, which I still haven't resolved.. I had an oct-file version of
triu/tril that did all types, and as the for-loops were in C++ there was
no trade-off speed/memory. However, John rejected this as he prefers to
keep as much as possible in m-files.. Maybe should revisit this..

Cheers
David


--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +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



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] adopting functions from Octave-forge

Paul Kienzle-3

On Sep 30, 2005, at 3:38 AM, David Bateman wrote:

> Paul Kienzle wrote:
>
>> Given the minimal time I have for maintaining octave-forge
>> and in particular, for making sure that it stays in sync with
>> octave, I propose we delete what we can.
>>
>> mu2lin and lin2mu: check the octave mailing list for bug
>> reports.  IIRC the octave-forge version is more compatible
>> with matlab.
>>
>> tf2zp and zp2tf: check the octave mailing list for bug
>> reports.  IIRC there are some cases which fail in octave
>> but not in octave-forge.
>>
>> rand, randn, randp, rande: much faster in octave-forge than in
>> octave, more bits of randomness and longer sequence. poisson_rnd
>> or whatever it is called now should call randp.
>>
>> grid: octave-forge allows finer control of the grid such as
>> the number of tic marks and which axes they are shown for.
>>
>> detrend: extra/nan and extra/tsa need to be resolved by Alois
>>
>> chol: check whether octave-forge is faster, and whether it is
>> enough faster.
>
> I'll be getting rid of the chol stuff in octave-forge when I get to do
> the same polymorphic solver code for the full matrices that I have for
> the sparse matrices.. So get rid of it..
>
>>
>>
>> Eliminate the following:
>>
>> polyder, polyderiv, polygcd
>
> I think I ported the differences from, this to octave...

Yes I saw that.  A syntax blind comparison would be nice, but it still
won't avoid the unnecessary () after if in octave or the unnecessary ,
after if in octave-forge.  The issues with linebreaks are also
difficult.

>
>> sortrows, isequal,cellstr
>> unique,ismember,setdiff, strcmpi, strmatch, strncmp, print
>> complex double char full sparse isspace. gammaln,
>> builtin,dispatch,dispatch_help,
>> fieldnames, isfield, rmfield,isa
>>
>> hankel, toeplitz, tril, triu: these were attempts to trade
>> memory for speed.  I believe the speed gain is only for small
>> matrices which don't need it.  I think we should turf these.
>
> Be careful dumping these, like polyder, etc there might be some
> subtile changes that are useful. They should each be examined
> carefully before dumping them.

I checked: unique, ismember, setdiff, sortrows strmatch, print, gammaln

I gave octave the benefit of the doubt on: fieldnames, isfield,
rmfield, struct, builtin, dispatch, dispatch_help, sparse, issparse,
full, complex, double, char

isequal should be checked.

>
> There are other problems with triu/tril in octave-forge for sparse
> matrices, which I still haven't resolved.. I had an oct-file version
> of triu/tril that did all types, and as the for-loops were in C++
> there was no trade-off speed/memory. However, John rejected this as he
> prefers to keep as much as possible in m-files.. Maybe should revisit
> this..
>
> Cheers
> David
>
>
> --
> David Bateman                                [hidden email]
> Motorola Labs - Paris                        +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
>



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: adopting functions from Octave-forge

John W. Eaton-6
In reply to this post by Quentin Spencer
On 29-Sep-2005, Quentin Spencer wrote:

| Did you mean moved from octave-forge to octave?

Yes.

| >Ignoring sparse functions, we currently have the following overlap:
| >
| >  builtin   dispatch       hankel    mu2lin     randn       struct  
| >  cellstr   dispatch_help  isa     ndims rmfield     tf2zp    
| >  char    double         isequal   orient     setdiff     toeplitz
| >  chol    fieldnames     isfield   polyder    sortrows    tril  
| >  complex   full   ismember  polyderiv  str2double  triu  
| >  deal    gammaln        issparse  polygcd    strcmpi     unique  
| >  detrend   gammaln        isunix    print strmatch    unix  
| >  dispatch  grid   lin2mu    rand strncmp     zp2tf  
| >
| >Some of these may still be different in Octave-forge, so the list
| >should also keep the current status of the function so that we don't
| >end up with two diverging versions of each of these.
|
| Maybe we should use the wiki for this. However, I'm under the impression
| that the wiki has become much less active since the security was
| tightened. Maybe we need to consider a new way of dealing with it.

The wiki is fine, if it is working.  Or, I can maintain a list and
keep it in the Octave CVS.  It doesn't matter to me.  I just wondered
whether anyone was keeping list.  I think we should have one, or we
are asking for more future confusion about which functions are the
latest and greatest.  Also, after a function has been moved to Octave,
that version should be the "master" source.  How can we make sure that
we won't modify the forge version and forget to update the Octave
version?

jwe