[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HELP a newbie - Weird problem
From: |
Ted Harding |
Subject: |
Re: HELP a newbie - Weird problem |
Date: |
Fri, 11 Aug 1995 19:04:49 +0200 (BST) |
( 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)