octave-dev — GNU Octave developers' list

[OctDev] octave translation project - partial polish translation - not formatted

[Boud R. <bo...@as...>]

Dear octave-dev,

A translation of about 9-10 sections of the octave documentation - from
the point of view of a reader, i.e. not at all integrated into the
source tree - in polish - is available here:

http://cosmo.torun.pl/cgi-bin/twiki/view/Cosmo/OctavePl


It would be a pity if this work gets lost - several people did a lot of
good work in doing the translation.

IMHO at least some sort of link to this, or the file itself - the file
is essentially in <pre>pre</pre> html format - i could attach it or
someone can just copy/paste - should go somewhere in the source tree,
so that anybody working more "systematically" on polish translation
can at least know about it, maybe do some cutting/pasting rather than
starting from zero.

i realise that, with hindsight, it may have been better to find out the
"right" way to translate right from the beginning. In any case, maybe this
could at least motivate some polish-english speaking people to work further
on this. :)

Since the translations are translations of GPL material, i assume that they
automatically are covered by the GPL.

cheers
boud

[OctDev] updating DOCSTRINGS translation

[Jorge B. de A. <fic...@so...>]

Hi for all.
I have two directories:

directory "new" with updated docstrigs after "split_docstrings" script appl=
ied
directory "old" with the same files but with old form.

The question is:
How i compare it with via md5 string to know which files need update=20
translation?
There is some already created script?
Thanks
=2D-=20
Data Estelar 2453672.158171
http://www.solar.com.br/~ficmatin
Desejo-lhe Paz, Vida Longa e Prosperidade.
S=E3o Bem Vindas Mensagens no Formato Texto Gen=E9rico com Acentos.

[OctDev] Re: help spinv (2.9.3 version)

[Paul K. <pki...@us...>]

On Oct 26, 2005, at 3:55 AM, David Bateman wrote:

> Jorge Barros de Abreu a =E9crit :
>
>> How i receive a message saying to me that the file xxxxxxx was=20
>> changed?
>>
>>
> Jorge,
>
> I think you need to ask these questions to Paul, as I'm not sure how=20=

> the translation packages work. I believe he extracted the DOCSTRINGS=20=

> file and split it into individual files for you to translate though I=20=

> can't be sure that is how he did it. I believe that 2.9.4 will be=20
> released fairly soon from what John has been saying and so I'd suggest=20=

> that to have a solid base that when 2.9.4 is release Paul can create=20=

> or show you how to create a new set of base files from which to=20
> translate and check against...

David is correct.  We need to get the two DOCSTRINGS files from the new=20=

octave build and split them in octave-lang/base/octave/help with the=20
command octave-lang/admin/split_docstrings.  Then we do a cvs commit on=20=

that directory (to update all the revision numbers of the files that=20
have changed) and 'cvs rtag 2.9.4' in the octave/help directory.

Next we will need to write octave-lang/admin/listnew which lists the=20
files in the pt subtree which have a version number older than the=20
files in octave-lang/base.

Then we will need to write octave-lang/admin/changes which pops up a=20
'cvs diff' or 'tkdiff' between the version number listed in the=20
translated file and the latest version in the base archive.

- Paul

[OctDev] jpgread changed

[Teemu I. <tpi...@pc...>]

On 10/12/05, Stefan van der Walt <st...@su...> wrote:
> On Wed, Oct 12, 2005 at 07:32:23PM +0300, Teemu Ikonen wrote:
> > I have a rewrite of imread as an oct-file binding to libmagick++ in
> > the works. AFAIK Imagemagick supports all of the formats of the
> > current imread implementation or more and I found that reading some
> > formats to octave is 2 orders of magnitude faster with imagemagick.
> Is the libmagick++ API stable?  We experimented with it a while ago,
> and had problems over different versions.

I have no idea about the stability of the API, other than that Debian
seems to be having some sort of library transition going on with it at
the moment.

> What I don't like about that solution is that we'll be needing a lot
> of extra development headers, many of which we'll never use.  So we
> should probably look into making use of more ImageMagick functionality
> in other parts of the image toolbox as well.

We will have to use the library dependencies if we want to support
loading of large number of formats and IMHO we should. The solution to
octave-forge having dependencies to half of the world is to devise a
decent module system to Octave and split octave-forge to smaller
pieces.

Teemu

[OctDev] Re: adopting functions from Octave-forge

[John W. E. <jw...@be...>]

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

Re: [OctDev] x86_64 patches

[Paul K. <pki...@us...>]

On Sep 28, 2005, at 3:40 PM, Orion Poplawski wrote:

