operation x=x(:)

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

operation x=x(:)

Oliver Eichler
Hi

I am testing the ability of octave to replace MatLab in my company. One of the
biggest drawbacks to use it is the missing ´x=x(:)´ operation. For all not
knowing what it does: it will convert any colum or row vector into a colum
vector. Many of our MatLab scripts and toolboxes rely on this to convert any
vector into a defined state. I can´t realy imagine it is not implemented sofar.
but where do I have to hit octave to do it?

Another topic - if anyone of the maintainers is listening:
Taken the case I think octave is able to replace MatLab I would like to port
a good part of MatLab´s signal toolbox with the help of an internship. I would
be very happy if one of the ocatve team could tell me how this can be done
without violating the legal rights of MathWorks. Of course we would follow the
little pledge from octave´s signal toolbox help and share the results ;)

regards,

---
Oliver Eichler

DSP Solutions
Ingenieure Kellermann, Hoepfel, Voigt, Eichler, Weidner
Partnerschaft


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

A. Scottedward Hodel-2
>Hi
>
>I am testing the ability of octave to replace MatLab in my company. One of the
>biggest drawbacks to use it is the missing ¥x=x(:)¥ operation. For all not
>knowing what it does: it will convert any colum or row vector into a colum
>vector. Many of our MatLab scripts and toolboxes rely on this to convert any
>vector into a defined state. I can¥t realy imagine it is not implemented sofar.
>but where do I have to hit octave to do it?

    An equivalent function (for vectors x) in octave is
    x = vec(x)

    octave:1> vec([1 2])
    ans =

      1
      2

    octave:2> vec([1;2])
    ans =

      1
      2

    although this will fail to warn you if the initial value of x was not
    a vector (row or column).

    octave:3> vec([1 2; 3 4])
    ans =

      1
      3
      2
      4

    The behavior you've described would require editing the octave C++ source;
    John Eaton could address the "where" much better than I could.  I think that
    this sort of topic was addressed in the help list a year or so ago, but
    I don't recall the conclusion that was drawn.

>Another topic - if anyone of the maintainers is listening:
>Taken the case I think octave is able to replace MatLab I would like to port
>a good part of MatLab¥s signal toolbox with the help of an internship. I would
>be very happy if one of the ocatve team could tell me how this can be done
>without violating the legal rights of MathWorks. Of course we would follow the
>little pledge from octave¥s signal toolbox help and share the results ;)

    Regarding "porting" a toolbox: to avoid ethical and copyright problems,
    it is important that one rather "develops" a toolbox without reference to
    the matlab  toolboxes.  It *is* a lot of work.  However, the end result may
    be more pleasing, since in the development of a new toolbox you can try to
    correct the annoyances you've had to deal with in the Matlab toolbox (whatever
    they might be).  

    Do take a look at the controls toolbox; there may be some items there that
    you'd like to take advantage of in such a rewrite (data structure, frequency
    response, block diagram manipulations, analog<->digital, etc.)

A S Hodel Assoc. Prof. Dept Elect Eng, Auburn Univ,AL  36849-5201
On leave at NASA Marshall Space Flight Center (256) 544-1426
Address until 15 Mar 2000:Mail Code ED-13, MSFC, Alabama, 35812
http://www.eng.auburn.edu/~scotte


Reply | Threaded
Open this post in threaded view
|

operation x=x(:)

John W. Eaton-6
In reply to this post by Oliver Eichler
On  5-May-1999, [hidden email] <[hidden email]> wrote:

| I am testing the ability of octave to replace MatLab in my
| company.

If you do decide to use Octave instead of (or in addition to) Matlab
at your company, please consider funding the future development of
Octave.

| One of the biggest drawbacks to use it is the missing
| ´x=x(:)´ operation.

