| Most Common IDL Programming Errors [message #59761] |
Tue, 08 April 2008 17:13  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59772 is a reply to message #59761] |
Fri, 11 April 2008 05:55  |
Tom McGlynn
Messages: 13
Registered: January 2008
|
Junior Member |
|
|
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
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59796 is a reply to message #59761] |
Thu, 10 April 2008 07:29 |
Vince Hradil
Messages: 574
Registered: December 1999
|
Senior Member |
|
|
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
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59803 is a reply to message #59761] |
Thu, 10 April 2008 02:29 |
Erik[1]
Messages: 23
Registered: December 2006
|
Junior Member |
|
|
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!
|
|
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59811 is a reply to message #59761] |
Wed, 09 April 2008 19:18 |
Tom McGlynn
Messages: 13
Registered: January 2008
|
Junior Member |
|
|
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
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59848 is a reply to message #59761] |
Thu, 17 April 2008 08:52 |
rlayberry
Messages: 33
Registered: November 2004
|
Member |
|
|
On 9 Apr, 01:13, 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. :-)
remembering (sometimes) to use /swap_endian when reading in binary
data across platforms
not deleting large arrays when the program no longer needs them
not commenting at the top of my code what the program does and also
giving short but useless filenames (a1.pro etc)
|
|
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59897 is a reply to message #59761] |
Fri, 11 April 2008 14:23 |
Vince Hradil
Messages: 574
Registered: December 1999
|
Senior Member |
|
|
On Apr 11, 3:52 pm, "R.G. Stockwell" <notha...@noemail.com> wrote:
> "Vince Hradil" <hrad...@yahoo.com> wrote in message
>
> news:b4e816fa-1c96-44a1-96bb-1a4e7395d376@24g2000hsh.googleg roups.com...
>
>> 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^)
>
> Here they are (10k iterations, ran loops over the different
> commands, repeated them in different orders, all functions and arrays
> were previously created):
>
> (and by the way WOW! - make array wins)
>
> plus 89.172000 Seconds.
>
> minus 89.188000 Seconds.
>
> multiply 90.531000 Seconds.
>
> divide 89.485000 Seconds.
>
> makearray 2.0000000 Seconds.
>
> makearray 1.9840000 Seconds.
>
> divide 90.250000 Seconds.
>
> multiply 90.219000 Seconds.
>
> minus 88.797000 Seconds.
>
> plus 88.125000 Seconds.
"Wow!" is right. I was being facetious originally, but I think I
really learned something. Thanks for the effort.
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59899 is a reply to message #59761] |
Fri, 11 April 2008 11:37 |
Kenneth P. Bowman
Messages: 585
Registered: May 2000
|
Senior Member |
|
|
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
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59900 is a reply to message #59761] |
Fri, 11 April 2008 13:52 |
R.G. Stockwell
Messages: 363
Registered: July 1999
|
Senior Member |
|
|
"Vince Hradil" <hradilv@yahoo.com> wrote in message
news:b4e816fa-1c96-44a1-96bb-1a4e7395d376@24g2000hsh.googleg roups.com...
> 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^)
Here they are (10k iterations, ran loops over the different
commands, repeated them in different orders, all functions and arrays
were previously created):
(and by the way WOW! - make array wins)
plus 89.172000 Seconds.
minus 89.188000 Seconds.
multiply 90.531000 Seconds.
divide 89.485000 Seconds.
makearray 2.0000000 Seconds.
makearray 1.9840000 Seconds.
divide 90.250000 Seconds.
multiply 90.219000 Seconds.
minus 88.797000 Seconds.
plus 88.125000 Seconds.
|
|
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #59912 is a reply to message #59772] |
Fri, 11 April 2008 09:02 |
R.G. Stockwell
Messages: 363
Registered: July 1999
|
Senior Member |
|
|
"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
|
|
|
|
|
|
|
|
| Re: Most Common IDL Programming Errors [message #80784 is a reply to message #59761] |
Tue, 10 July 2012 01:33 |
gerapagi
Messages: 1
Registered: July 2012
|
Junior Member |
|
|
On Wednesday, April 9, 2008 5:43:17 AM UTC+5:30, David Fanning 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.")
I just want know where are the references for the formula or algorithm used in IDL?
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
