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

*Subject*: Re: N_ELEMENTS and WHERE: Scalar or Array ?*From*: steinhh(at)ulrik.uio.no (Stein Vidar Hagfors Haugan)*Date*: 2 Feb 1999 10:18:18 GMT*In-reply-to*: wmc@bas.ac.uk's message of 1 Feb 1999 16:29:31 GMT*Newsgroups*: comp.lang.idl-pvwave*Organization*: University of Oslo, Norway*References*: <78s23o$525$1@nnrp1.dejanews.com> <36b57934.0@news.nwl.ac.uk><793vuv$euv$1@readme.uio.no> <36b5d66b.0@news.nwl.ac.uk>*Xref*: news.doit.wisc.edu comp.lang.idl-pvwave:13514

In article <36b5d66b.0@news.nwl.ac.uk> wmc@bas.ac.uk writes: [..] > I'm not sure this is so: indexing by nulls ("where" in the example > above would return "null", not -1) can be distinguished from out- > of-range. The problem is the "null" - it ought to be something other than an integer/long/long64. Ok, so maybe -2LL^63 would do... and of course you'd need to keep compatible, so you need WHERE(..,/null) > But even so: I've always felt that allowing > indexing by out of bounds indices is more a bug that a feature. Why > is it possible? Can you think of an example where it is useful, or > necessary? Uh - no, *I* don't think it's a good thing. RSI does (did?) :-) > If this is necessary for legacy reasons, it might be possible to make > () and [] behave differently in this case? Possibly a missed > opportunity when [] came in! How'bout {} ? :-) I'm not *just* kidding. [] work as both array constructors and indexing brackets, so {} could work as both structure constructors and indexing brackets.. [..] >> array[NaN] = 5 ; Would be allowed, but does nothing > >This could well be possible as an easy-to-do work-around. In that >case, where would have to return NaN not -1. (Yes - though with a WHERE(..,/nan) switch) >The other possibility (which would only work for this special case, >but its quite a common special case) is that -1 would count as a >"special" value & assigning to array[-1] would, as a special case, >just do nothing rather than producing an error message. > >Incidentally, I've just realised how dangerous the out-of-bounds stuff >is: > > array([where(array eq false)])='stoat' > >assigns to the first element... And you can *bet* some program(mer)s out there are counting on exactly this as a *feature*! Sorry to say so, but...that's why you'd have to introduce a keyword switch in WHERE. Regards, Stein Vidar

**Follow-Ups**:**Re: N_ELEMENTS and WHERE: Scalar or Array ?***From:*Jack Saba

**Re: N_ELEMENTS and WHERE: Scalar or Array ?***From:*wmc

**References**:**Re: N_ELEMENTS and WHERE: Scalar or Array ?***From:*wmc

**Re: N_ELEMENTS and WHERE: Scalar or Array ?***From:*Stein Vidar Hagfors Haugan

**Re: N_ELEMENTS and WHERE: Scalar or Array ?***From:*wmc

- Prev by Date:
**Re: N_ELEMENTS and WHERE: Scalar or Array ?** - Next by Date:
**Re: N_ELEMENTS and WHERE: Scalar or Array ?** - Prev by thread:
**Re: N_ELEMENTS and WHERE: Scalar or Array ?** - Next by thread:
**Re: N_ELEMENTS and WHERE: Scalar or Array ?** - Index(es):