octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: purpose of 10486:4e64fbbd5c58


From: Jaroslav Hajek
Subject: Re: purpose of 10486:4e64fbbd5c58
Date: Sat, 8 May 2010 08:36:09 +0200

On Fri, May 7, 2010 at 11:36 PM, John W. Eaton <address@hidden> wrote:
> I thought I sent the following message yesterday, but found it in an
> Emacs buffer, apparently unsent.
>
>
>  On  6-May-2010, Jaroslav Hajek wrote:
>
>  | Now I'm getting this:
>  |
>  | octave:1> (1:10)(1.1:10.1)
>  | error: rounding non-integer range used as index to nearest integer
>  |
>  | This error message is really confusing.
>
>  OK, I agree.  I've changed it as you suggested.
>
>  | Further, the following no longer works:
>  |
>  | a = rand (1, 10);
>  | idx = 1.1:10.1;
>  |
>  | try
>  |   b = a(idx);
>  | catch
>  |   [err, id] = lasterr ();
>  |   if (any (strcmp (id, {"Octave:invalid-index", 
> "Octave:index-out-of-bounds"})))
>  |     disp ("indexing error occured");
>  |   else
>  |     rethrow (lasterror);
>  |   endif
>  | end_try_catch
>
>  What is special about these two error IDs that they are the only two
>  which can indicate an indexing error?
>
>  | I think my original solution was better in that it left the normal
>  | behavior intact. If you really insist on the warning ID solution, I
>  | think the message should be just "non-integer range used as index".
>  |
>  | I propose to revert 10605:1834132fb50b and apply the patch I sent
>  | earlier (after completing it).
>
>  What was left to do to complete it?
>

Make it on only in maximum braindamage mode, I think. Though I don't
insist on that; it's OK with me if it's on by default.
And of course add ChangeLog entries.


>  The reason I chose the warning ID solution was that I thought it would
>  have the same effect but would avoid introducing a new internal
>  variable.
>
>  jwe
>
>
> Also, you mentioned the performance of isindex.  Is the isindex
> function often used in places where performance is critical?
>
> In any case, now I've added the new internal variable, so it should be
> fast again.
>
> jwe
>

OK, thanks. Actually I had the patch almost ready, I didn't mean to
request you to do it. But thanks anyway.
I don't think that the performance impact to isindex was critical, I
just wanted to point out that it is there.

I can normally appreciate the value of Matlab compatibility, but I
think I've shown earlier that the new behavior is significantly
different from Matlab, so it seems to me that the benefit in terms of
compatibility is essentially zero. Incidentally, is this still allowed
in the newest Matlab?
So, as I understand it, the entire change was for the purposes of the
person you support. And you wanted it to be done despite my
(unfortunately nobody else participated in the discussion) opposition,
because the support is a paid one. OK, I see the reason, it's great
such people exist. But what I absolutely don't understand is why you
tried to somehow make this change more integrated in Octave, i.e. why
you didn't accept the pseudo-variable solution. When we make a change
like this, that is not actually Matlab compatible and thus in fact has
no actual positives besides allowing a certain person to run certain
buggy programs, I suppose the most logical approach is to create just
an on/off switch for it. You argued that both solutions were equally
good, I tried to point out that they aren't. Regarding the error IDs,
that was just an initial small step towards a more consistent approach
to Octave's error handling. Matlab tries to use IDs consistently, in
Octave we generally don't care much. The programming approach in both
Matlab and Octave generally seems to be "check data first", so maybe
it doesn't matter that much, but it certainly can help to have common
IDs for equivalent kinds of errors in some situations.
Finally, I bet Matlab will stop supporting this inconsistency at one
point (it's not documented) and I hope Octave gets rid of it
eventually, too. In that case a less intrusive change will be easier
to back out.

I hope the person you support doesn't have more buggy codes like this
to run on Octave :)


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]