bugGNU Octave - Bugs: bug #34852, incorrect column number on error...

 
 

bug #34852: incorrect column number on error messages

Submitter:  None
Submitted:  Thu 17 Nov 2011 08:21:19 PM UTC
   
 
Category:  Interpreter Severity:  2 - Minor
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  delinquentme Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 27 Jan 2019 06:00:33 AM UTC, comment #10: 

This bug was fixed quite a while ago.  Closing report.

Rik <rik5>
Group administrator
Wed 01 Aug 2018 07:49:52 PM UTC, comment #9: 

All good now with the list of operators in the Octave manual.

Rik <rik5>
Group administrator
Wed 01 Aug 2018 07:33:45 PM UTC, comment #8: 
John W. Eaton <jwe>
Group administrator
Wed 01 Aug 2018 06:59:39 PM UTC, comment #7: 

Hey, that's an improvement.  For the first case the column is reported as 31 as it should be.  I still get a difference when the transpose operator is used, but maybe because that also looks like a quote character and there is another place in the code to accomadate that.  If I eliminate the transpose then the column is correct again.


octave:1> a = [1 2] .* [3 4]; b = sind (z)
error: 'z' undefined near line 1 column 31
octave:1> a = [1 2] * [3 4]'; b = sind (z)
error: 'z' undefined near line 1 column 30
octave:1> a = [1 2] * [3;4] ; b = sind (z)
error: 'z' undefined near line 1 column 31



Rik <rik5>
Group administrator
Wed 01 Aug 2018 02:53:08 AM UTC, comment #6: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/ca38400776bc

I don't know that it fixes everything, but it seems to improve the accuracy of the column numbers in the examples shown in comment #5.

With the new evaluator, it might be fairly easy now to generate better column numbers for stack traces as well, but that's a larger project.

John W. Eaton <jwe>
Group administrator
Wed 01 Aug 2018 12:02:25 AM UTC, comment #5: 

Marking as low priority.  It seems better to print the column number because often it will be correct and help localize debugging.  Occasionally, as in this instance, it can be off.

Another thing that could be improved, however, is getting the column numbers to add when there is more than one statement on a line.  For example,


clear all
sind z)
error: 'z' undefined near line 1 column 7


That's correct as 'z' appears in column 7.  Now,


a = 12345; sind (z)
error: 'z' undefined near line 1 column 18


which is also correct.  But as soon as you throw in operators things get off.  In the following, z is at column 31 always but the the column is off in different ways.


octave:5> a = [1 2] .* [3 4]; b = sind (z)
error: 'z' undefined near line 1 column 29
octave:5> a = 12345; sind (z)
error: 'z' undefined near line 1 column 18
octave:5> a = [1 2] * [3 4]'; b = sind (z)
error: 'z' undefined near line 1 column 28



Rik <rik5>
Group administrator
Sat 19 Nov 2016 07:32:42 PM UTC, comment #4: 

This issue is still present in Octave 4.2.0.

Here is the code of the original submission in runable form:


1;
function [theta, J_history] = gradientDescent(X, y, theta, alpha, num_iters)

  m = length(y); % number of training examples
  J_history = zeros(num_iters, 1);

  for iter = 1:num_iters

    theta = theta - alpha/m * sum ( (((X*theta) - y) )*X )
    J_history(iter) = computeCost(X, y, theta);

  endfor

endfunction

X = 1:100;
y = 3.3 ;
theta = pi/2;
alpha = 0.5;
num_iters = 10;

gradientDescent(X, y, theta, alpha, num_iters)


The resulting error message is

error: gradientDescent: operator *: nonconformant arguments (op1 is 1x100, op2 is 1x100)
error: called from
    gradientDescent at line 9 column 11
    testscript at line 22 column 1


If I understand jwe's comment #2 correct, then it would be better if Octave did not mention any column number at all in this error message, since this column number is not adding any useful information anyways.

My personal opinion: There might as well be cases where the given column number makes debugging easier than without this column number. Just imagine code that has several commands on a single text line, like this


a = [1 2] .* [3 4]; b = [5 6] * [7 8]



Hartmut <hardy>
Sat 27 Dec 2014 05:22:04 PM UTC, comment #3: 

Added bug #43249 as a related bug.  In that case, the reported line number from an error is incorrect rather than the reported column number.

Rik <rik5>
Group administrator
Thu 17 Nov 2011 08:40:00 PM UTC, comment #2: 

It's difficult to see here because the web interface eats whitespace (use verbatim ... verbatim tags here next time to enclose code), but the problem is that the error line is pointing to the assignment operator instead of the multiplication operator.

A relevant discussion from #octave follows:



<jwe> We currently don't save teh information about the locations of
individual operators when we are evaluating them.

<jwe> So the matrix multiply function can't print it.

<jwe> And the code that generates the backtrace just looks at the call
stack, which has info only about the locations of the statements.

<jwe> For the line with teh assignment, the location is the location
of the = operator.

<jwe> We should probably just drop the column number from the error
message so it is not misleading.


Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 17 Nov 2011 08:36:46 PM UTC, comment #1: 

It's difficult to see here because the web interface eats whitespace (use ++verbatim++ ... --verbatim-- tags here next time to enclose code), but the problem is that the error line is pointing to the assignment operator instead of the multiplication operator.

A relevant discussion from #octave follows:



<jwe> We currently don't save teh information about the locations of
individual operators when we are evaluating them.

<jwe> So the matrix multiply function can't print it.

<jwe> And the code that generates the backtrace just looks at the call
stack, which has info only about the locations of the statements.

<jwe> For the line with teh assignment, the location is the location
of the = operator.

<jwe> We should probably just drop the column number from the error
message so it is not misleading.


Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 17 Nov 2011 08:21:19 PM UTC, original submission:  

function [theta, J_history] = gradientDescent(X, y, theta, alpha, num_iters)

  m = length(y); % number of training examples
  J_history = zeros(num_iters, 1);

  for iter = 1:num_iters


    theta = theta - alpha/m * sum (  (((X*theta) - y) )*X  )
 
    J_history(iter) = computeCost(X, y, theta);

  end

end




......................

above code nets this error ( with an incorrect column number )

......................

error: operator *: nonconformant arguments (op1 is 97x1, op2 is 97x2)
error: evaluating argument list element number 1
error: evaluating argument list element number 1
error: called from:
error:   /home/thrive/Desktop/studies/machine_learning/ex1/mlclass-ex1/gradientDescent.m at line 9, column 11

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-18 mtmiller Carbon-CopyRemoved 80942 -
    2019-01-27 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-08-01 rik5 Priority5 - Normal 3 - Low
    2014-12-27 rik5 Dependencies- bugs #43249 is dependent
    2014-01-19 mtmiller CategoryNone Interpreter
        Item GroupNone Incorrect Result
        Release3.2.3 dev
        Operating SystemGNU/Linux Any
    2011-11-17 jordigh Severity3 - Normal 2 - Minor
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code