> Attached is a patch that allowed me to compile octave-forge-2005.06.13 
> on octave-2.9.2 x86_64.  Main issue is the changing of octave_idx_type 
> from int to long, so requiring a change of int variables to 
> octave_idx_type.
>

I'm surprised you needed to explicitly type constants such as 0,1,2 
which were parameters to functions, but I applied the changes anyway.  
With a minor tweak to octave-forge/configure.base, it even compiles for 
octave without octave_idx_type.

	- Paul

Re: [OctDev] jpgread changed

[Andy A. <an...@an...>]

On 10/12/05, Teemu Ikonen <tpi...@pc...> wrote:
> I have a rewrite of imread as an oct-file binding to libmagick++ in
> the works. AFAIK Imagemagick supports all of the formats of the
> current imread implementation or more and I found that reading some
> formats to octave is 2 orders of magnitude faster with imagemagick.
>
> I plan to support the imread interface documented at the Mathworks
> website as much as possible.

This is a great idea. I did not do this in the past because the libMagick++
API was not stable. Maybe it is now.

Imagemagick also implements lots of other algorithms. Maybe there
can be a generic way to access these api features.

Andy

Re: [OctDev] jpgread changed

[Stefan v. d. W. <st...@su...>]

On Wed, Oct 12, 2005 at 07:32:23PM +0300, Teemu Ikonen wrote:
> I have a rewrite of imread as an oct-file binding to libmagick++ in
> the works. AFAIK Imagemagick supports all of the formats of the
> current imread implementation or more and I found that reading some
> formats to octave is 2 orders of magnitude faster with imagemagick.

Is the libmagick++ API stable?  We experimented with it a while ago,
and had problems over different versions.

The current implementation of imread calls jpgread and pngread when
appropriate, so loading png and jpegs should be (almost) as fast as
when using libmagick.  ImageMagick requires libpng and libjpeg, but I
guess it would be safer to depend on their implementation.

What I don't like about that solution is that we'll be needing a lot
of extra development headers, many of which we'll never use.  So we
should probably look into making use of more ImageMagick functionality
in other parts of the image toolbox as well.

Regards
St=E9fan

Re: [OctDev] jpgread changed

[Teemu I. <tpi...@pc...>]

