| Re: New behavior of n_elements? [message #94579 is a reply to message #94576] |
Fri, 14 July 2017 14:13  |
wlandsman
Messages: 743
Registered: June 2000
|
Senior Member |
|
|
I suspect that whether the index is LONG or INT is irrelevant, and the problem is that your DATES array doesn't have 1440 elements
IDL> dates = fltarr(1439)
IDL> print,dates[1439]
% Attempt to subscript DATES with <INT ( 1439)> is out of range.
On Friday, July 14, 2017 at 3:43:37 PM UTC-4, laura...@gmail.com wrote:
> Hi,
>
> I have been using n_elements forever to get the number of elements in an array, which is then used to index a loop. Today, I find the values returned are LONGs instead of plain INTs. I don't care, but when I use them as array indices, they are rejected:
>
> % Attempt to subscript DATES with <LONG ( 1439)> is out of range.
>
> If I change the value to a regular INT there's no problem. Has anyone seen this behavior? My first thoughts were that the value came back as a LONG if it was too big for an INT, but 1440 isn't. My next thought was that maybe it was because the array contained DOUBLEs, so I converted them to FLOATs, but still got a LONG back. I have never seen this behavior before. The documentation for n_elements only says that it
>
> Returns the number of elements.
>
> with no specification of the type of the returned value.
>
> I'm baffled. I don't see any reason you can't use a LONG as an array element number anyway.
>
> Thanks,
>
> Laura
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
