Re: HELP a newbie - Weird problem

[Ted Harding]

( Re Message From: Billy Chow )
Hi Billy,

> I worte to the list a few days ago about the problem I have with the
> variable `whitespace_in_literal_matrix' and so far received no reply.

Sorry about that, on behal of all of us. Wasn't intended!

> I really want to know why this happens, is it due to a problem in my
> setup or a bug in octave.  Here is a summary:
> 
> System:
> 
>    -8Mb 486DX-33
>    -Linux 1.2.8 (slackware 2.3)
>    -Octave 1.1.1
> 
> Symptom:
> 
>    -Start octave clean (no .octaverc), and type 
> 
>           Octave:1>conv(1,1)
>           Ans = 1
>           Octave:2>whitespace_in_literal_matrix = 'traditional';
>           Octave:3>conv(1,1)
>           Ans = 1
> 
>     Good! no problem but if we ...
>    -Start octave clean, and type
> 
>           Octave:1>whitespace_in_literal_matrix = 'traditional';
>           Octave:2>conv(1,1)
>           Parse error in line 59 of conv.m
>               .........
>               .........
>           
> The same error if I put the line ``whitespace_in_literal_matrix =
> 'traditional''' in a .octaverc.  This line is suggested in the FAQ for
> better Matlab combatibility.  I don't believe I am the first one to
> following suggestions in the FAQ and put the line in a .octaverc.
> Somebody must have come across this problem and might even have a
> solution.  Please some kind soul enlighten me.  Or just try the above
> out and tell me if you have the same outcome.

Well I did. I don't have an ".octavrc" but I do use a global
/usr/local/lib/octave/1.1.1/m/startup/octaverc;
however, this doesn't normally do anything about whitespace_in_literal_matrix.

Not that it matters: what counts is the following.

If you start up octave, and immediately execute "conv(1,1)", then PROVIDED
the variable whitespace_in_literal_matrix is a null string the result will
be correct. You can then set whitespace_in_literal_matrix='traditional'
and re-execute "conv(1,1)" and it will still work. This is because the
m-file for "conv" has already been read in, parsed, understood, and
"compiled" into octave's internal format.

However, if you first execute whitespace_in_literal_matrix='traditional'
and THEN do "conv(1,1)" you will get

      parse error near line 59 of file conv.m:

      >>>       x = [b, zeros (1, ly - lb)];
                                 ^
no doubt because it tries to evaluate "[b, zeros (1, ly - lb)]" as a
matrix with columns  "b"  and  "zeros" and "(1, ly - lb)" (or somthing to
that effect) because the "traditional" column separator in a Matlab
literal matrix is the space.  (Can experts confirm that this reading is
[approx] correct?).

The result is that this line in "conv.m" is parsed to have incorrect
syntax, so the "conv" function never gets into octave.

However, if you edit
/usr/local/lib/octave/1.1.1/m/polynomial/conv.m
to change relevant lines to 
x = [b,zeros(1,ly - lb)];
x = [a,zeros(1,ly - la)];
(I have actually changed ", " into "," thoughout), then it should work OK.

As to whether it is a bug in octave, you might consider that it was since
one might expect the parser to recognise that "zeros (" was the leadin to
a function expression before parsing the contents of [ ... ] into columns
using spaces and/or commas, but if you think about it it is not so
obvious, because "zeros" is a valid expression (at the parser level), i.e.
a variable name (because we have not yet got to the stage of seeing whther
"zeros" has been created -- and in any case "zeros" gives "ans = 0" so it's
valid anyway). Therefore [b, zeros (<expr>)] gets parsed as

    Matrix with 3 columns "b", "zeros", (<expr>)"

Next, if <expr> is a valid expression, so is (<expr>). The problem would
seem to arise from the parser asserting that "(1, ly - lb)" is not a valid
expression (the parser having already decided that "zeros" is valid). The
only get-round would seem to be to write a back-tracking parser which
tried to apply rules like

    If     (<expr>)   is not a valid expression,
           and   (<expr>)   is preceded by a name <name>
    Then   try to parse   <name> (<expr>)   as a function call
           <function_name>(<arg_list>)

This would be a pain: and since the problem really arises from trying to
satisfy two different conventions (white-space where you like as in
octave, versus white-space only when it can't cause trouble as in
Matlab) at the same time, the real solution is for people to write their
m-functions accordingly.

Any comment from the people who really know what goes on? The above is
off the top of my head!

Cheers,
Ted.                                    (address@hidden)