[Top][All Lists]

[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
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
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

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!

Ted.                                    (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]