"y \= scalar" fails

[Rolf Fabian]

octave-3.0.0.exe:1> version,computer
ans = 3.0.0
i686-pc-msdosmsvc

octave-3.0.0.exe:2> x=[1,2;3,4]; c = 2; A=[3,2;1,5];

octave-3.0.0.exe:3> y=x; y \= c     # FAILS without leading dot
error: operator \: nonconformant arguments (op1 is 2x2, op2 is 1x1)
error: assignment failed, or no method for `matrix \= scalar'
error: evaluating assignment expression near line 3, column 8

octave-3.0.0.exe:3> y=x; y \= A      # matrix RHS : OK without dot
y =
  -5.00000   1.00000
   4.00000   0.50000

octave-3.0.0.exe:4> y=x; y .\= c     # scalar RHS: OK with dot
y =
   2.00000   1.00000
   0.66667   0.50000

[Jaroslav Hajek-2]

this seems 100% correct. y \= c means y = y \ c = inv(y) * c, but
size(y,2) != size(c,1).
Matlab gripes as well here.

On Mon, Mar 3, 2008 at 10:26 AM, Rolf Fabian <Rolf.Fabian@...> wrote:

>
>
>  octave-3.0.0.exe:1> version,computer
>  ans = 3.0.0
>  i686-pc-msdosmsvc
>
>  octave-3.0.0.exe:2> x=[1,2;3,4]; c = 2; A=[3,2;1,5];
>
>  octave-3.0.0.exe:3> y=x; y \= c     # FAILS without leading dot
>  error: operator \: nonconformant arguments (op1 is 2x2, op2 is 1x1)
>  error: assignment failed, or no method for `matrix \= scalar'
>  error: evaluating assignment expression near line 3, column 8
>
>  octave-3.0.0.exe:3> y=x; y \= A      # matrix RHS : OK without dot
>  y =
>   -5.00000   1.00000
>    4.00000   0.50000
>
>  octave-3.0.0.exe:4> y=x; y .\= c     # scalar RHS: OK with dot
>  y =
>    2.00000   1.00000
>    0.66667   0.50000
>
>
>  -----
>  Rolf Fabian
>  <r dot fabian at jacobs-university dot de>
>
>  --
>  View this message in context: http://www.nabble.com/%22y-%5C%3D-scalar%22-fails-tp15799910p15799910.html
>  Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
>  _______________________________________________
>  Bug-octave mailing list
>  Bug-octave@...
>  https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Rolf Fabian]

Jaroslav Hajek-2 wrote:

this seems 100% correct.
y \= c means y = y \ c = inv(y) * c,

Thanks for explaining me, what a backslash
division is supposed to do.

but size(y,2) != size(c,1).

Unfortunately you forgot to line out the
problem which Octave has to multiply a
square matrix by a scalar value. i.e.
evaluating "inv(y) * c" .
Is "inv(y) * c" not anymore identical
to "inv(y) .* c" or did I miss something?

Matlab gripes as well here.

RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

There seem to be many features of ML which
are weird, strange or obscure. They do not
necessarily have to be merged into Octave
without critically reflecting them.

[Ben Abbott]

On Mar 3, 2008, at 7:42 AM, Rolf Fabian wrote:

> Unfortunately you forgot to line out the
> problem which Octave has to multiply a
> square matrix by a scalar value. i.e.
> evaluating "inv(y) * c" .
> Is "inv(y) * c" not anymore identical
> to "inv(y) .* c" or did I miss something?

Rolf, I believe the operations ".*" and "*" are identical to each  
other when one of the inputs is a scalar.

For example, if c = scalar and A = mxn matrix, A*c, A.*c, c*A, c.*A  
each produce the same result.

Ben
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Mon, Mar 3, 2008 at 1:42 PM, Rolf Fabian <Rolf.Fabian@...> wrote:

>
>
>  Jaroslav Hajek-2 wrote:
>  >
>  > this seems 100% correct.
>  > y \= c means y = y \ c = inv(y) * c,
>  >
>
>  Thanks for explaining me, what a backslash
>  division is supposed to do.
>
>

Unfortunately, I didn't. The inv(y)*c thinkg was a mistake; it does
not work that way.
y \= c is indeed equivalent to y = y\c, the rest is not true.
"Supposed to" is the problem here. Supposed by whom?

