| undefined keyword variables [message #17531] |
Sat, 30 October 1999 00:00  |
Mark Fardal
Messages: 51
Registered: October 1995
|
Member |
|
|
Hi,
A question: should you always be able to pass undefined variables as
keywords to IDL routines?
For example, PLOT is smart enough not to do anything with this undefined
variable
IDL> plot,x,y,title=donkeykong
[plots fine]
but not this one
IDL> plot,x,y,clip=pong
% PLOT: Variable is undefined: PONG.
% Execution halted at: $MAIN$
[no plot produced]
IDL> help,donkeykong, pong
DONKEYKONG UNDEFINED = <Undefined>
PONG UNDEFINED = <Undefined>
Should this be considered a bug in plot, or as normal behavior?
In general I don't know why you should be able to safely feed
undefined variables to routines and expect them to work. But if you
can't, it leads to annoying problems in writing interfaces to any
routine with lots of keywords. In my case, I wanted to write a
routine that called plot and then oplot, which use different sets of
optional keyword parameters. The best solution I know of is to
construct a value for the _extra keyword, but it's a pretty convoluted
solution.
Mark Fardal
UMass
|
|
|
|
|
|
| Re: undefined keyword variables [message #17607 is a reply to message #17531] |
Mon, 01 November 1999 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
J.D. Smith (jdsmith@astro.cornell.edu) writes the kind of
article I wish I could write more often when he says:
> It's really not a difference between built-in and compiled routines,
> just well-written and poorly written routines. Back when I first
> noticed this phenomenon of built-in routines recognizing undefined
> variables, I immediately knew that RSI programmers had access to some
> argument functionality we in compiled-land did not. Thus was
> arg_present() born. I can now write a compiled routine which can:
>
> 1) Discern if a keyword is passed at all.
> 2) Discern if a keyword is passed with a value.
> 3) Discern if a keyword is passed which has scope in the passing level
> (by reference).
>
> Both 2 & 3 can be simultaneously true. So, since the introduction of
> arg_present, we can make programs which handle undefined submitted
> keywords gracefully, in whatever way necessary. This doesn't mean we
> *will*. Here is an example which demonstrates the various
> possibilities. Note that keyword_set is a really a subset of
> n_elements, and so isn't explicity included, though it can be useful.
> I can easily produce a routine which fails on some keywords and not on
> others when passed undefined variables. So can RSI. The problem is
> there isn't always a correct thing to do... maybe an error is actually
> appropriate in some cases, but consistency should be policy.
Good stuff, here.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: undefined keyword variables [message #17608 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
>
> Dusting off my degree in horse-beating...
Oh, well, it's a slow day here, too. :-)
>
> davidf@dfanning.com (David Fanning) writes:
>>
>> I think it is not only feasible, but required, that you
>> provide default values for *any* variable you plan
>> to use in the code. Certainly if I were planning to
>> use the POSITION keyword I would have something like this:
>>
>> IF N_Elements(thePosition) EQ 0 THEN thePosition=!P.Position
>> ...
>> Plot, data, Position=thePosition
>
> This doesn't always work. Here is what happens when I examine
> !p.position after starting IDL fresh:
>
> IDL> print, !version
> { alpha OSF unix 5.2 Oct 30 1998}
> IDL> print, !p.position
> 0.00000 0.00000 0.00000 0.00000
Whoops! Indeed. Case of IDL not being as smart
as it usually is, I think. But, then, this is one
of those keywords that is apparently escaping
scrutiny anyway.
> My point is that *whatever* strategy that IDL uses to pass undefined
> keywords appears to be inconsistent. It should either be documented
> or corrected.
I shouldn't think they would document it. Too embarrassing.
But I hear they are fixing it, and indeed my IDL 5.3 beta
seems to handle things more gracefully. Although not, alas,
in this specific case.
But to be fair, checking variables can be a damn nuisance.
I have someone hounding me now about one of the programs
I have on my web page. Even though the documentation
clearly says use NORMALIZED coordinates, he wants to use
DATA coordinates. So my tick marks are the wrong length.
So...what to do. Enforce the normalized convention when I
check my keywords, or modify the code to handle a situation
I didn't anticipate? I'll probably modify the code. But
now I have a better idea of how people will use my code
and--yikes!--I have a lot of code out there that could
benefit from my new understanding. Will I change it?
No, probably not. Not unless someone else starts hounding
me with e-mails.
But I *might* think about it the next time I'm foolish
enough to publish something in a public forum. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: undefined keyword variables [message #17611 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
J.D. Smith
Messages: 214
Registered: August 1996
|
Senior Member |
|
|
Craig Markwardt wrote:
>
> davidf@dfanning.com (David Fanning) writes:
>>
>> Mark Fardal (fardal@weka.astro.umass.edu) writes:
>>
>>> A question: should you always be able to pass undefined variables as
>>> keywords to IDL routines?
>>
>> Oh, this is absolutely normal behavior. (At least under the
>> usual standards by which such things are judged in IDL.)
>> Is it *correct* behavior? Don't know. But I would doubt it.
>> Seems to me *any* optional input keyword should be capable of
>> accepting an undefined variable as an argument. I would run
>> it by RSI for confirmation.
>>
>>> In general I don't know why you should be able to safely feed
>>> undefined variables to routines and expect them to work.
>>
>> Well, because you expect decent programmers to test any
>> variable they expect to receive and define default values
>> if one is not passed in. (As well as testing for data type
>> and structure, but who among us does this except under
>> exceptional conditions?)
>
> I am never sure any more how undefined keywords are passed. It seems
> to make a difference whether it's a built-in routine, or an IDL
> routine. It seems to make a difference whether it's IDL 4 or 5. It
> seems to make a difference if you refer to the variable by name before
> calling the procedure (not necessarily setting its value). All these
> factors make it hard to handle pass-through keywords consistently. It
> would be nice (no, crucial!) to have this more carefully documented by
> RSI.
It's really not a difference between built-in and compiled routines,
just well-written and poorly written routines. Back when I first
noticed this phenomenon of built-in routines recognizing undefined
variables, I immediately knew that RSI programmers had access to some
argument functionality we in compiled-land did not. Thus was
arg_present() born. I can now write a compiled routine which can:
1) Discern if a keyword is passed at all.
2) Discern if a keyword is passed with a value.
3) Discern if a keyword is passed which has scope in the passing level
(by reference).
Both 2 & 3 can be simultaneously true. So, since the introduction of
arg_present, we can make programs which handle undefined submitted
keywords gracefully, in whatever way necessary. This doesn't mean we
*will*. Here is an example which demonstrates the various
possibilities. Note that keyword_set is a really a subset of
n_elements, and so isn't explicity included, though it can be useful.
pro testkey,KEY1=k1
case arg_present(k1)+2L*(n_elements(k1) ne 0) of
0: print,'Nothing was passed through the keyword.'
1: print,'An undefined variable was passed.'
2: print,'A value without scope in the passing level was passed.'
3: print,'A defined and valued variable was passed.'
endcase
end
IDL> testkey
Nothing was passed through the keyword.
IDL> testkey,KEY1=1
A value without scope in the passing level was passed.
IDL> testkey,KEY1=undef_var
An undefined variable was passed.
IDL> undef_var=[1,2,3]
IDL> testkey,KEY1=undef_var
A defined and valued variable was passed.
RSI programmers have similar (and perhaps more) functionality for
writing built-in programs. This doesn't mean they'll use it
consistently or correctly.
I can easily produce a routine which fails on some keywords and not on
others when passed undefined variables. So can RSI. The problem is
there isn't always a correct thing to do... maybe an error is actually
appropriate in some cases, but consistency should be policy.
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
| Re: undefined keyword variables [message #17612 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Dusting off my degree in horse-beating...
davidf@dfanning.com (David Fanning) writes:
>
> I think it is not only feasible, but required, that you
> provide default values for *any* variable you plan
> to use in the code. Certainly if I were planning to
> use the POSITION keyword I would have something like this:
>
> IF N_Elements(thePosition) EQ 0 THEN thePosition=!P.Position
> ...
> Plot, data, Position=thePosition
This doesn't always work. Here is what happens when I examine
!p.position after starting IDL fresh:
IDL> print, !version
{ alpha OSF unix 5.2 Oct 30 1998}
IDL> print, !p.position
0.00000 0.00000 0.00000 0.00000
That causes an error when I try to plot. Anyway, your solution takes
the previous plot position. I was interested in using the IDL default
position. I haven't found any logical way to figure that out. [ Okay,
there's the plot,/nodata,xstyle=5,ystyle=5 technique to set up the
coordinates ahead of time. Hmmm... ] I run into this situation where
I have two paths in my code, one path where I set the POSITION, and
one where I just want to pass the user's value. Check out map_set.pro
and map_struct_append to see what contortions RSI went through.
My point is that *whatever* strategy that IDL uses to pass undefined
keywords appears to be inconsistent. It should either be documented
or corrected.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: undefined keyword variables [message #17613 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
Paul Hick
Messages: 9
Registered: November 1999
|
Junior Member |
|
|
In IDL5.2 several other plot keywords show the same behaviour as clip:
position, [xyz]margin, [xyz]range, [xyz]tickname, [xyz]tickv
I reported this to RSI a while back. In IDL5.3 (I'm running the Windows
beta version) this has been fixed. Presumably now the values from system
variables (!p.position, !x.margin, etc.) are used if the keyword
variable
is undefined.
Mark Fardal wrote:
>
> Hi,
>
> A question: should you always be able to pass undefined variables as
> keywords to IDL routines?
>
> For example, PLOT is smart enough not to do anything with this undefined
> variable
>
> IDL> plot,x,y,title=donkeykong
> [plots fine]
>
> but not this one
> IDL> plot,x,y,clip=pong
> % PLOT: Variable is undefined: PONG.
> % Execution halted at: $MAIN$
> [no plot produced]
>
> IDL> help,donkeykong, pong
> DONKEYKONG UNDEFINED = <Undefined>
> PONG UNDEFINED = <Undefined>
>
> Should this be considered a bug in plot, or as normal behavior?
>
> In general I don't know why you should be able to safely feed
> undefined variables to routines and expect them to work. But if you
> can't, it leads to annoying problems in writing interfaces to any
> routine with lots of keywords. In my case, I wanted to write a
> routine that called plot and then oplot, which use different sets of
> optional keyword parameters. The best solution I know of is to
> construct a value for the _extra keyword, but it's a pretty convoluted
> solution.
>
> Mark Fardal
> UMass
|
|
|
|
| Re: undefined keyword variables [message #17615 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> As to David's suggestion to define default values, that's not always
> feasible. What about the POSITION keyword? If it's not defined then
> you want to rely on IDL's standard positioning. No default should be
> required!
I think it is not only feasible, but required, that you
provide default values for *any* variable you plan
to use in the code. Certainly if I were planning to
use the POSITION keyword I would have something like this:
IF N_Elements(thePosition) EQ 0 THEN thePosition=!P.Position
...
Plot, data, Position=thePosition
As for keywords that come in with _Extra, well, that's
what God made the Catch statement for. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: undefined keyword variables [message #17617 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
>
> Mark Fardal (fardal@weka.astro.umass.edu) writes:
>
>> A question: should you always be able to pass undefined variables as
>> keywords to IDL routines?
>
> Oh, this is absolutely normal behavior. (At least under the
> usual standards by which such things are judged in IDL.)
> Is it *correct* behavior? Don't know. But I would doubt it.
> Seems to me *any* optional input keyword should be capable of
> accepting an undefined variable as an argument. I would run
> it by RSI for confirmation.
>
>> In general I don't know why you should be able to safely feed
>> undefined variables to routines and expect them to work.
>
> Well, because you expect decent programmers to test any
> variable they expect to receive and define default values
> if one is not passed in. (As well as testing for data type
> and structure, but who among us does this except under
> exceptional conditions?)
I am never sure any more how undefined keywords are passed. It seems
to make a difference whether it's a built-in routine, or an IDL
routine. It seems to make a difference whether it's IDL 4 or 5. It
seems to make a difference if you refer to the variable by name before
calling the procedure (not necessarily setting its value). All these
factors make it hard to handle pass-through keywords consistently. It
would be nice (no, crucial!) to have this more carefully documented by
RSI.
As to David's suggestion to define default values, that's not always
feasible. What about the POSITION keyword? If it's not defined then
you want to rely on IDL's standard positioning. No default should be
required!
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: undefined keyword variables [message #17620 is a reply to message #17531] |
Mon, 01 November 1999 00:00 |
meron
Messages: 51
Registered: July 1995
|
Member |
|
|
In article <MPG.128617e7f136424a98992c@news.frii.com>, davidf@dfanning.com (David Fanning) writes:
> Mati Meron (meron@cars3.uchicago.edu) writes:
>
>>> Well, because you expect decent programmers to test any
>>> variable they expect to receive and define default values
>>> if one is not passed in. (As well as testing for data type
>>> and structure, but who among us does this except under
>>> exceptional conditions?)
>>>
>> That's where you need function like my Default, which does both.
>
> And that function is ... where, Mati? For those of us
> who have forgotten to bookmark your very useful collection
> of programs.
>
At the moment, the most updated version of what I've is on
cars3.uchicago.edu. You can get there through anonymous FTP, then CD
to MIDL and download everything is sight (strongly recommended, if you
download anything, download it all, since whatever routine you take
will be calling other ones.
Mati Meron | "When you argue with a fool,
meron@cars.uchicago.edu | chances are he is doing just the same"
|
|
|
|
| Re: undefined keyword variables [message #17621 is a reply to message #17531] |
Sun, 31 October 1999 00:00 |
Liam Gumley
Messages: 473
Registered: November 1994
|
Senior Member |
|
|
Mark Fardal <fardal@weka.astro.umass.edu> wrote in message
news:7vbt9gk4jk.fsf@weka.phast.umass.edu...
> A question: should you always be able to pass undefined variables as
> keywords to IDL routines?
>
> For example, PLOT is smart enough not to do anything with this undefined
> variable
>
> IDL> plot,x,y,title=donkeykong
> [plots fine]
>
> but not this one
> IDL> plot,x,y,clip=pong
> % PLOT: Variable is undefined: PONG.
> % Execution halted at: $MAIN$
> [no plot produced]
>
> IDL> help,donkeykong, pong
> DONKEYKONG UNDEFINED = <Undefined>
> PONG UNDEFINED = <Undefined>
>
> Should this be considered a bug in plot, or as normal behavior?
A bug, no. Inconsistent behavior, maybe.
>
> In general I don't know why you should be able to safely feed
> undefined variables to routines and expect them to work. But if you
> can't, it leads to annoying problems in writing interfaces to any
> routine with lots of keywords. In my case, I wanted to write a
> routine that called plot and then oplot, which use different sets of
> optional keyword parameters. The best solution I know of is to
> construct a value for the _extra keyword, but it's a pretty convoluted
> solution.
The most obvious reason to pass undefined variables as keywords is when they
are supposed to be *set* in the called procedure or function. If output
keywords are passed, you check them like this:
if n_elements(key) gt 0 and arg_present(key) ne 1 then $
message, 'Output keyword KEY is an expression and cannot be set'
Keywords that are used as *input* arguments fall into two classes.
First, they can be true/false flags. In this case, they do not need to be
checked. All you need to do is use KEYWORD_SET whenever the keyword is used,
e.g.
if keyword_set(ps) then begin
current_device = !d.name
set_plot, 'PS'
device, /landscape, /color, bits=8
endif
Second, they can be input values. In this case, they should be checked to
see if they are defined, and if not, then default value(s) should be
assigned, e.g.
if n_elements(range) eq 0 then begin
minvalue = min(data, max=maxvalue)
range = [minvalue, maxvalue]
endif
If you wish to pass extra keywords to PLOT or OPLOT or any other routine,
you only need to check the keywords which you explicitly wish to use in your
procedure. For example, here is a PLOT/OPLOT wrapper which lets you
control plot colors more easily:
;---cut here---
PRO SPLOT, X, Y, $
BACKGROUND=BACKGROUND, CHARSIZE=CHARSIZE, $
COLOR=COLOR, WINCOLOR=WINCOLOR, PLOTCOLOR=PLOTCOLOR, $
_EXTRA = extra_keywords
;- Check arguments
if n_params() eq 0 then message, 'Usage: SPLOT, Y or SPLOT, X, Y'
if n_elements(x) eq 0 then message, 'Argument Y is undefined'
;- Check keywords
if n_elements(background) eq 0 then background = 0
if n_elements(charsize) eq 0 then charsize = 1.0
if n_elements(color) eq 0 then color = !d.table_size - 1
if n_elements(wincolor) eq 0 then wincolor = background
if n_elements(plotcolor) eq 0 then plotcolor = !d.table_size - 1
;- Save first element of !p.multi
multi_first = !p.multi[0]
;- Erase screen and establish plot position
plot, [0], /nodata, xstyle=4, ystyle=4, $
background=background, charsize=charsize
pos = [!x.window[0], !y.window[0], !x.window[1], !y.window[1]]
;- If Postscript output, fill background
if !d.name eq 'PS' and multi_first le 0 then $
polyfill, [0.0,1.0,1.0,0.0], [0.0,0.0,1.0,1.0], $
/normal, color=background
;- Fill plot window background
polyfill, [pos[0], pos[2], pos[2], pos[0], pos[0]], $
[pos[1], pos[1], pos[3], pos[3], pos[1]], $
/normal, color=wincolor
;- Plot the data points
case n_params() of
1 : begin
plot, x, /noerase, /nodata, color=color, $
position=pos, charsize=charsize, _extra=extra_keywords
oplot, x, color=plotcolor, _extra=extra_keywords
end
2 : begin
plot, x, y, /noerase, /nodata, color=color, $
position=pos, charsize=charsize, _extra=extra_keywords
oplot, x, y, color=plotcolor, _extra=extra_keywords
end
endcase
END
;---cut here---
Notice that the keywords I want to use (BACKGROUND, CHARSIZE, COLOR) are
listed explicitly in the arguments to this procedure. Any other keywords are
stuffed into EXTRA_KEYWORDS. There is no problem passing the same
EXTRA_KEYWORDS structure to both PLOT and OPLOT; they just use any keywords
they recognize, and ignore the rest.
Using the procedure above, and if you grab my COLORS routine from
http://cimss.ssec.wisc.edu/~gumley/idl/colors.pro, you can do this:
IDL> device, decomposed=0
IDL> colors
IDL> x = findgen(200) * 0.1
IDL> y = sin(x)
IDL> splot, x, y, background=13, wincolor=7, plotcolor=1, color=0
That is, you can control the colors of the plot background, the plot window,
the plot axes, and the plotted data independently. Works in Postscript too.
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
|
|
|
|
| Re: undefined keyword variables [message #17665 is a reply to message #17531] |
Wed, 03 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
>
> I think it is not only feasible, but required, that you
> provide default values for *any* variable you plan
> to use in the code. Certainly if I were planning to
> use the POSITION keyword I would have something like this:
>
By the way David, I agree with you. In *almost* all circumstances,
keyword parameters should be given appropriate default values which
should be *documented*.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: undefined keyword variables [message #17671 is a reply to message #17531] |
Wed, 03 November 1999 00:00 |
m218003
Messages: 56
Registered: August 1999
|
Member |
|
|
In article <MPG.1287a145f4a5803998992d@news.frii.com>,
davidf@dfanning.com (David Fanning) writes:
>
> I think it is not only feasible, but required, that you
> provide default values for *any* variable you plan
> to use in the code. Certainly if I were planning to
> use the POSITION keyword I would have something like this:
>
> IF N_Elements(thePosition) EQ 0 THEN thePosition=!P.Position
> ...
> Plot, data, Position=thePosition
>
Hi David,
here is one for you. I just checked out the code for MAP_SET, and
here's what I found:
if keyword_set(position) then $
...
Seems like you should give one of your famous courses over there ;-)
Cheers,
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
