Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Folks, I realize you don't much like to play games (I'm thinking back to the "Yo mama's so ..." thread), but you have no idea how hard it is to come up with new topics for my IDL Tips page every week. (Especially so because I try to understand what I write and make available, which pretty much rules out 4/5 of what I read on this newsgroup.) Anyway, I was sitting here wondering why we don't have any beer in the house again, and it occurred to me that I should have a page listing the 10 or 15 most common IDL programming errors with their solutions. But I can only think of three. Here are the three errors I most commonly see in IDL programs. 1. IDL programs are named incorrectly. The last program module in the file should have the same name as the file. Utility modules in the file should start with the name of the "command" (or last) module to make clear their purpose. 2. KEYWORD_SET is used to check whether a keyword is "used" or "defined". This function should only be used with binary keywords. (I plan to avoid all nuance with this list, and just go with black and white pronouncements.) 3. People draw graphics willy-nilly in widget programs without having the faintest idea which window their graphics might show up in. What would be on your list? Of course, typos are assumed. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.dfanning.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
On Apr 8, 8:13 pm, David Fanning <n...@dfanning.com> wrote: > > What would be on your list? Of course, typos are assumed. :-) I do a lot of outputting data into columns of a text file---the one that confused me for the longest time is that, unless otherwise stated, with the "width=" keyword, the line length of an opened file is 80 characters.
David Fanning wrote: > What would be on your list? Of course, typos are assumed. :-) > Naive use of data types: IDL> print, 30000 + 30000 -5536 IDL> print, 3 / 2 1 Thinking that any non-zero value is true: IDL> if (2) then print, 'True' else print, 'False' False Doug
One problem that I used to make all the time was to assume that WHERE returned a match, e.g., w = where(x gt 0) x[w] = alog10(x[w]) neglecting the case where the x are all negative. My programs would always work when I tested them, and then I'd find they failed when I tried them in the real world. The need to check finally got beaten into me. Another is fogetting the inherently parallel nature of array operations, e.g., something like expecting x=[0,1,1,2,2,2] y=indgen(3) y[x] = y[x]+1 to give something other than 1,1,1. Regards, Tom McGlynn
Andrew Cool writes: > May I refer you to your posts of the previous Millennium on Dec 1, > 2000, under > "How Computers Represent Floats" Oh, *that* article. I've got a better idea than to waste time thinking up new articles: I'm just going to recycle some old ones. Some of us wouldn't know the difference. ;-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.dfanning.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Boy! this is turning out to be one long list. And going through it I realized I have faced most of them and learnt them the hard way. Since I have been working with images in different formats, I would like to mention that the reading/ display order of various formats is easy to get confused with and when working with multiple formats at the same time, I have displayed my images upside down-many a times. I hope David extends his list beyond 10-15 to include all the common errors. Cheers, Gaurav
> Since I have been working with images in different formats, I would > like to mention that the reading/ display order of various formats is > easy to get confused with and when working with multiple formats at > the same time, I have displayed my images upside down-many a times. +1 I actually like having !order=1 in my defaults since most of the time my images are in top-bottom order. But I have no clue why the display coordinate system is not changed accordingly (both in direct and obj graphics).
On 10 apr, 04:18, Tom McGlynn <t...@milkyway.gsfc.nasa.gov> wrote: > One problem that I used to make all the time was to assume that WHERE > returned a match, e.g., > > w = where(x gt 0) > x[w] = alog10(x[w]) > > neglecting the case where the x are all negative. My programs would > always work when I tested them, and then I'd find they failed when I > tried them in the real world. The need to check finally got beaten > into me. > > Another is fogetting the inherently parallel nature of array > operations, e.g., something like expecting > > x=[0,1,1,2,2,2] > y=indgen(3) > > y[x] = y[x]+1 > > to give something other than 1,1,1. > > Regards, > Tom McGlynn Quote: - Coding up your own function when there's a perfectly useful inbuilt command that'll do what you want, and can even do it without three nested FOR loops ;-) Lol! So true this one!
On Apr 9, 9:33 pm, Doug <doug.lindh...@gmail.com> wrote: > David Fanning wrote: >> What would be on your list? Of course, typos are assumed. :-) > > Naive use of data types: > IDL> print, 30000 + 30000 > -5536 > IDL> print, 3 / 2 > 1 compile_opt defint32 in your startup script, and at the beginning of every function/procedure you write. Maarten
>>>> > "Carsten" == Carsten Lechte <chl@toppoint.de> writes: > PRINT, BYTE( 'test') eq BYTE( 'e') > PRINT, BYTE( 'test') eq (BYTE( 'e'))[0] By far my most common error is writing "print x" in IDL after I've been using python for a while and writing "print, x" in python after using IDL for a while. Mike
On Apr 10, 12:29 am, David Fanning <n...@dfanning.com> wrote: > Andrew Cool writes: >> May I refer you to your posts of the previous Millennium on Dec 1, >> 2000, under >> "How Computers Represent Floats" > > Oh, *that* article. > > I've got a better idea than to waste time thinking up > new articles: I'm just going to recycle some old ones. > Some of us wouldn't know the difference. ;-) > > Cheers, > > David > -- > David Fanning, Ph.D. > Fanning Software Consulting, Inc. > Coyote's Guide to IDL Programming:http://www.dfanning.com/ > Sepore ma de ni thui. ("Perhaps thou speakest truth.") David, May I suggest SciGen http://pdos.csail.mit.edu/scigen/ ? Cheers, Vince
On Apr 10, 8:22 am, mmill...@iupui.edu (Michael A. Miller) wrote: >>>> >> "Carsten" == Carsten Lechte <c...@toppoint.de> writes: > >> PRINT, BYTE( 'test') eq BYTE( 'e') > >> PRINT, BYTE( 'test') eq (BYTE( 'e'))[0] > > By far my most common error is writing "print x" in IDL after > I've been using python for a while and writing "print, x" in > python after using IDL for a while. > > Mike Ha - I find myself typing %> cat, file.txt in unix...
"David Fanning" <news@dfanning.com> wrote in message news:MPG.2265b7fc3128704798a320@news.frii.com... ... > Here are the three errors I most commonly see in IDL programs. I apologize for not having read all the replies - sorry if this is duplicating others. 1) multiple copies of a routine. I have done this a few times, with older "utility" programs that somehow get duplicated in different parts of the path. Which is fine cause IDL always uses the "first" one - until edits make the two copies branch independently and then function calls don't do what i think they are doing. 2) running off arrays - (depending on system settings) two cases, a) one where IDL repeats the last element and doesn't issue an error. b) where you multiply two arrays and the longer one gets truncated. Cheers, bob
On Apr 9, 10:18 pm, Tom McGlynn <t...@milkyway.gsfc.nasa.gov> wrote: ... > Another is fogetting the inherently parallel nature of array > operations, e.g., something like expecting > > x=[0,1,1,2,2,2] > y=indgen(3) > > y[x] = y[x]+1 > > to give something other than 1,1,1. > And perhaps I should include using the XXXgen functions when one means XXXarr! Tom
Tom McGlynn writes: > And perhaps I should include using the XXXgen functions when one > means XXXarr! I usually do exactly the opposite. :-( Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.dfanning.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
"Tom McGlynn" <tam@milkyway.gsfc.nasa.gov> wrote in message news:08513f0c-9af3-4613-900c-2449d1306fc5@l42g2000hsc.google groups.com... > On Apr 9, 10:18 pm, Tom McGlynn <t...@milkyway.gsfc.nasa.gov> wrote: > ... >> Another is fogetting the inherently parallel nature of array >> operations, e.g., something like expecting >> >> x=[0,1,1,2,2,2] >> y=indgen(3) >> >> y[x] = y[x]+1 >> >> to give something other than 1,1,1. >> > And perhaps I should include using the XXXgen functions when one > means XXXarr! > Tom XXXarr needs a /nan keyword (to fill it with nans). I always use it like a = fltarr(len) + !values.f_nan -bob
"R.G. Stockwell" <nothanks@noemail.com> writes: > a = fltarr(len) + !values.f_nan What about a = make_array(len, value=!values.f_nan) That's what I use. I'm sure it saves me some computational power by not having to compute those values I'm just going to overwrite anyway. :) Matt -- Matthew Savoie - Scientific Programmer National Snow and Ice Data Center (303) 735-0785 http://nsidc.org
<savoie@nsidc.org> wrote in message news:ywkufxtss6b9.fsf@snowblow.colorado.edu... > "R.G. Stockwell" <nothanks@noemail.com> writes: > > >> a = fltarr(len) + !values.f_nan > > What about > a = make_array(len, value=!values.f_nan) > > That's what I use. I'm sure it saves me some computational power by not > having > to compute those values I'm just going to overwrite anyway. :) You know, I am just the kind of person who will end up time testing those variations. And seeing what operation is faster: fltarr(len) + !values.f_nan, fltarr(len) - !values.f_nan, fltarr(len) * !values.f_nan, or fltarr(len)/!values.f_nan :) Cheers, bob
On Apr 11, 12:41 pm, "R.G. Stockwell" <notha...@noemail.com> wrote: > <sav...@nsidc.org> wrote in message > > news:ywkufxtss6b9.fsf@snowblow.colorado.edu... > >> "R.G. Stockwell" <notha...@noemail.com> writes: > >>> a = fltarr(len) + !values.f_nan > >> What about >> a = make_array(len, value=!values.f_nan) > >> That's what I use. I'm sure it saves me some computational power by not >> having >> to compute those values I'm just going to overwrite anyway. :) > > You know, I am just the kind of person who will end up time testing > those variations. And seeing what operation is faster: fltarr(len) + > !values.f_nan, > fltarr(len) - !values.f_nan, fltarr(len) * !values.f_nan, or > fltarr(len)/!values.f_nan > > :) > > Cheers, > bob I'm waiting with bated breath. 8^)
In article <fto23e$fk5$1@aioe.org>, "R.G. Stockwell" <nothanks@noemail.com> wrote: > "Tom McGlynn" <tam@milkyway.gsfc.nasa.gov> wrote in message > news:08513f0c-9af3-4613-900c-2449d1306fc5@l42g2000hsc.google groups.com... >> On Apr 9, 10:18 pm, Tom McGlynn <t...@milkyway.gsfc.nasa.gov> wrote: >> ... >>> Another is fogetting the inherently parallel nature of array >>> operations, e.g., something like expecting >>> >>> x=[0,1,1,2,2,2] >>> y=indgen(3) >>> >>> y[x] = y[x]+1 >>> >>> to give something other than 1,1,1. >>> >> And perhaps I should include using the XXXgen functions when one >> means XXXarr! >> Tom > > > XXXarr needs a /nan keyword (to fill it with nans). > I always use it like > > a = fltarr(len) + !values.f_nan > > -bob Or a = REPLICATE(!VALUES.F_NAN, len) Ken Bowman