Re: A question on Matlab compatibility

[Peter Jensen]

Gents,

In relation to the discussion below,
could somebody clarify the procedure 
for reporting differences between mat*ab 
and octave-forge.

I found out that the scaling for pwelch in 
octave-forge is different from matlab,
but I was not sure  if I should report this 
as a bug.

If the scaling of pwelch was changed in
octave-forge it may break some peoples 
code. On the other hand the function is
not mat*ab compatible right now.

Peter

On Sun, 2006-09-17 at 11:19 -0400, John W. Eaton wrote:
> On 16-Sep-2006, Ron Crummett wrote:
> 
> | Maybe I'm missing something here, but I have always seen Octave-forge as 
> | an open-source attempt to include the functional extendability that the 
> | various Matlab toolboxes provides.
> 
> That is part of it, but the other more important part is that Octave
> Forge provides a central location for people to contribute code, and
> for people to work on it in a collaborative way.  It, like Octave, is
> a community project, and it is freely available.  So if you don't like
> what you see, you can help to improve it.  But just complaining will
> usually not cause the people who are doing the work to make
> improvements just to meet your needs.  In fact, it often has the
> opposite effect, of just annoying the people who have been doing the
> hard work.
> 
> | I have always been under the impression that to be included in 
> | Octave-forge, some requirements must be satisfied, in order to prevent 
> | anybody from writing some simple script and submitting it, only to have 
> | the rest of us in fits because we don't know how to use it.
> 
> I think pretty much anything with a free software license is accepted
> in the Octave Forge collection.  We tend to place more requirements on
> code that is distributed as a part of Octave itself (Texinfo doc
> strings, code formatting conventions, etc.).
> 
> | In the cases I have mentioned, I don't think it would be hard at all to 
> | provide more compatibility between Octave and Matlab.
> 
> Then please submit some patches to make it happen.
> 
> | For example, 
> | Matlab has the series function that performs a multiplication of two 
> | cascaded systems.  Octave has a function by the same name and with the 
> | same functionality, but when it is called displays a warning encouraging 
> | its users to use sysmult instead, a function whose name lends itself 
> | well to its performance.
> 
> You seem to be under the impression that these choices were made just
> to make things difficult for you and other users.  I doubt that is the
> case.  Most of the control functions for Octave were written before
> the MathWorks released the current interface for the Matlab control
> toolbox.  So it is not surprising that there are some differences.  It
> is not as if we made the interface incompatible just for the sake of
> being incompatible.  Again, if you would like to help improve things,
> then please submit some patches.  I don't think there is currently an
> active maintainer of the control functions in Octave, so it might help
> to have some people working on it.
> 
> | Heck, I'd do both of these if I knew I wasn't stepping 
> | on anyone's toes.
> 
> There is little need to worry about that around here.  It's not like
> we have so many people working on Octave that we are constantly
> bumping into each other.
> 
> | Perhaps a break-off of Octave-forge is needed, some sort of general code 
> | repository similar to the Matlab Central exchange.  Octave-forge could 
> | be preserved with the goal of Matlab toolbox compatibility (again, 
> | that's how I've always seen it) and Octave-central (call it what you 
> | will)  could be a third-party code submission where people submit their 
> | task-specific code.
> 
> We (mostly Soren and David) have been working on moving toward a
> package system for Octave to help encourage more contributions.  With
> the package system, it will be easier to install just the parts of
> the Octave Forge collection that you need rather than installing all
> of it.  It will also be easier for people to package and distribute
> their own collections of functions.  I'm hopeful that this will result
> in more contributions.
> 
> jwe
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave