comp.lang.idl-pvwave archive: archive » New behavior of n

Home » Public Forums » archive » New behavior of n_elements?

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

New behavior of n_elements? [message #94576]

Fri, 14 July 2017 12:43

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

Report message to a moderator

[Message index]

		New behavior of n_elements? By: laura.hike on Fri, 14 July 2017 12:43
		Re: New behavior of n_elements? By: wlandsman on Fri, 14 July 2017 14:13

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) ] [

] [

]

Current Time: Wed Oct 08 13:32:24 PDT 2025

Total time taken to generate the page: 0.00432 seconds