>
>
>  > but size(y,2) != size(c,1).
>  >
>
>  Unfortunately you forgot to line out the
>  problem which Octave has to multiply a
>  square matrix by a scalar value. i.e.
>  evaluating "inv(y) * c" .
>  Is "inv(y) * c" not anymore identical
>  to "inv(y) .* c" or did I miss something?
>
>

No, as I confessed above, this is true. The problem is that matrix
left division A \ B is not
defined as inv(A) * B (for one thing, A does not have to be square.)

>
>
>  > Matlab gripes as well here.
>  >
>
> > RNDr. Jaroslav Hajek
>  > computing expert
>  > Aeronautical Research and Test Institute (VZLU)
>  > Prague, Czech Republic
>  > url: www.highegg.matfyz.cz
>  >
>
>  There seem to be many features of ML which
>  are weird, strange or obscure. They do not
>  necessarily have to be merged into Octave
>  without critically reflecting them.
>
>
>
>  -----
>  Rolf Fabian
>  <r dot fabian at jacobs-university dot de>
>
>  --
>  View this message in context: http://www.nabble.com/%22y-%5C%3D-scalar%22-fails-tp15799910p15802174.html
>
>
> Sent from the Octave - Bugs mailing list archive at Nabble.com.
>
>  _______________________________________________
>  Bug-octave mailing list
>  Bug-octave@...
>  https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

>
>  There seem to be many features of ML which
>  are weird, strange or obscure. They do not
>  necessarily have to be merged into Octave
>  without critically reflecting them.
>

mldivide and mrdivide simply require the dimensions to match. They can
certainly be extended to the matrix-scalar case.

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Rolf Fabian]

Jaroslav Hajek-2 wrote:

On Mon, Mar 3, 2008 at 1:42 PM, Rolf Fabian <[e-mail]> wrote:
>  Jaroslav Hajek-2 wrote:
>  >
>  > this seems 100% correct.
>  > y \= c means y = y \ c = inv(y) * c,
>  >
>
>  Thanks for explaining me, what a backslash
>  division is supposed to do.

Unfortunately, I didn't. The inv(y)*c thinkg was a mistake; it does
not work that way.
y \= c is indeed equivalent to y = y\c, the rest is not true.
"Supposed to" is the problem here. Supposed by whom?

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Did I write "how a backslash division is supposed to work"
or did I actually specify "what a backslash division is supposed
to do" ? You should better recognize the difference.

The fact, that for an (invertible) square matrix y and scalar c
the command "y \= c" results in a size conflict error looks weird and
obscure to me. Moreover, the fact that MatLab behaves in the same
way does  not all all make this 'feature' less strange and less obscure.
The way how the calculation is actually done does not play
any role concerning that statement.

Again:
In my eyes, having to specify

"y \= c * eye( size (y))"
(for square y and constant c)

instead of "y \= c"

to get something which is 'conceptually identical'
to "y \= c"

is extremely ugly and needs to be improved
by allowing syntax "y \= c" for that special
case.

[Jaroslav Hajek-2]

On Mon, Mar 3, 2008 at 5:05 PM, Rolf Fabian <Rolf.Fabian@...> wrote:

>
>
>  Jaroslav Hajek-2 wrote:
>  >
>  > On Mon, Mar 3, 2008 at 1:42 PM, Rolf Fabian <Rolf.Fabian@...> wrote:
>  >>  Jaroslav Hajek-2 wrote:
>  >>  >
>  >>  > this seems 100% correct.
>  >>  > y \= c means y = y \ c = inv(y) * c,
>  >>  >
>  >>
>  >>  Thanks for explaining me, what a backslash
>  >>  division is supposed to do.
>  >
>  > Unfortunately, I didn't. The inv(y)*c thinkg was a mistake; it does
>  > not work that way.
>  > y \= c is indeed equivalent to y = y\c, the rest is not true.
>  > "Supposed to" is the problem here. Supposed by whom?
>  >
>  > --
>
> > RNDr. Jaroslav Hajek
>  > computing expert
>  > Aeronautical Research and Test Institute (VZLU)
>  > Prague, Czech Republic
>  > url: www.highegg.matfyz.cz
>  >
>
>  Did I write "how a backslash division is supposed to work"
>  or did I actually specify "what a backslash division is supposed
>  to do" ? You should better recognize the difference.
>

Either way, the question is the same. Supposed by whom? You, presumably.