I'm not sure why you say that it is missing.  Octave has understood
colon indexing for a long time.  In versions 2.0.12 and later, I
believe that it works in a Matlab-compatible way no matter what the
value of do_fortran_indexing.  For earlier versions, you had to set
do_fortran_indexing to 1 (or, for really ancient versions, "yes") to
enable compatible behavior.

  GNU Octave, version 2.0.14 (i686-pc-linux-gnu).
  Copyright (C) 1996, 1997, 1998, 1999 John W. Eaton.
  This is free software with ABSOLUTELY NO WARRANTY.
  For details, type `warranty'.

  octave:1> x = rand (2)
  x =

    0.14962  0.13838
    0.98633  0.30464

  octave:2> x = x(:)
  x =

    0.14962
    0.98633
    0.13838
    0.30464

| Another topic - if anyone of the maintainers is listening: Taken the
| case I think octave is able to replace MatLab I would like to port a
| good part of MatLab´s signal toolbox with the help of an
| internship. I would be very happy if one of the ocatve team could
| tell me how this can be done without violating the legal rights of
| MathWorks. Of course we would follow the little pledge from
| octave´s signal toolbox help and share the results ;)

If you want an interpretation of the Matlab copyright and license, I
think it would make more sense to ask someone at the MathWorks for an
official statement on the issue.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

Jonathan King-2
In reply to this post by Oliver Eichler

On Wed, 5 May 1999, A. Scottedward Hodel wrote:

> [an orignal poster whose attribution was lost in editing wrote:
> >
> >I am testing the ability of octave to replace MatLab in my company.
> >One of the biggest drawbacks to use it is the missing x=x(:)
> >operation.

[snip]

> The behavior you've described would require editing the octave C++ source;
> John Eaton could address the "where" much better than I could.  

Now, that would be a pretty "braindead" thing to do. :-)  

But seriously, you can get this "traditional" Matlab feature and many
others by invoking Octave with either of these switches:

--traditional
--braindead

Although I find "--braindead" the more satisfying of the two.  So for
example:

[king@babar king]$ /usr/bin/octave --braindead
Octave, version 2.0.13 (i386-redhat-linux-gnu).
Copyright (C) 1996, 1997, 1998 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.

>> x=ones(2,3);
>> x(:)
ans =

  1
  1
  1
  1
  1
  1

>> exit
[king@babar king]$

(No...I haven't upgraded to 2.0.14 yet; my default Octave is 2.1.x)
 
jking



Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

Oliver Eichler
In reply to this post by A. Scottedward Hodel-2
>     The behavior you've described would require editing the octave C++
> source;
>     John Eaton could address the "where" much better than I could.  I think

Ok, I will try to contact him.

>     Regarding "porting" a toolbox: to avoid ethical and copyright problems,
>     it is important that one rather "develops" a toolbox without reference to
>     the matlab  toolboxes.  It *is* a lot of work.  However, the end result

That´s what I expected :). What about the MatLab interfaces. You see, my
problem is that I have to write MatLab simulations for my customers. They do
not care what tool I use as long as the script runs flawlessly on their MatLab.
Do you know anything about copyrights on calling interfaces? It looks like
octave has no problems on that.


Thanks for your help.

---
Oliver Eichler

DSP Solutions
Ingenieure Kellermann, Hoepfel, Voigt, Eichler, Weidner
Partnerschaft


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

wkim+
In reply to this post by John W. Eaton-6
John W. Eaton wrote:

>
> On  5-May-1999, [hidden email] <[hidden email]> wrote:
>
> | One of the biggest drawbacks to use it is the missing
> | 'x=x(:)' operation.
>
> I'm not sure why you say that it is missing.  Octave has understood
> colon indexing for a long time.  In versions 2.0.12 and later, I
> believe that it works in a Matlab-compatible way no matter what the
> value of do_fortran_indexing.  For earlier versions, you had to set
> do_fortran_indexing to 1 (or, for really ancient versions, "yes") to
> enable compatible behavior.
>
>   GNU Octave, version 2.0.14 (i686-pc-linux-gnu).
>   Copyright (C) 1996, 1997, 1998, 1999 John W. Eaton.
>   This is free software with ABSOLUTELY NO WARRANTY.
>   For details, type `warranty'.
>
>   octave:1> x = rand (2)
>   x =
>
>     0.14962  0.13838
>     0.98633  0.30464
>
>   octave:2> x = x(:)
>   x =
>
>     0.14962
>     0.98633
>     0.13838
>     0.30464

However, x = x(:) does not convert a row vector to a column vector
(Octave 2.0.13 for OS/2).  Though I don't mind this, but the
original poster would, as this is a different behavior from Matlab.

//-------------------------------------------------------------------
// Wonkoo Kim <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

Oliver Eichler
In reply to this post by Jonathan King-2
>
> Now, that would be a pretty "braindead" thing to do. :-)  
>
> But seriously, you can get this "traditional" Matlab feature and many
> others by invoking Octave with either of these switches:
>
> --traditional
> --braindead

That´s it! Thanks!

I better do not ask why it is called "braindead", do I?

regards,

---
Oliver Eichler

DSP Solutions
Ingenieure Kellermann, Hoepfel, Voigt, Eichler, Weidner
Partnerschaft


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

John W. Eaton-6
In reply to this post by wkim+
On  5-May-1999, Wonkoo Kim <[hidden email]> wrote:

