[Octave-bug-tracker] [bug #45957] Error "A(I) = X: X must have the same size as I" not very informative

[Lachlan Andrew]

Follow-up Comment #4, bug #45957 (project octave):

They're both good suggestions, John.

I made a start on specifying which dimension caused the problem, but the issue
with invalid indices is flagged several levels deeper than out-of-range
indices.  I got lost in the tangle of passing location references through
subroutine calls, and so decided to submit the cleaner patch first.

The idea of exceptions is great.  One issue is that the piece of code that
knows which index is in doesn't know which variable it is -- because it could
be (A+B)(1,-1).  The parenthesis-handling code would probably have to
partially format the error message, and then re-throw to the variable-handling
code.  Who would then catch the exception for (A+B)(1,-1)?  I suppose that
could go way up in the code that evaluates a generic expression.

Ideally, I'd like the error to be something like
error:  Accessing varname(.,index).
for example


error: accessing A(-1)
error: accessing B(1e50,.)
error: accessing coord(.,1.3,.,.)


For out-of-range errors, I'd like

error: accessing varname(x,y,z) but varname has size AxBxC.

If we get

  x = [1 2 3]
  x(2,1)
==>
  error: index to dimension 1 is out of bounds; value 2 out of bound 1

we don't know if  x  is a singleton, or we've just swapped the row and column
indices.  (I deal a lot with lists rather than true vectors, so I get
sloppy.)

The cast to double is problematic for indices greater than 2^52, which would
only occur in the most extreme sparse matrices.  Are there other problems?  I
was just trying to avoid having two nearly-identical sections of code to
maintain.  I suppose we could convert the index to a string and have the
octave_idx_type and double calls both pass a string to a common function.


A question about etiquette: I'm preparing a patch to make distribution
functions (like unifcdf) give more explicit errors.  Should I add that to this
bug, or open a new one?

Thanks!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45957>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/