HELP a newbie - Weird problem

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

HELP a newbie - Weird problem

Billy Chow
Dear list members,

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

Thanks

/Billy







Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

Darrel Hankerson-2
             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

I'm not an octave expert, but I suspect this is due to the way
octave "compiles" source files. In your second example, the
variable is set before the first call to conv.

The offending lines are of the form

    x = [b, zeros (1, ly - lb)];

The problem is that octave wants to insert a comma between
"zeros" and "(". I'm not certain if this is an octave bug or a
bug in m/polynomial/conv.m.

--Darrel Hankerson [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

Ted.Harding
In reply to this post by Billy Chow
( 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])

Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

Ian Searle-2
In reply to this post by Billy Chow
> Date: Fri, 11 Aug 95 16:57:16 BST
> From: [hidden email] (Billy Chow)
> Sender: [hidden email]
> Content-Type: text
> Content-Length: 1311
>
> Dear list members,
>
> 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.
> 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.
>
> Thanks
>
> /Billy
>

I tried the above on a Sparc-10/51 (Solaris 2.4), using the octave
binary distribution. I get the exact same results as you describe
above.

        octave:1> whitespace_in_literal_matrix = 'traditional';
        octave:2> conv(1,1)
        parse error near line 59 of file conv.m:
         
        >>>       x = [b, zeros (1, ly - lb)];
                                   ^
         
        error: `conv' undefined near line 2 column 1
        error: evaluating index expression near line 2, column 1

-Ian

Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

Billy Chow
In reply to this post by Darrel Hankerson-2
>>>>> "Darrel" == Darrel Hankerson <[hidden email]> writes:


Darrel> The problem is that octave wants to insert a comma between
Darrel> "zeros" and "(". I'm not certain if this is an octave bug or a
Darrel> bug in m/polynomial/conv.m.

thanks for your reply.  At least I know it's not my systems's fault.
This is such an obvious problem I hope john will fix it in the next
octave release.

/Billy

Darrel> --Darrel Hankerson [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

Ian Searle-2
In reply to this post by Ted.Harding


> 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?).
>

Yes this is almost correct... Matlab 4.2 does:

        >> x = [b, zeros (1, ly - lb)];
        ??? x = [b, zeros (1,
                            |
        A closing right parenthesis is missing.
        Check for a missing ")" or a missing operator.

[other stuff sniped]

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

I believe that the parse error is due to the comma, or the early ). It
looks like the expression x = [b, zeros (1, ly - lb)]; is parsed as

        x = [ b        zeros       (1,        ly - lb) ]

Thus Matlab and Octave are complaining about the (1 not being
completed properly. It is possible that a back-tracking parser is not
necessary, proper precedence, might do the trick. On the other hand it
might be that there are just too many ambiguities in this expression
for sensible parsing to occur. I would have to actually try writing a
parser for this to be sure (and I am not about to do that!).

Can you say "bad language design" :-) Machine languages with
ambiguities are acceptable, but when the ambiguities cause confusion
for humans, there is a design problem that cannot be fixed with a
better parser.

-Ian

Reply | Threaded
Open this post in threaded view
|

Re: HELP a newbie - Weird problem

John W. Eaton-6
In reply to this post by Ted.Harding
Ted Harding <[hidden email]> wrote about problems with
whitespace_in_literal_matrix:

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

Right.  Some of the preference variables only matter when Octave is
`compiling' input into its internal form.

: 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?).

Yes.  Octave is inserting a comma between `zeros' and the following
`('.  Then the remaining input doesn't make sense.

Rather than go to all the trouble to `fix' the parser to attempt to
read the programmer's mind, it will be much easier (though probably
not trivial) to fix the functions so that they will work with any
combination of the preference variables.  (I hope I have not done
something stupid that makes this impossible! :-)

To make things work correctly no matter what the value of
whitespace_in_literal_matrix, I believe it is sufficient to (1) always
use `,' and `;' to separate elements and rows and (2) omit spaces
between variable names and '(' when it is used for indexing.  I plan
to do at least this for the next release.  Instead of (2), you can
use a temporary variable to move the expression outside the literal
matrix,

  tmp = zeros (1, ly - lb);
  x = [b, tmp];

or you can put the expression inside parentheses,

  x = [b, (zeros (1, ly - lb))];

This works because Octave turns off the auto-insertion of commas
inside the parentheses.

Another possibility that has been mentioned is to allow some way of
setting the compile-time preference variables on a per-function basis.
I haven't given this enough thought yet to see exactly how to make it
work (either efficiently or at all or without being too confusing)...

As Ian Searle noted, `Can you say "bad language design" :-)'.

jwe