| However, x = x(:) does not convert a row vector to a column vector
| (Octave 2.0.13 for OS/2).  Though I don't mind this, but the
| original poster would, as this is a different behavior from Matlab.

I thought that the code had been changed so that it always returned a
column vector.  Actually, it was changed so that a single colon index
would always work, but you still need to set do_fortran_indexing to 1
to make it always return a column vector.

Perhaps this could be `fixed' for 2.1.x so that it always does the
Matlab-compatible thing.  Does anyone have a strong opinion either
way?

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

Mike Miller-9
On Wed, 5 May 1999, John W. Eaton wrote:

> On  5-May-1999, Wonkoo Kim <[hidden email]> wrote:
>
> | However, x = x(:) does not convert a row vector to a column vector
> | (Octave 2.0.13 for OS/2).  Though I don't mind this, but the
> | original poster would, as this is a different behavior from Matlab.
>
> <snip>
> Perhaps this could be `fixed' for 2.1.x so that it always does the
> Matlab-compatible thing.  Does anyone have a strong opinion either
> way?

I think the default behavior of Octave functions should always be MATLAB
compatible unless there is something obviously wrong with what MATLAB is
doing.

In this case, the x=x(:) always returns a column vector in MATLAB, but in
Octave it does so almost always with the exception occuring when x is
initially a row vector.  I don't see the need for the exception and I vote
that the default behavior be like that of MATLAB.

Regards,

Mike

--
Michael B. Miller
University of Missouri--Columbia
http://taxa.psyc.missouri.edu/~mbmiller/


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

heberf-2
In reply to this post by Oliver Eichler

I agree that when there is a choice we should go with MATLAB compatibility.  The
reason is that this is what sets Octave apart from similar projects.  Scilab is
a good piece of code as well but not as MATLAB compatible as Octave.  For myself
it doesn't make a lot of difference because I don't even have MATLAB on my
machine.  However when I share code with colleagues it's nice to have something
that will run on MATLAB as well.  

There is a downside to this since MATLAB doesn't do everything the right way so
bug-for-bug compatibility may not be desirable.  


_______________________________________________________________________________
Heber Farnsworth
Assistant Professor of Finance
John M. Olin School of Business
Washington University
Campus Box 1133 phone: (314) 935-4221
One Brookings Drive FAX: (314) 935-6359
St. Louis, MO 63130-4899



Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

John W. Eaton-6
In reply to this post by Oliver Eichler
The following patch (for the 2.1.x sources) should cause Octave to
always return a column vector for A(:).  The change is the same for
the 2.0.x sources.

jwe

