( 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. (

[hidden email])