| Re: Named Indices [message #21905] |
Wed, 27 September 2000 00:00 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
David Fanning wrote:
>
> J.D. Smith (jdsmith@astro.cornell.edu) writes:
>
>> A slightly more portable solution, in the sense that it requires no modification
>> of startup code but simply inclusion of a program somewhere on the path
>> (presumably in the same directory tree as the program which would use it), is a
>> special purpose function. E.g.
>>
>> plot, findgen(11), LINESTYLE=linestyle(/DASH)
>>
>> You could even make an uber-function that encapsulates all such "named
>> entity"<->"integer value" constant mappings:
>>
>> const(/LINESTYLE,/DASH) ; produces 2
>>
>> const(/AXIS_STYLE,/FORCE,/SUPPRESS) ; produces 4 or 2 = 6
>>
>> const(/SIZE,/INTEGER) ; produces 2
>>
>> const(/WIDGET_DRAW_TYPE,/BUTTON_RELEASE) ; produces 1
>>
>> const(/AXIS_NUMBER,/X) ; produces 0
>>
>> const(/COLOR_TABLE,/PRISM) ; produces 6
>>
>> etc.
>>
>> The problem is you have to maintain it with new versions of IDL, and ensure
>> backwards compatibility too. Other issues crop up, such as private color table
>> lists, etc. It would definitely help readability though. Sounds like a great
>> beginner programming project that would readily educate one on the subtle
>> distinctions among keyword_set(), n_elements() ne 0, and arg_present().
>
> I thought about a function too, although not such
> a generic one. But I got this far:
>
> FUNCTION LS, Solid=Solid, Dot=Dot, Dash=Dash, DashDot=DashDot...
>
> When I realized I was in trouble with keyword names.
> In the end, I decided cryptic numbers were better
> than a long-winded explanation of how keyword names
> work. :-(
>
> But what I'm really surprised you didn't offer was
> a way to write a polymorphic object to do the job. :-)
I said it was a *beginner* function to code up, David. Intermediate users would
of course wrap it in a superclass so that new maps could be created at will by
self-aware plotting entities which lie hiding silently under your terminal and
creep out at night to plot things you'll never see. But then again, you'll need
to create that object sometime, perhaps in the startup file and then... o damn
we're back to where we started.
Ahh yes, the familiar "Ambiguous keyword abbreviation" a.k.a. a.k.a. The only
workaround being carnal manipulation of the _EXTRA structure. So that makes
this not so beginner a problem. You could always use strings instead, but
that's an extra character to type:
const(/LINESTYLE,'dotdash')
The solution is left as an exercise.
JD
JD
--
J.D. Smith /*\ WORK: (607) 255-6263
Cornell University Dept. of Astronomy \*/ (607) 255-5842
304 Space Sciences Bldg. /*\ FAX: (607) 255-5875
Ithaca, NY 14853 \*/
|
|
|
|
| Re: Named Indices [message #21908 is a reply to message #21905] |
Wed, 27 September 2000 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
J.D. Smith (jdsmith@astro.cornell.edu) writes:
> A slightly more portable solution, in the sense that it requires no modification
> of startup code but simply inclusion of a program somewhere on the path
> (presumably in the same directory tree as the program which would use it), is a
> special purpose function. E.g.
>
> plot, findgen(11), LINESTYLE=linestyle(/DASH)
>
> You could even make an uber-function that encapsulates all such "named
> entity"<->"integer value" constant mappings:
>
> const(/LINESTYLE,/DASH) ; produces 2
>
> const(/AXIS_STYLE,/FORCE,/SUPPRESS) ; produces 4 or 2 = 6
>
> const(/SIZE,/INTEGER) ; produces 2
>
> const(/WIDGET_DRAW_TYPE,/BUTTON_RELEASE) ; produces 1
>
> const(/AXIS_NUMBER,/X) ; produces 0
>
> const(/COLOR_TABLE,/PRISM) ; produces 6
>
> etc.
>
> The problem is you have to maintain it with new versions of IDL, and ensure
> backwards compatibility too. Other issues crop up, such as private color table
> lists, etc. It would definitely help readability though. Sounds like a great
> beginner programming project that would readily educate one on the subtle
> distinctions among keyword_set(), n_elements() ne 0, and arg_present().
I thought about a function too, although not such
a generic one. But I got this far:
FUNCTION LS, Solid=Solid, Dot=Dot, Dash=Dash, DashDot=DashDot...
When I realized I was in trouble with keyword names.
In the end, I decided cryptic numbers were better
than a long-winded explanation of how keyword names
work. :-(
But what I'm really surprised you didn't offer was
a way to write a polymorphic object to do the job. :-)
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: Named Indices [message #21909 is a reply to message #21905] |
Wed, 27 September 2000 00:00 |
promashkin
Messages: 169
Registered: December 1999
|
Senior Member |
|
|
David Fanning wrote:
> And most of us (present company included) don't have any
> idea what that code does five minutes after we write the
> program.
Sure we do. Five minutes, five days and five weeks later, it still sits
on our FTP server, and we are the only ones who ever downloads it when
we happen to be at some other location :-)
Cheers,
Pavel
P.S. I swear I downloaded your FSC_PSConfig! This, actually, does mean
that you have no idea what is happening to it :-) but neither do I :-(
|
|
|
|
| Re: Named Indices [message #21912 is a reply to message #21905] |
Wed, 27 September 2000 00:00 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
David Fanning wrote:
>
> Jason P. Meyers (jpm7934@cis.rit.edu) writes:
>
>> I am brand new to IDL programming. I am using version 5.3.1 on a PC
>> and started going through some examples from my Digital Image Processing
>> (DIP) class as well as some from the online manuals and Dave Fanning's
>> book. I got to wondering if there exists (either built-in or developed
>> by someone else) a list of named indices. Such a beast would be useful
>> for specifying things line styles using names instead of numbers.
>>
>> For example,
>>
>> PLOT, time, curve, LineStyle=LongDash
>>
>> makes more sense to me than
>>
>> PLOT, time, curve, LineStyle=5
>>
>> One idea I had was to create a structured system variable named !I (for
>> indices) which then has the various indices as fields. For example:
>>
>> !I.Solid = 0
>> !I.Dot = 1
>> !I.Dash = 2
>> !I.DashDot = 3
>> !I.Dash3Dot = 4
>> !I.LongDash = 5
>>
>> I couldn't find a reference to such a system variable. Furthermore, I
>> don't even know if it is possible to create new system variables like
>> this. Finally, if something like this can be created, I don't want to
>> reinvent the wheel if it already exists.
>
> Well, it *is* possible to do something like this, since
> you can make new system variables. In fact, to do what
> you want to do requires an IDL statement like this:
>
> DefSysV, '!LS', {solid:0, dot:1, dash:2, dashdot:3, dashdotdot:4, longdash:5}, 1
>
> I used !LS for "line style", but what name you choose is up to you.
> You can put this kind of statement in, for example, an IDL
> start-up file.
>
> The principle reason this is not done more often
> is that programs that rely on it:
>
> Plot, Findgen(11), Linestyle=!LS.Dash
>
> don't work when they are passed along to someone else.
> You always forget to give them your start-up file, or
> they got it, but they forget to run it, etc. So most of
> us stay with the lowest common denominator code:
>
> Plot, Findgen(11), Linestyle=2
>
> And most of us (present company included) don't have any
> idea what that code does five minutes after we write the
> program.
>
A slightly more portable solution, in the sense that it requires no modification
of startup code but simply inclusion of a program somewhere on the path
(presumably in the same directory tree as the program which would use it), is a
special purpose function. E.g.
plot, findgen(11), LINESTYLE=linestyle(/DASH)
You could even make an uber-function that encapsulates all such "named
entity"<->"integer value" constant mappings:
const(/LINESTYLE,/DASH) ; produces 2
const(/AXIS_STYLE,/FORCE,/SUPPRESS) ; produces 4 or 2 = 6
const(/SIZE,/INTEGER) ; produces 2
const(/WIDGET_DRAW_TYPE,/BUTTON_RELEASE) ; produces 1
const(/AXIS_NUMBER,/X) ; produces 0
const(/COLOR_TABLE,/PRISM) ; produces 6
etc.
The problem is you have to maintain it with new versions of IDL, and ensure
backwards compatibility too. Other issues crop up, such as private color table
lists, etc. It would definitely help readability though. Sounds like a great
beginner programming project that would readily educate one on the subtle
distinctions among keyword_set(), n_elements() ne 0, and arg_present().
JD
--
J.D. Smith /*\ WORK: (607) 255-6263
Cornell University Dept. of Astronomy \*/ (607) 255-5842
304 Space Sciences Bldg. /*\ FAX: (607) 255-5875
Ithaca, NY 14853 \*/
|
|
|
|
| Re: Named Indices [message #21913 is a reply to message #21905] |
Wed, 27 September 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Jason P. Meyers (jpm7934@cis.rit.edu) writes:
> I am brand new to IDL programming. I am using version 5.3.1 on a PC
> and started going through some examples from my Digital Image Processing
> (DIP) class as well as some from the online manuals and Dave Fanning's
> book. I got to wondering if there exists (either built-in or developed
> by someone else) a list of named indices. Such a beast would be useful
> for specifying things line styles using names instead of numbers.
>
> For example,
>
> PLOT, time, curve, LineStyle=LongDash
>
> makes more sense to me than
>
> PLOT, time, curve, LineStyle=5
>
> One idea I had was to create a structured system variable named !I (for
> indices) which then has the various indices as fields. For example:
>
> !I.Solid = 0
> !I.Dot = 1
> !I.Dash = 2
> !I.DashDot = 3
> !I.Dash3Dot = 4
> !I.LongDash = 5
>
> I couldn't find a reference to such a system variable. Furthermore, I
> don't even know if it is possible to create new system variables like
> this. Finally, if something like this can be created, I don't want to
> reinvent the wheel if it already exists.
Well, it *is* possible to do something like this, since
you can make new system variables. In fact, to do what
you want to do requires an IDL statement like this:
DefSysV, '!LS', {solid:0, dot:1, dash:2, dashdot:3, dashdotdot:4, longdash:5}, 1
I used !LS for "line style", but what name you choose is up to you.
You can put this kind of statement in, for example, an IDL
start-up file.
The principle reason this is not done more often
is that programs that rely on it:
Plot, Findgen(11), Linestyle=!LS.Dash
don't work when they are passed along to someone else.
You always forget to give them your start-up file, or
they got it, but they forget to run it, etc. So most of
us stay with the lowest common denominator code:
Plot, Findgen(11), Linestyle=2
And most of us (present company included) don't have any
idea what that code does five minutes after we write the
program.
And, anyway, making code "readable" is not really the
true programmer's solution anyway. If you want to earn
the big bucks, "cryptic" is better. :-)
If everyone in your workgroup would agree to use the same
IDL startup file, however, this would work great.
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
