bugGNU Octave - Bugs: bug #58830, imprecise error message for...

 
 

bug #58830: imprecise error message for "size(foo,end)"

Submitted by:  None
Submitted on:  Sun 26 Jul 2020 01:50:12 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 14 Aug 2020 06:22:06 PM UTC, comment #13: 

Looks good.  Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Fri 14 Aug 2020 08:15:44 AM UTC, comment #12: 

I think the proposed solution is a good one. For reference, Matlab 2020a also behaves in a similar way. So, if X is undefined, X(1:10) produces an error about an undefined function or variable", but X(1:end) complains about the use of "end".

Fernando <tutissanalio>
Fri 14 Aug 2020 05:10:23 AM UTC, comment #11: 

I meant, pushed on stable, merged with default.

John W. Eaton <jwe>
Project Administrator
Fri 14 Aug 2020 05:09:38 AM UTC, comment #10: 

I pushed the following changeset and merged with stable:

http://hg.savannah.gnu.org/hgweb/octave/rev/0bac488f17fa

John W. Eaton <jwe>
Project Administrator
Thu 13 Aug 2020 09:00:22 PM UTC, comment #9: 

Rik: yeah, I don't see how to do what Mike showed in the other bug report.  If evaluation of the argument list fails, then we can't really proceed to look up the function because we don't really know what the arguments are for dispatching.  The simplest solution seems to be to just throw an "invalid use of 'end' in index expression".  If it occurs within a function, you should get a stack trace to tell you the line where the error happened.  Yes, it makes the error for undefined X different for X(1:end) vs X(1:10), but that seems reasonable to me.

John W. Eaton <jwe>
Project Administrator
Thu 13 Aug 2020 08:48:38 PM UTC, comment #8: 

The error message is

x = isnan (end)
The end operator must be used within an array index expression.

So, it doesn't give any indication of where the error occurred.

Rik <rik5>
Project Administrator
Thu 13 Aug 2020 07:51:34 PM UTC, comment #7: 

I'm looking at this problem now.

I think I had "end" return NaN because I thought it could be detected later.  Maybe there is a better way.

Given and expression like

foo (expr_that_uses_end)

we can look for "foo" in the current stack frame to see whether it is a variable.  If it is, then we can cache that info somewhere so that when we evaluate "expr_that_uses_end", we will be able to look up the dimensions so we will know what value "end" should produce in this context.

If "foo" is not defined as a variable, then it might be a function, but we have to evaluate "expr_that_uses_end" before we can search for the function definition because we need the types of the arguments to do proper dispatching.  So if we encounter "end", it's an error.  I guess the question is just what the best way is to handle the error so that we can display meaningful info.  I have some ideas but will need to experiment a bit more.

John W. Eaton <jwe>
Project Administrator
Thu 13 Aug 2020 07:32:04 PM UTC, comment #6: 

Rik, I see what you mean. Reporting the subscript and the dimensional reasoning is extremely useful behavior when accidentally going out of bounds:

octave:2> mat = rand(3,4)
mat =

   0.6382   0.6235   0.7015   0.8218
   0.1992   0.6884   0.5041   0.9771
   0.7918   0.3789   0.7485   0.4995

octave:3> mat(end)
ans = 0.4995
octave:4> mat(end+1)
error: mat(13): out of bound 12 (dimensions are 3x4)
octave:5> mat(0)
error: mat(0): subscripts must be either integers 1 to (2^63)-1 or logicals
octave:6> mat(-1)
error: mat(-1): subscripts must be either integers 1 to (2^63)-1 or logicals
octave:7> mat(end-13)
error: mat(-1): subscripts must be either integers 1 to (2^63)-1 or logicals
octave:8> mat(nan)
error: mat(nan): subscripts must be either integers 1 to (2^63)-1 or logicals

The occasional quirk is that incorrectly calling a function with end as an argument causes behavior that is very consistent with "end == nan" but can surprise a user who doesn't know that equivalence:

octave:9> size(end)
ans =
   1   1
octave:10> size(nan)
ans =
   1   1
octave:11> isnan(end)
ans =
   1

Though it can be surprising, it is likely easily noticed and fixed.

If it's relevant, could you check Matlab's error message for "isnan(end)" please? Is it a blanket error message or does it give info relevant to the calling location?

Anonymous
Thu 13 Aug 2020 03:23:29 PM UTC, comment #5: 

I agree that reverting the fix for bug #33637 and introducing a call to error() would fix the first bug and this one.  However, we would lose reporting about where the error occurred.  This doesn't seem desirable.  I've added jwe to the CC list for this bug since he resolved the first one.

The current summary of the bug is that when end is used incorrectly, the parser returns NaN.  For an indexing operation, this results in eventually displaying an error about a non-existent variable.  But if it is a function call, then NaN is used as the parameter.  So,

size (1, end)

is equivalent to

size (1, NaN)

and that throws the error

error: size: requested dimension DIM (= -9223372036854775808) out of range

If we had a way of knowing where we were in parsing (line number and column number) within the method end() then we could just issue the call to error() with that information.

Rik <rik5>
Project Administrator
Thu 13 Aug 2020 01:30:32 AM UTC, comment #4: 

The suggestion to change

Rik <rik5>
Project Administrator
Sun 09 Aug 2020 01:21:45 PM UTC, comment #3: 

How about changing this:

  if (! indexed_object)
    return ovl (octave_NaN);

to this:

  if (! indexed_object)
    error ("Keyword 'end' used incorrectly. Cannot use 'end' as a function argument or to index non-existent variables.");

The new error message is verbose but helpful in localizing the problems identified in both bug #58830 and bug #33637.

Anonymous
Sat 08 Aug 2020 07:09:20 PM UTC, comment #2: 

The problem is a little more serious. When "end" is used as an argument to a function, it is simply replaced by NaN, instead of throwing an error. You get the following behaviour both in stable and default branches:

>> disp(end)
NaN

The problem was introduced in changeset 27100:b453b586da16, more than a year ago, to correct bug #33637.

I could try and see if I can fix it.

Fernando <tutissanalio>
Mon 27 Jul 2020 03:31:05 AM UTC, comment #1: 

For reference, Matlab also throws an error.  It just happens to be a bit more precise about what is going on.  It says "The end operator must be used within an array index expression".

Rik <rik5>
Project Administrator
Sun 26 Jul 2020 01:50:12 PM UTC, original submission:  

I made a typo and accidentally typed size(foo,end) instead of size(foo)(end). I got an odd error with a weird value. This doesn't affect anything but is being reported in case it's a symptom of something deeper. If it's safe to ignore, please disregard it.

octave:60> size(arr)
ans =
     2     2     2     2   168

octave:61> size(arr)(end)
ans = 168
octave:62> size(arr,end)
error: size: requested dimension DIM (= -9223372036854775808) out of range

This is on GNU Octave Version: 7.0.0 (hg id: a61b651914d6) on 64-bit Linux.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by tutissanalio (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-14 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2020-08-14 jwe StatusConfirmed => Ready For Test
    2020-08-13 rik5 Carbon-Copy- => Added jwe
    2020-08-13 rik5 Dependencies- => Depends on bugs #33637
    2020-07-27 rik5 StatusNone => Confirmed
        SummaryOdd error on size(foo,end) => imprecise error message for "size(foo,end)"

    Back to the top


    Powered by Savane 3.5