| Re: pointers in IDL [message #8800] |
Tue, 29 April 1997 00:00 |
Thomas A. McGlynn
Messages: 23
Registered: March 1996
|
Junior Member |
|
|
David Fanning wrote:
>
> Christian Oehreneder <co@ipf.tuwien.ac.at> writes:
>
>> My application uses a not a priori known number of images with different
>> sizes, which I want to access easily and flexible, preferrably by
>> writing img_i = img(i) or something similar. Because of the different
>> sizes of the images this is not easily done in IDL.
>> In common programming lanuages it would be natural to have an array of
>> pointers to each of the images.
>> So far I have not found a possibilty to do this in IDL. Handles are nice
>> but they do not allow to have two pointers on the same data. The effect
>> is that once you take the value of a handle (without copying it of
>> course !!) the handle itself contains an undefined value. It is not
>> possible to have a list of images and pass them to some manipulation
>> routines by pointer, e.g. multiplying all images by a factor of 2. Of
>> course it is possible to take the value form the handle, multiply it and
>> set it as value of the handle, but that's rather cumbersome.
>>
>> Has anyone an idea how to work arround this??
>
> I think there is no good way to work around the cumbersome
> method of handles except to upgrade to IDL 5.0 when it comes
> out and take advantage of the new POINTER data type. I'm sure
> it was added to the IDL language for exactly this reason.
>
> Cheers!
>
> David
>
> ----------------------------------------------------------
One way to deal with this if the number of images isn't large
and you don't want to discard or rearrange them can be to use structures to
act as containers for your images.
If you know what the images are then you can just define the structure naturally.
If you need to build it incrementally then you can do something like:
mystruct =
create_struct(mystruct,'e'+string(n_tags(old_struct)),new_im age)
[this particular constructions makes it difficult for you to use
the tagnames, but I'm assuming that's not an issue.]
You have to handle the first one specially of course.
Now you can pass the structure to subroutines and do whatever you want.
To access a given image just:
image_i_want = my_struct.(index)
which seems to be close to what you want. This may only get
you back to IDL 4.0 though, I'm not sure if create_struct works this way
(or at all) much earlier.
Tom McGlynn
|
|
|
|
| Re: pointers in IDL [message #8805 is a reply to message #8800] |
Mon, 28 April 1997 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Christian Oehreneder <co@ipf.tuwien.ac.at> writes:
> My application uses a not a priori known number of images with different
> sizes, which I want to access easily and flexible, preferrably by
> writing img_i = img(i) or something similar. Because of the different
> sizes of the images this is not easily done in IDL.
> In common programming lanuages it would be natural to have an array of
> pointers to each of the images.
> So far I have not found a possibilty to do this in IDL. Handles are nice
> but they do not allow to have two pointers on the same data. The effect
> is that once you take the value of a handle (without copying it of
> course !!) the handle itself contains an undefined value. It is not
> possible to have a list of images and pass them to some manipulation
> routines by pointer, e.g. multiplying all images by a factor of 2. Of
> course it is possible to take the value form the handle, multiply it and
> set it as value of the handle, but that's rather cumbersome.
>
> Has anyone an idea how to work arround this??
I think there is no good way to work around the cumbersome
method of handles except to upgrade to IDL 5.0 when it comes
out and take advantage of the new POINTER data type. I'm sure
it was added to the IDL language for exactly this reason.
Cheers!
David
----------------------------------------------------------
David Fanning, Ph.D.
Fanning Software Consulting
Customizable IDL Programming Courses
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
|
|
|
|
| Re: pointers in IDL [message #8808 is a reply to message #8805] |
Mon, 28 April 1997 00:00 |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
> My application uses a not a priori known number of images with different
> sizes, which I want to access easily and flexible, preferrably by
> writing img_i = img(i) or something similar. Because of the different
> sizes of the images this is not easily done in IDL.
> In common programming lanuages it would be natural to have an array of
> pointers to each of the images.
> So far I have not found a possibilty to do this in IDL. Handles are nice
> but they do not allow to have two pointers on the same data.
I don't think that is true. Consider the following code:
IDL> a = findgen(100,100)
IDL> ap = handle_create()
IDL> handle_value, ap, a, /set
IDL> ap1 = ap
IDL> handle_value, ap1, t1
IDL> help, t1
T1 FLOAT = Array(100, 100)
IDL> ap2 = ap
IDL> handle_value, ap2, t2
IDL> help, t2
T2 FLOAT = Array(100, 100)
In the above example ap, ap1 and ap2 are all "pointers" to the array a.
> It is not
> possible to have a list of images and pass them to some manipulation
> routines by pointer, e.g. multiplying all images by a factor of 2. Of
> course it is possible to take the value form the handle, multiply it and
> set it as value of the handle, but that's rather cumbersome.
You are right here, if you use NOCOPY then you have to put the value back when
you are done with it, but it is really not that cumbersome.
____________________________________________________________
Mark Rivers (773) 702-2279 (office)
CARS (773) 702-9951 (secretary)
Univ. of Chicago (773) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars.uchicago.edu (e-mail)
or:
Argonne National Laboratory (630) 252-0422 (office)
Building 434A (630) 252-0405 (lab)
9700 South Cass Avenue (630) 252-1713 (beamline)
Argonne, IL 60439 (630) 252-0443 (FAX)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