>
>  The fact, that for an (invertible) square matrix y and scalar c
>  the command "y \= c" results in a size conflict error looks weird and
>  obscure to me. Moreover, the fact that MatLab behaves in the same
>  way does  not all all make this 'feature' less strange and less obscure.
>  The way how the calculation is actually done does not play
>  any role concerning that statement.
>
>  Again:
>  In my eyes, having to specify
>
>  "y \= c * eye( size (y))"
>  (for square y and constant c)
>
>  instead of "y \= c"
>
>  to get something which is 'conceptually identical'
>  to "y \= c"
>
>  is extremely ugly and needs to be improved
>  by allowing syntax "y \= c" for that special
>  case.
>
>

OK, no problem. In my eyes, matrix \=  scalar is confusing. Perhaps
just because I've never seen it (because it does not work). Anyway, I
think such an extension would be easy to implement. I'd even volunteer
to do it if more people are interested.
Does anyone else share Rolf's opinion?

regards,
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On  3-Mar-2008, Jaroslav Hajek wrote:

| OK, no problem. In my eyes, matrix \=  scalar is confusing. Perhaps
| just because I've never seen it (because it does not work). Anyway, I
| think such an extension would be easy to implement. I'd even volunteer
| to do it if more people are interested.
| Does anyone else share Rolf's opinion?

If you want M \ s (and presumably s / M) to work, then I think for
consistency with the rest of the Octave internals, we should implement
this by introducing new xleftdiv and xdiv functions that take double
and Complex scalar values as arguments so that things like

  DEFBINOP (ldiv, matrix, scalar)
  {
    CAST_BINOP_ARGS (const octave_matrix&, const octave_scalar&);

    Matrix m1 = v1.matrix_value ();
    Matrix m2 = v2.matrix_value ();
    MatrixType typ = v1.matrix_type ();

    Matrix ret = xleftdiv (m1, m2, typ);

    v1.matrix_type (typ);
    return ret;
  }

can be rewritten as

  DEFBINOP (ldiv, matrix, scalar)
  {
    CAST_BINOP_ARGS (const octave_matrix&, const octave_scalar&);

    Matrix ret = xleftdiv (v1.matrix_value (), v2.scalar_value (),
                           v1.matrix_type ());

    v1.matrix_type (typ);

    return ret;
  }

This leaves the original xleftdiv and xdiv functions alone and only
working for conforming matrix dimensions.  This is consistent with
other internal functions in Octave which do not do special things when
(for example) a Matrix object happens to have only one element.

You'll also need to handle the sparse cases.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On  3-Mar-2008, John W. Eaton wrote:

| On  3-Mar-2008, Jaroslav Hajek wrote:
|
| | OK, no problem. In my eyes, matrix \=  scalar is confusing. Perhaps
| | just because I've never seen it (because it does not work). Anyway, I
| | think such an extension would be easy to implement. I'd even volunteer
| | to do it if more people are interested.
| | Does anyone else share Rolf's opinion?
|
| If you want M \ s (and presumably s / M) to work, then I think for

Another possibility is to fix the documentation and instead of saying
that x = M \ y is conceptually equivalent to x = inv (M) * y, we could
say that it solves the set of equations M * x = y for the unknonwn
vector X.  Stated that way, I don't see any particular justification
for special handling for scalar values of Y.

Comments?

jwe


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Wed, Mar 5, 2008 at 10:45 PM, John W. Eaton <jwe@...> wrote:

> On  3-Mar-2008, John W. Eaton wrote:
>
> | On  3-Mar-2008, Jaroslav Hajek wrote:
> |
> | | OK, no problem. In my eyes, matrix \=  scalar is confusing. Perhaps
> | | just because I've never seen it (because it does not work). Anyway, I
> | | think such an extension would be easy to implement. I'd even volunteer
> | | to do it if more people are interested.
> | | Does anyone else share Rolf's opinion?
> |
> | If you want M \ s (and presumably s / M) to work, then I think for
>
> Another possibility is to fix the documentation and instead of saying
> that x = M \ y is conceptually equivalent to x = inv (M) * y, we could
> say that it solves the set of equations M * x = y for the unknonwn
> vector X.  Stated that way, I don't see any particular justification
> for special handling for scalar values of Y.
>

I agree. One more reason: giving this special meaning to s / M and M \
s could possibly make a user previously exposed to other matrix
languages (Fortran 95, R, Mathematica...) guess incorrectly that /
behaves like element-by-element operation. He'll still be surprised
that M / M or s / NDarray don't work. Anyone dealing with Octave (or
Matlab) should understand the difference between *,/ and .*,./

> Comments?
>
> jwe
>
>
>



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave