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.")
> 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.")
How about: -indexing for-loops with (short) integers. -using indeces from where without checking count > 0
David Fanning wrote: > 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. :-)
Here are a few (in no particular order, despite the numbers):
1. Thinking you are using a color table in direct graphics, but are actually using decomposed color (shades of red problem).
2. Not setting up color in PS output correctly.
3. Confusion with direct graphics output in landscape mode in PS.
4. Not scaling object graphics into a coordinate system correctly.
> On Apr 8, 7:13 pm, David Fanning <n...@dfanning.com> wrote:
> > 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.")
> How about: > -indexing for-loops with (short) integers. > -using indeces from where without checking count > 0
<...> 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. <...>
Some others...
Forgetting about a "catch" statement that lies buried somewhere, hiding other bugs or making a total mystery of execution problems.
Forgetting to use "reform" - stumbling on an unwanted array dimension of 1 that's left after pulling out an array subset. (Actually I don't know if this one's still there. I'm a bit behind the times maybe.)
Getting "rows" mixed up with "columns" (whatever they are) when using IDL calls that involve matrices.
> 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.")
1. Indexing FOR loops with a float 2. Reading undefined variables from a file. 3. Lack of comments in some other cretin's legacy code.
Andrew Cool writes: > 1. Indexing FOR loops with a float
I think you missed the word "common", Andrew. :-)
I don't even know what this problem is. Can you elaborate?
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.")
Peter Mason writes: > Getting "rows" mixed up with "columns" (whatever they are) when using IDL > calls that involve matrices.
Oh, my gosh! I've been working on an EOF (Empirical Orthogonal Functions) problem the past 3-4 days, and I'll bet I spent half my time trying to wrap my mind around this! "OK, does the LA_SVD routine think like IDL or like matrix algebra? When it says the first mode EOF is in the column of the output is that in a linear algebra sense or an IDL sense?" One more day of it and I'll be ready to buy Matlab. (Heck, all the examples are in Matlab code.)
Even now, when I am *sure* I know what I'm doing, I have momentary doubts. Why don't you write us a primer, Peter? :-)
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 9, 3:27 am, David Fanning <n...@dfanning.com> wrote:
Judging by the fact that we've got 11 IDL licences in the building, probably 5-15 users in any given week (including at least one *Real* computer scientist - with a PhD and everything) and I'm the only one who ever seems to use REBIN, REFORM, REVERSE... even READ_BINARY instead of OPENR / FSTAT / READU, I'd say some more major errors are:
- Not knowing where to find the useful built-in functions in the sea of helpfiles - 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 ;-) - Writing code that solves one specific problem (particularly using integers that don't change for this dataset but may well do so for the next one, rendering the function useless without major re-working, when a simple call to SIZE would have made it SOOO much more flexible)
So in short, I'd love to see an article entitled something like: "I've only got time to read a dozen helpfiles - which ones should I read?" This could contain the names of the commands and a brief one-line summary of what each one does. Of course, deciding which helpfiles to pick is liable to cause some, uh... heated debate ;-)
FWIW, I'd definitely throw in: SIZE, REFORM, REBIN, TRANSPOSE, WHERE, BYTSCL ... and then maybe ARRAY_INDICES; also TV, PLOT, OPLOT & TVSCL to show the wealth of keywords they accept.
I realise that I'm coming at this from a biophysics-lab-in-academia angle, which may be completely different to other people.
On Apr 9, 12:13 am, David Fanning <n...@dfanning.com> wrote:
> Here are the three errors I most commonly see in IDL programs.
[snip]
> What would be on your list? Of course, typos are assumed. :-)
How about any code that does not use compile_opt defint32, strictarr, strictarrsubs Yes, the first two can be combined with idl2, which gives you an idea how long overdue it is to make this the default. I prefer this way, because it does give you some idea of what changes. You can put this in your startup script, and avoid an awful amount of surprises.
The other errors I observe in IDL code are mostly part of the syntax itself :p
> > Getting "rows" mixed up with "columns" (whatever they are) when using IDL > > calls that involve matrices.
> Oh, my gosh! I've been working on an EOF (Empirical > Orthogonal Functions) problem the past 3-4 days, and > I'll bet I spent half my time trying to wrap my mind > around this! "OK, does the LA_SVD routine think like > IDL or like matrix algebra? When it says the first > mode EOF is in the column of the output is that in > a linear algebra sense or an IDL sense?" One more day > of it and I'll be ready to buy Matlab. (Heck, all the > examples are in Matlab code.)
> Even now, when I am *sure* I know what I'm doing, > I have momentary doubts. Why don't you write us > a primer, Peter? :-)
> Cheers,
> David
David, I have some EOF code that is only a few lines long if you want it (using LA_EIGENQL).