Index: Array2-idx.h
===================================================================
RCS file: /home/jwe/src/master/octave/liboctave/Array2-idx.h,v
retrieving revision 1.21
diff -c -r1.21 Array2-idx.h
*** Array2-idx.h 1998/09/24 19:00:14 1.21
--- Array2-idx.h 1999/05/06 00:58:08
***************
*** 84,93 ****
      }
    else if (nr == 1 || nc == 1)
      {
!       int result_is_column_vector = (nc == 1);
!
!       if (liboctave_dfi_flag && idx.is_colon ())
!    result_is_column_vector = 1;
 
        Array<T> tmp = Array<T>::index (idx);
 
--- 84,90 ----
      }
    else if (nr == 1 || nc == 1)
      {
!       int result_is_column_vector = (nc == 1 || idx.is_colon ());
 
        Array<T> tmp = Array<T>::index (idx);
 


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

John Logsdon-4
In reply to this post by John W. Eaton-6
On Wed, 5 May 1999, John W. Eaton wrote:

>
> I thought that the code had been changed so that it always returned a
> column vector.  Actually, it was changed so that a single colon index
> would always work, but you still need to set do_fortran_indexing to 1
> to make it always return a column vector.
>

I thought to get close to Matlab compatability you *had* to have
do_fortran_indexing set to 1 (best in .octaverc)

> Perhaps this could be `fixed' for 2.1.x so that it always does the
> Matlab-compatible thing.  Does anyone have a strong opinion either
> way?
>

It is already, surely.  I see no need as there may be code out there that
uses the opposite sense with do_fortran_indexing=0

> Thanks,
>
> jwe
>

BTW, John mentioned contributions but did not suggest looking at the URL
which pre-prints a form for sending (by s-mail).  See JWE's message of
16th April.

Perhaps this URL could be added as a footer to the list messages, together
with a reminder of how to unsubscribe?  (My contribution is in the post,
John).

John



Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

Ted.Harding
On 06-May-99 John Logsdon wrote:

> On Wed, 5 May 1999, John W. Eaton wrote:
>
> I thought to get close to Matlab compatability you *had* to have
> do_fortran_indexing set to 1 (best in .octaverc)
>
>> Perhaps this could be `fixed' for 2.1.x so that it always does the
>> Matlab-compatible thing.  Does anyone have a strong opinion either
>> way?
>>
>
> It is already, surely.  I see no need as there may be code out there
> that
> uses the opposite sense with do_fortran_indexing=0
>
>> Thanks,
>>
>> jwe

I'm inclined to agree with John Logsdon on this one.

However, I think the following would be really useful.

It has never been really clear what you need to set if you want, for
whatever reason, MatLab compatibility (interoperability with MatLab
users being a compelling reason).

Maybe the whole thing could be wrapped up in an option

"matlab_compatibility = 1"

which overrides everything else that would be ML-incompatible,
while if you set it "= 0" then you can set any of these other options
to be what you like.

And it would be desirable if "= 1" made it really compatible, modulo
non-implemented MatLab functions -- I'm really thinking about things like
the "x(:)" issue (though I deeply appreciate that it can be decidedly
non-trivial to set one package up to be totally compatible with another,
especially since this can, in the long term, involve you in
"feature-tracking" when you may have better things to do). I'm also aware
that there are things you can do in octave which are simply not in
MatLab, but this issue should not be a problem where writing/running code
that should run on either is concerned.

There are enough people with a foot in each camp to make compatibility a
serious issue.

Best wishes, and as always: thanks to John Eaton.
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <[hidden email]>
Date: 06-May-99                                       Time: 09:44:51
------------------------------ XFMail ------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: operation x=x(:)

John W. Eaton-6
On  6-May-1999, (Ted Harding) <[hidden email]> wrote:

| On 06-May-99 John Logsdon wrote:
| > On Wed, 5 May 1999, John W. Eaton wrote:
| >
| > I thought to get close to Matlab compatability you *had* to have
| > do_fortran_indexing set to 1 (best in .octaverc)
| >
| >> Perhaps this could be `fixed' for 2.1.x so that it always does the
| >> Matlab-compatible thing.  Does anyone have a strong opinion either
| >> way?
| >>
| >
| > It is already, surely.  I see no need as there may be code out there
| > that
| > uses the opposite sense with do_fortran_indexing=0
| >
| >> Thanks,
| >>
| >> jwe
|
| I'm inclined to agree with John Logsdon on this one.
|
| However, I think the following would be really useful.
|
| It has never been really clear what you need to set if you want, for
| whatever reason, MatLab compatibility (interoperability with MatLab
| users being a compelling reason).

The manual lists them with the desription of the --traditional
command-line option:

`--traditional'
`--braindead'
     Set initial values for user-preference variables to the following
     values for compatibility with MATLAB.

          PS1                           = ">> "
          PS2                           = ""
          beep_on_error                 = 1
          default_save_format           = "mat-binary"
          define_all_return_values      = 1
          do_fortran_indexing           = 1
          crash_dumps_octave_core       = 0
          empty_list_elements_ok        = 1
          implicit_str_to_num_ok        = 1
          ok_to_lose_imaginary_part     = 1
          page_screen_output            = 0
          prefer_column_vectors         = 0
          print_empty_dimensions        = 0
          treat_neg_dim_as_zero         = 1
          warn_function_name_clash      = 0
          whitespace_in_literal_matrix  = "traditional"

Unfortunately, this list is slightly out of date.  The correct
information is in the function maximum_braindamage, which is defined
in octave.cc.  Recent additions are

  default_eval_print_flag       = 0
  default_global_variable_value = []
  fixed_point_format            = 1
  implicit_num_to_str_ok        = 1
  initialize_global_variables   = 1
  prefer_zero_one_indexing      = 1

(My apologies for letting the documentation slip a bit.)

| Maybe the whole thing could be wrapped up in an option
|
| "matlab_compatibility = 1"

It would be trivial to add a function that simply set the appropriate
variables to the values they would have on --traditional.

| (though I deeply appreciate that it can be decidedly
| non-trivial to set one package up to be totally compatible with another,
| especially since this can, in the long term, involve you in
| "feature-tracking" when you may have better things to do).

Right.  It's a losing battle, especially when many of the new features
tend to be poorly designed.

I never set out to write a `Matlab clone' and have never called Octave
that.  The reason for choosing a mostly compatible syntax was to make
it easier for Matlab users to learn.

jwe