On 10/6/05, Paul Kienzle <pki...@us...> wrote:
> On Oct 5, 2005, at 5:28 PM, Andy Adler wrote:
> > On 10/4/05, Paul Kienzle <pki...@us...> wrote:
> >> Should we maintain support for [r,g,b]=3Djpgread... instead of forcing
> >> an nxmx3 matrix im=3Djpgread?
> >
> > jpgread was never officially part of Matlab AFAIK (a version was
> > posted by someone to comp.soft-sys.matlab in the early 90's). Thus we
> > are not breaking compatibility either way.
> >
> > OTOH, imread has not given [r,g,b] output since version 5.

I have a rewrite of imread as an oct-file binding to libmagick++ in
the works. AFAIK Imagemagick supports all of the formats of the
current imread implementation or more and I found that reading some
formats to octave is 2 orders of magnitude faster with imagemagick.

I plan to support the imread interface documented at the Mathworks
website as much as possible.

Teemu

Re: [OctDev] ginput

[Per P. <per...@ma...>]

On Oct 11, 2005, at 02:05, Paul Kienzle wrote:


> OS X:
>
>
>
>> The aqua term does not support mouse.  Any idea how much work it  
>> would be to add it?
>>

Not a lot, the foundation is there, i.e. passing events from AquaTerm  
to the aquaterm.trm driver.
See demos and PGPLOT driver in AquaTerm developer extras for some  
examples how to use events.

I dabbled with adding mouse support to gnuplot/aqua some years ago,  
but never quite got the hang of how it was supposed to work.  
Nowadays, I'm just too short of time to be of any real use...

In case anyone goes about adding mousing to aquaterm.trm, keep me  
posted and I'll try to help (at least I can commit the patches;-).

Regards,
Per

[OctDev] Re: ginput

[Petr M. <mi...@ph...>]

> I'm trying to get Petr Mikulik's ginput to work instead of the X11-based 
> ginput hack on octave-forge.
>
> Petr's function is cleaner than the current gget+ginput+grab.cc code, and it 
> should work on any terminal with mouse support rather than just X11. The 
> current gget is the source of too many support requests.

It would be nice to replace those routines written in C by this .m solution 
using the mousing gnuplot features directly.

>> I doubt it will work on cygwin since as of last year mkfifo was not 
>> supported.  Can a cygwin user please try it?

I remember OS/2 had an equivalent of opening a file with a name like
"//pipe/blabla"; I guess Windows could have a similar possibility?

>> The aqua term does not support mouse.  Any idea how much work it would be 
>> to add it?
>> 
>> Anyone have better luck with their systems?

Why X11 terminal does not work with mousing?

I guess the native Mac terminal is AquaTerm
   http://aquaterm.sourceforge.net/
   http://cvs.sourceforge.net/viewcvs.py/aquaterm/adapters/gnuplot/

have a look there if it is mousing, and if not, please contact the author 
and express your wish.

---
PM

[OctDev] ginput

[Paul K. <pki...@us...>]

Hi,

I'm trying to get Petr Mikulik's ginput to work instead of the 
X11-based ginput hack on octave-forge.

See section "Links" => "Programming interfaces - bidirectional 
interaction":

     http://gnuplot.sourceforge.net/links.html

Petr's function is cleaner than the current gget+ginput+grab.cc code, 
and it should work on any terminal with mouse support rather than just 
X11. The current gget is the source of too many support requests.

Unix:
>
> I'm assuming it works on X11 for Linux since that is where it was 
> developed, and for unix+x11 systems.  I haven't tested it.

Cygwin:

> I doubt it will work on cygwin since as of last year mkfifo was not 
> supported.  Can a cygwin user please try it?
>
> Assuming it does not work, maybe the gget code could be modified to 
> use the new input mouse command.
>
> Does it only work on X11?  Or does it also work with the Windows 
> native terminal?

OS X:

> The aqua term does not support mouse.  Any idea how much work it would 
> be to add it?
>
> I was unable to get mouse working on X11 using the 4.0.0 build at 
> sourceforge.  It works directly from gnuplot, but __gnuplot_raw__("set 
> mouse\r") doesn't work from Octave.
>
> Anyone have better luck with their systems?


Thanks,

- Paul

Re: [OctDev] doc wrong in weekday.m

[Paul K. <pki...@us...>]

On Sep 27, 2005, at 10:45 AM, Deepak Goel wrote:

>
> Forge's weekday fcn seems to be consistent with matlab.  Today is
> Tuesday.
>
>
>  octave:14> date
>  ans = 27-Sep-2005
>  octave:17> [d s]=weekday(now)
>  d = 3
>  s = Tue
>
>
> however, the doc seems wrong:
>
>      Takes a date (in either datenum format or a string that datenum
>      can parse) and returns the number for the day of the week (0 =
>      "Sun", 1 = "Mon", ... , "Sat")
>
>
> The doc says that Tue is 2, whereas it is really 3, both for the fcn,
> as well as in matlab.
>
> (Attached is a also diff fix and changelog entry.)
>
>


Applied.

Thanks,

	-Paul

Re: [OctDev] jpgread changed

[Paul K. <pki...@us...>]

On Oct 5, 2005, at 5:28 PM, Andy Adler wrote:

> On 10/4/05, Paul Kienzle <pki...@us...> wrote:
>> testimio is now failing because the output of jpgread has changed.
>>
>> Should we maintain support for [r,g,b]=jpgread... instead of forcing 
>> an nxmx3 matrix im=jpgread?
>
> jpgread was never officially part of Matlab AFAIK (a version was 
> posted by someone to comp.soft-sys.matlab in the early 90's). Thus we 
> are not breaking compatibility either way.
>
> OTOH, imread has not given [r,g,b] output since version 5.
>

Regardless, is it of value to the users of the image routines to be 
able to read directly into [r,g,b]?

If the answer is no, then someone needs to change testimio.

- Paul

Re: [OctDev] jpgread changed

[Andy A. <ad...@nc...>]

On 10/4/05, Paul Kienzle <pki...@us...> wrote:
> testimio is now failing because the output of jpgread has changed.
>
> Should we maintain support for [r,g,b]=3Djpgread... instead of forcing an
> nxmx3 matrix im=3Djpgread?

jpgread was never officially part of Matlab AFAIK (a version was posted
by someone to comp.soft-sys.matlab in the early 90's). Thus we are
not breaking compatibility either way.

OTOH, imread has not given [r,g,b] output since version 5.

Andy

[OctDev] jpgread changed

[Paul K. <pki...@us...>]

testimio is now failing because the output of jpgread has changed.

Should we maintain support for [r,g,b]=jpgread... instead of forcing an 
nxmx3 matrix im=jpgread?

- Paul

Re: [OctDev] Function 'now' off by an hour

[Paul K. <pki...@us...>]

I switched to use datenum(clock) in now.

I think the problem was that the offset from the current time zone to 
coordinated universal time changes throughout the year and I was using 
a constant offset from GMT to the current time zone.

Thanks,

	- Paul

On Oct 4, 2005, at 6:25 PM, Keith Goodman wrote:

> The octave-forge function 'now' is (for me) off by an hour:
>
>>> datestr(now)
> ans = 04-Oct-2005 14:20:59
>>> system('date')
> Tue Oct  4 15:21:03 PDT 2005
> ans = 0
>
> But the octave function 'clock' works:
>
>>> datestr(datenum(clock))
> ans = 04-Oct-2005 15:21:09
>
>
> -------------------------------------------------------
> 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
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Function 'now' off by an hour

[Keith G. <kwg...@gm...>]

The octave-forge function 'now' is (for me) off by an hour:

>> datestr(now)
ans =3D 04-Oct-2005 14:20:59
>> system('date')
Tue Oct  4 15:21:03 PDT 2005
ans =3D 0

But the octave function 'clock' works:

>> datestr(datenum(clock))
ans =3D 04-Oct-2005 15:21:09

Re: [OctDev] octave-forge near a releasable state?

[James R. P. <ant...@ya...>]

--- Paul Kienzle wrote:

> The minimum you need to generate a package for a CVS snapshot is to 
> rebuild the configure file:
> 
> 	./autogen.sh
> 
> Other things that should be done are documented at the head of 
> ./release.sh.
> 
> Are you planning a 2.9.xx release or a 2.1.xx release?
> 
> - Paul

I had not planned to do an octave 2.9 xx cygwin release, until it reaches
3.0.xx.  My goal for octave-forge was just to pull in the fixes I described
above.

I will try to follow the instructions in release.sh, and see how far I can get.

jrp

Re: [OctDev] octave-forge near a releasable state?

[Paul K. <pki...@us...>]

The minimum you need to generate a package for a CVS snapshot is to 
rebuild the configure file:

	./autogen.sh

Other things that should be done are documented at the head of 
./release.sh.

Are you planning a 2.9.xx release or a 2.1.xx release?

- Paul

On Oct 2, 2005, at 2:04 PM, James R. Phillips wrote:

> Is octave-forge at or near a releasable state?
>
> I'd like to do a new cygwin release, incorporating at least the recent 
> patches
> to legend.m and print.m.
>
> Would it be better patch the existing release, or could a new release 
> be made
> available soon at sourceforge?
>
> I did download the entire current source tree from anonymous cvs, but 
> looking
> at it I can see that additional steps are required to turn a cvs pull 
> into a
> release, which I didn't want to jump into right away.
>
> Jim Phillips
> volunteer cygwin maintainer for octave-forge
>
>
>
>
> -------------------------------------------------------
> 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
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] Re: (octave-forge) segfault in dlmread

[David B. <Dav...@mo...>]

Tom Bergan wrote:

>Hello, I believe there's a bug in dlmread - it segfaults when the file is empty.
> This fix works on my machine:
>
>line 159:
>  if((long int)flen == 0) {
>      // file is empty
>    ComplexMatrix cm(0,0);
>    retval(0) = cm;
>    return retval;
>  }
>  OCTAVE_LOCAL_BUFFER(char,line,(long int)flen)
>
>I'm not familiar enough with the code to know if this fix is suitable, so I
>haven't added this to CVS.
>
>-Tom Bergan
>
>  
>
I think I'd be inclined to do the patch something like the attached... 
However, its not my code and so I'll let someone else comment before 
applying it..

D.

-- 
David Bateman                                Dav...@mo...
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

[OctDev] octave-forge near a releasable state?

[James R. P. <ant...@ya...>]

Is octave-forge at or near a releasable state?

I'd like to do a new cygwin release, incorporating at least the recent patches
to legend.m and print.m.

Would it be better patch the existing release, or could a new release be made
available soon at sourceforge?

I did download the entire current source tree from anonymous cvs, but looking
at it I can see that additional steps are required to turn a cvs pull into a
release, which I didn't want to jump into right away.

Jim Phillips
volunteer cygwin maintainer for octave-forge 

Re: [OctDev] adopting functions from Octave-forge

[Paul K. <pki...@us...>]

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                                Dav...@mo...
> 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
>

Re: [OctDev] adopting functions from Octave-forge

[David B. <Dav...@mo...>]

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                                Dav...@mo...
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

Re: [OctDev] adopting functions from Octave-forge

[Paul K. <pki...@us...>]

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
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>