comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » New behavior of n_elements?
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
New behavior of n_elements? [message #94576] Fri, 14 July 2017 12:43 Go to next message
laura.hike is currently offline  laura.hike
Messages: 87
Registered: September 2013
Member
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
Re: New behavior of n_elements? [message #94579 is a reply to message #94576] Fri, 14 July 2017 14:13 Go to previous message
wlandsman is currently offline  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
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Compilation Error: Procedure header must appear first and only once
Next Topic: Creating executable sav file

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:07:00 PDT 2025

Total time taken to generate the page: 0.00359 seconds