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

 
 

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

Submitter:  None
Submitted:  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 Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
Thu 13 Aug 2020 01:30:32 AM UTC, comment #4: 

The suggestion to change

Rik <rik5>
Group 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>
Group 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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-4448.
    Corresponding source code