| Re: Top 10 IDL Requests [message #20627] |
Tue, 18 July 2000 00:00 |
Ivan Zimine
Messages: 40
Registered: February 1999
|
Member |
|
|
Hello,
Another close to end in top 100 request.
I really like searching in recall buffer (^-text thing).
How difficult would it be to make a recursive search?
I mean by pressing "^" again to go up in the history.
And maybe "^" should be remapped to Ctrl-Something.
Thanks,
Ivan
--
Ivan Zimine | ivan.zimine@physics.unige.ch
Dpt. of Radiology | (+41 22) 372 70 70
Geneva University Hospitals |
|
|
|
|
| Re: Top 10 IDL Requests [message #20628 is a reply to message #20627] |
Tue, 18 July 2000 00:00  |
Theo Brauers
Messages: 58
Registered: November 1997
|
Member |
|
|
Craig's suggestions aregreat and I strongly support them.
And I am still hoping for a way to get a executable out of my
IDL code after compiling without the trouble of setting up a
licensed runtime version for a demo or a student lab.
Theo
Craig Markwardt wrote:
>
> davidf@dfanning.com (David Fanning) writes:
>> ... I think Craig in particular should have a
>> look at the new curve fitting routines.
>
> That sounds great, although I'm pretty attached to my own MPFIT
> functions by now :-)
>
> As for my top ten wish list, you probably will wish I hadn't gotten
> started. Okay here's my list. It's more than ten, so I guess I'm
> already starting to compete with myself. I focus mainly on the basic
> programming elements which need to be improved, rather than the
> feature-level stuff that we can program ourselves.
>
> * Arrays in structures can collapse to scalars? A BUG!
>
> ........................
>
> "print" button right *on it*.
>
> Sorry for the long message, but you asked for it! :-)
>
> Constructively,
> Craig
>
> --
> ------------------------------------------------------------ --------------
> Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
> Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
> ------------------------------------------------------------ --------------
--
----------------------------------------------
Dr. Theo Brauers
Institut fuer Atmosphaerische Chemie (ICG-3)
Forschungszentrum Juelich
52425 JUELICH, Germany
Tel. +49-2461-61-6646 Fax. +49-2461-61-5346
http://www.kfa-juelich.de/icg/icg3/MITARBEITER/th.brauers.ht ml
|
|
|
|
| Re: Top 10 IDL Requests [message #20629 is a reply to message #20627] |
Tue, 18 July 2000 00:00 |
landsman
Messages: 93
Registered: August 1991
|
Member |
|
|
In article <on66q4a433.fsf@cow.physics.wisc.edu>,
craigmnet@cow.physics.wisc.edu wrote:
> * A way to index strings like arrays.
>
> I know we can use STRMID and STRPUT, but it seems that an array-like
> notation would fit so much better with the philosophy of IDL.
>
If I understand you correctly, then this was syntax that IDL used in its
ancient (Version 1) history, e.g. if st was a string array, then
st(3:5,*) extracted the third through fifth characters of all elements
of the array. Of course, this was when IDL was limited to
fixed-length string arrays. With the current variable length string
arrays, things are more complicated but the notation is still feasible.
For example, the first dimension of a string array could be defined to
be the maximum string length in the array.
But I am not sure that such a change would be desirable. First of
all would be the difficulty in making a syntax change backwards
compatible. The change of the string syntax from V1 to V2 probably
required more coding changes than any other syntax change ever made to
IDL. Also, some syntax would become more complicated -- for example, the
current extraction of elements of a string array st1 = st[3:5] would
have to become st1 = st[*,3:5]. V5.3 introduced many string
processing enhancements (e.g. STRMID now accepts vector parameters), so
I think all the functionality of the array notation is now available in
then string processing functions. Finally, one can always index strings
like arrays by first converting them with BYTE().
--Wayne Landsman landsman@mpb.gsfc.nasa.gov
P.S. I heartily endorse a COMPLEMENT keyword to the WHERE function.
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
| Re: Top 10 IDL Requests [message #20630 is a reply to message #20627] |
Tue, 18 July 2000 00:00 |
Harvey Rarback
Messages: 24
Registered: September 1998
|
Junior Member |
|
|
David,
Thanks for taking on the burden of making IDL better.
My request is to give VMS the same status as the other OSes that IDL supports by
eliminating the restriction that the VMS "plain tty" cannot process widget
events, making it impossible to build non-blocking widget applications.
I use both the VMS Development Environment and "plain tty" interface. I am
forced to do kludges like
> help, /key, out=out ; kludge to see if we are running in terminal environment
> cli = strcmp( out[0], '%', 1) eq 0
> defsysv, '!cli', cli, 1 ; /read_only
to be able to determine whether Xmanager returns control to me or not. As an
aside, is there a better way to determine this information?
Related to this problem: in IDL 5.3 the restriction that an object could not be
destroyed in its INIT method first appeared. But if you are building widget
object applications in VMS where the INIT method makes the first call to
Xmanager, you are forced into shenanigans in order to do proper garbage
collection on the object. Could this restriction be removed?
--Harvey
|
|
|
|
| Re: Top 10 IDL Requests [message #20631 is a reply to message #20627] |
Tue, 18 July 2000 00:00 |
wbiagiot
Messages: 59
Registered: January 1999
|
Member |
|
|
Ok, my two cents:
1) Compilation-related comments:
If you leave out an 'END' somewhere in 10000 lines of code, please
don't let the compilation process scroll countless lines of compilation
errors. Second, have a way to skip from error to error without
searching for the little red dot. Third, try really really hard to
improve the informational nature of some of those totally nondescript
error descriptions.
2) Is it at all possible to simply update the color palette and see the
effect w/o redrawing the image (Win95/98). I realize this might be a
Win problem, but it sure would speed up an awful lot of my graphics
routines if it were possible.
3) It's late - more tomorrow!
Thanks,
Bill B.
--
"They don't think it be like it is, but it do."
Oscar Gamble, NY Yankees
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
| Re: Top 10 IDL Requests [message #20632 is a reply to message #20627] |
Tue, 18 July 2000 00:00 |
m-zingale
Messages: 1
Registered: July 2000
|
Junior Member |
|
|
In article <MPG.13db815b76724572989b5b@news.frii.com>, davidf@dfanning.com (David Fanning) wrote:
> One of the people I ran into at the picnic was the
> new VP of Software Engineering. After we were introduced
> and it was pointed out that I was, uh, the person who
> wrote "that book about IDL" the VP gave me his e-mail
> and phone extension and encouraged me to submit my
> top 10 IDL requests to him personally.
>
> Wow! You don't get an opportunity like this every day. :-)
>
> Not wanting to hog the spotlight, however, I thought
> I'd have a little contest and see what the rest of
> you want. I've already reserved the top spot for taking
> the Table Widget out in the field behind RSI and shooting
> it, but I'm open to suggestions after that.
>
1. Multithreading (this was already mentioned, but I wanted to second it)
2. HDF 5 support (with parallel I/O capabilities if the multithreading if
implemented).
Mike Zingale
Department of Astronomy and Astrophysics
University of Chicago
|
|
|
|
|
|
|
|
| Re: Top 10 IDL Requests [message #20636 is a reply to message #20627] |
Mon, 17 July 2000 00:00 |
Brad Gom
Messages: 49
Registered: August 1997
|
Member |
|
|
Craig has hit the nail on the head with many of his suggestions.
There are many changes that could be made to IDL that would be convenient to
some but inconvenient to others. The best changes, however, would be those
that improve IDLs useability to everyone (no matter how small the
improvement).
In particular:
Craig Markwardt wrote:
> * The concept of an empty array (null data type).
> I've mentiond this before. It would avoid special cases for WHERE()
> commands. Also, it would make it much easier to do list processing,
> * Short-hand notation to index arrays from the end.
> It pains me to have to use N_ELEMENTS() to find out the size of an array
before indexing it.
> I've wondered whether we could just be allowed to use "*" in an expression,
> like MATRIX(0:*-1) in place of MATRIX(0:N_ELEMENTS(MATRIX)-2)
> * A way to index strings like arrays.
> I know we can use STRMID and STRPUT, but it seems that an array-like
> notation would fit so much better with the philosophy of IDL.
I think changing these 3 small details would add alot of elegance to IDL, and
would benefit everyone.
Brad Gom
|
|
|
|
|
|
| Re: Top 10 IDL Requests [message #20638 is a reply to message #20637] |
Mon, 17 July 2000 00:00 |
Dennis Boccippio
Messages: 23
Registered: July 2000
|
Junior Member |
|
|
In article <gurman-BA14CE.16384117072000@news.gsfc.nasa.gov>, "Joseph
B. Gurman" <gurman@gsfc.nasa.gov> wrote:
> 2. support for QuickTime video at least as an output option (e.g.
> WRITE_QT), even if this means paying an additional license fee for
> various CODECs.
>
Hear, hear. The Animation codec would be pretty straightforward, seems
appropriate for the type of output likely to be made in IDL, is
supported on Mac/Windows/UNIX, and can be set lossless so the resulting
clip could always be recompressed using a different codec (using, e.g.,
MediaCleaner) ... seems like it would be a natural...
- DJB
|
|
|
|
|
|
| Re: Top 10 IDL Requests [message #20642 is a reply to message #20640] |
Mon, 17 July 2000 00:00 |
Kenneth Mankoff
Messages: 42
Registered: August 1999
|
Member |
|
|
here is my christmas-in-july wishlist for IDL improvements:
1. Multiple z-buffers, accessible by logical unit numbers
2. c++ style increment operators
this does not need to cover ++i necessarily, but i would
really like to be able to use i++.
thanks,
ken.
|
|
|
|
| Re: Top 10 IDL Requests [message #20643 is a reply to message #20642] |
Mon, 17 July 2000 00:00 |
Joseph B. Gurman
Messages: 31
Registered: April 2000
|
Member |
|
|
In article <MPG.13db815b76724572989b5b@news.frii.com>,
davidf@dfanning.com (David Fanning) wrote:
> Hi Folks,
>
> [snip]
>
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
Dave -
Thanks so much for the "RFC." If I had my druthers, I would ask for:
1. support for interlaced GIFs via a keyword to WRITE_GIF (how hard can
this be?), and
2. support for QuickTime video at least as an output option (e.g.
WRITE_QT), even if this means paying an additional license fee for
various CODECs.
The programming support functions people have been listing as their
druthers, and expanded object programming really mean very little to
those of us who produce lots of Web content. I suspect this is a much
bigger area nowadays than object programming, and would in fact be
thrilled to see a rebundled product:
3. with NO object interfaces, since it's scientists who are doing a lot
of the programming, and I can't see why we're paying for features we
never use (however gnarly).
Please send flames and explanations of why the gnarliness is useful
to /dev/null.
Best,
Joe Gurman
>
> Please restrict yourself to a paragraph or so
> about why you think your suggestion is a good
> idea. Suggestions can either be fixes to something
> currently in IDL, or requests for future capabilities.
> Items that make it to the top of the list
> will be written with some wit, intelligence,
> and humor. Items at the bottom of the list
> will be written with a lot of whining. I reserve
> the right to edit submissions if I think it is
> unintelligible to the average computer dolt.
--
| Joseph B. Gurman, NASA Goddard Space Flight Center, Solar Physics
| Branch, Greenbelt MD 20771 USA / Federal employees are still
| prohibited from holding opinions while at work. Therefore, any
| opinions expressed herein are somebody else's.
|
|
|
|
| Re: Top 10 IDL Requests [message #20644 is a reply to message #20643] |
Mon, 17 July 2000 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> ... I think Craig in particular should have a
> look at the new curve fitting routines.
That sounds great, although I'm pretty attached to my own MPFIT
functions by now :-)
As for my top ten wish list, you probably will wish I hadn't gotten
started. Okay here's my list. It's more than ten, so I guess I'm
already starting to compete with myself. I focus mainly on the basic
programming elements which need to be improved, rather than the
feature-level stuff that we can program ourselves.
* Arrays in structures can collapse to scalars? A BUG!
This is a problem for structures declared like this:
X = {VAL: REFORM(DBLARR(1,1),1,1)}
Whenever you try to extract VAL, it will come out as a scalar! This
is clearly a language bug that must be fixed. J.D. will disagree
but that doesn't make him more right. :-)
* The concept of an empty array (null data type).
I've mentiond this before. It would avoid special cases for WHERE()
commands. Also, it would make it much easier to do list processing,
such as extraction and concatenation. Ah, Patrick Broos has the
same idea. Like he says, we couldn't get along without the empty
string. So why do we not have the empty array?
* The ability for WHERE to return the *complement* of the selection
simultaneously. I do this fairly occasionally:
WH1 = WHERE(X GT 0, CT1)
WH2 = WHERE(X LE 0, CT2)
Which involves two comparisons instead of one. This can be a big
hit with large arrays. The syntax could be like this:
WH1 = WHERE(X GT 0, CT1, COMPLEMENT=WH2, CT2)
* Short-hand notation to index arrays from the end.
It pains me to have to use N_ELEMENTS() to find out the size of an
array before indexing it. It's even more difficult for a
multi-dimensional array. Shouldn't the array itself know how big it
is?
I've wondered whether we could just be allowed to use "*" in an
expression, like MATRIX(0:*-1) in place of
MATRIX(0:N_ELEMENTS(MATRIX)-2), but this has problems if
multiplication is used.
* Optional strict array sizing.
A simple keyword -- such as STRICT -- to all of the array
constructors to prevent them from automatically dropping any
trailing dimensions of size 1. Please! I know what size my arrays
should be. Don't work against me here. I would much prefer to do
this:
X = DBLARR(NX, NY, NZ, /STRICT)
rather than this:
X = REFORM(DBLARR(NX, NY, NZ), NX, NY, NZ, /OVERWRITE)
* Consistent behavior for REFORM, REBIN, TOTAL and TRANSPOSE.
Make sure that REFORM, REBIN and TOTAL work the same way on scalars
and arrays. For example, why doesn't REFORM(1,[1,1]) work? Yes,
sometimes I *do* need a 1-element, multi-dimensional, array.
Also, a convention for passing dimensions to these routines should
be codified and enforced. For example, REBIN(ARRAY, [2,3]) does not
work, but REFORM(ARRAY, [2,3]) does. Can that make sense?
* Consistent ways to compile procedures and functions.
There should be programmatic ways to compile procedures and
functions. RESOLVE_ROUTINE helps, but for example it only compiles
procedures in the IDL path. There is no way to explicitly designate
the path to the code, which is especially vexing if your code is in
a scratch area.
By the same token, it should be possible to compile an entire
procedure from memory (as opposed to from disk).
* A way to index strings like arrays.
I know we can use STRMID and STRPUT, but it seems that an array-like
notation would fit so much better with the philosophy of IDL.
* A way to construct procedures which accept a variable number of
parameters.
The particular context I'm talking about here is some kind of
wrapper procedure, which in turn calls another procedure. You end
up writing something like this, which seems foolishly redudant and
artificially limiting:
CASE N_ARGS OF
0: CALL_PROCEDURE, PROC
1: CALL_PROCEDURE, PROC, ARGS.(0)
2: CALL_PROCEDURE, PROC, ARGS.(0), ARGS.(1)
3: CALL_PROCEDURE, PROC, ARGS.(0), ARGS.(1), ARGS.(2)
ENDCASE
* A way to selectively pass a few keywords via the _EXTRA mechanism.
The _EXTRA mechanism for keyword passing is great. However, it is
most useful when you are passing arguments to *one* *single*
internal function. There are times when I have several internally
called functions which may accept different keywords. A way to
filter keywords would be convenient.
* A way to do one-click printing under Unix.
My solution was XFWINDOW. It's a hack, nobody on the net seems to
like it, but I use it every day. I hate using SET_PLOT and DEVICE,
and I always get it wrong. A direct graphics window should have a
"print" button right *on it*.
Sorry for the long message, but you asked for it! :-)
Constructively,
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Top 10 IDL Requests [message #20645 is a reply to message #20644] |
Mon, 17 July 2000 00:00 |
Phillip David
Messages: 36
Registered: April 1999
|
Member |
|
|
David;
My request: Full support for object visibility, and support for class
data and methods. This includes the ability to make methods private and
data public. I've had data structures that I'd like to implement, but
have been unable to really properly implement without either making a
method private, or without having access to class data (i.e., there's
just one instance of the data, and it's visible to all objects of that
type). The particular example is the Singleton pattern from the book
"Design Patterns", by the "Gang of Four". This is a great first book on
OO programming methodology, and this pattern has proven very valuable to
me. I think IDL programmers would benefit from this type of support,
although I grant that it's one of those "under-the-hood" types of
changes that's not likely to get a lot of recognition from marketing
types.
Phillip
David Fanning wrote:
>
> Hi Folks,
>
> I was teaching an IDL course at RSI this past week
> and had the opportunity to do a bit of intelligence
> work on behalf of this newsgroup at the annual RSI
> picnic on Thursday. Besides the usual volleyball and
> Frisbee, some of us sat around and talked shop. Sigh...
>
> I'll get a life later, but I thought you might like to
> know the IDL 5.4 beta is do to go out in the next week
> or so and they are signing up testers. If you would
> like to participate, you can contact the IDL beta program
> at idl_beta@rsinc.com.
>
> I would especially encourage those of you who want
> more math functionality in IDL to do so, because
> that seems to be one of the themes of this release.
> Apparently the new math guy they hired recently has
> been busy. I think Craig in particular should have a
> look at the new curve fitting routines.
>
> There are other things that should warm the heart of
> any regular IDL newsgroup reader. For example, a
> completely rewritten SPAWN command for Windows will
> be warmly embraced. Not only can you now get the results
> of the spawned command back (the way you have always been
> able to in UNIX), but you can also use the NOSHELL keyword
> to avoid the ugly DOS window popping up all the time.
> And J.D. will appreciate the new relaxed structure rules
> that will allow anonymous structures (with similar fields)
> to be concatenated.
>
> And, as often happens, the biggest changes under the
> hood get short--shrift in the marketing hype. But the
> fact that the Windows version of IDL now supports
> LARGE data files meant a four-month effort to work-around
> Microsoft's very restricted I/O layer. But this will be
> a godsend for those of you working with those 40 GByte
> image files. :-)
>
> One of the people I ran into at the picnic was the
> new VP of Software Engineering. After we were introduced
> and it was pointed out that I was, uh, the person who
> wrote "that book about IDL" the VP gave me his e-mail
> and phone extension and encouraged me to submit my
> top 10 IDL requests to him personally.
>
> Wow! You don't get an opportunity like this every day. :-)
>
> Not wanting to hog the spotlight, however, I thought
> I'd have a little contest and see what the rest of
> you want. I've already reserved the top spot for taking
> the Table Widget out in the field behind RSI and shooting
> it, but I'm open to suggestions after that.
>
> I do feel strongly that the TV command could be made
> a whole lot smarter. I find I can't even use it
> anymore if I want to write device/version/decomposed_state
> independent code. Certainly you can use my TVIMAGE or
> Liam's IMDISP program, but shouldn't something as
> simple as this be built into IDL? And please, God,
> don't EVER take my 24-bit image though a color table,
> no matter what silly thing I've done to the color
> decomposition state. :-(
>
> (One thing that seems obvious from reading the list
> of new features in IDL 5.4 is that in today's
> employment marketplace it is futile to assign good
> engineers to fixing old technology. They will just
> go down the street and work for someone else doing
> something a whole lot sexier for twice as much money.
> It's reality I guess, but it seems a shame too.
> RSI is certainly not the only software company
> suffering from the current state of affairs.)
>
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
>
> Please restrict yourself to a paragraph or so
> about why you think your suggestion is a good
> idea. Suggestions can either be fixes to something
> currently in IDL, or requests for future capabilities.
> Items that make it to the top of the list
> will be written with some wit, intelligence,
> and humor. Items at the bottom of the list
> will be written with a lot of whining. I reserve
> the right to edit submissions if I think it is
> unintelligible to the average computer dolt.
>
> That's it! No prizes or anything. Just a chance
> to be heard by someone who can maybe make a
> difference. In today's world, that's about all
> we can ask. :-)
>
> 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: Top 10 IDL Requests [message #20649 is a reply to message #20647] |
Mon, 17 July 2000 00:00 |
Nicolas Decoster
Messages: 34
Registered: March 2000
|
Member |
|
|
Hi.
Here are few thoughts/wishes I had while writing IDL code.
* A very interesting thing for beginners and for code clarity is to
replace the use of integer values by strings for arguments like
line_style of object graphics (like IDLgrPlot). As suggested by Patrick
Broos, it would be nice too to be able to use named colors ("red").
* Postscript output of object graphics. This was the main subject of my
"newsgroup activity", and I think efforts can be done to have some
improvments. In particular, I think about the postscript order of
objects that is different than the object graphics tree one. But perhaps
this point is fix in IDL 5.4 ?
* On line object/named-structures development. With IDL 5.3 you can't
change a named structure on the fly. When you work on a new object
graphic or any object or structure, if you add or remove a field you
must exit/re-enter IDL for the modification to be effective. It is a bit
painfull, and you loose the interest of the use of a scripting language.
* The best thing that can happened to IDL, is to open its source. But,
well, perhaps RSI prefers other development models. I must be a little
bit idealistic.
Thanks.
Nicolas.
--
T�l. : 00 (33) 5 62 88 11 16
Fax : 00 (33) 5 62 88 11 12
Nicolas.Decoster@Noveltis.fr
Noveltis
Parc Technologique du Canal
2, avenue de l'Europe
31520 Ramonville Saint Agne - France
|
|
|
|
| Re: Top 10 IDL Requests [message #20650 is a reply to message #20649] |
Mon, 17 July 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Andrew wrote:
>
> In article <39731270.99C6E4C6@ssec.wisc.edu>,
> "Liam E.Gumley" <Liam.Gumley@ssec.wisc.edu> wrote:
>> Andrew,
>>
>> TrueType fonts scale and rotate correctly in 3D, e.g.
>>
>> set_plot, 'PS'
>> device, set_font='Times Italic', /tt_font, file='surface.ps'
>> surface, dist(256), xtitle='X Axis', ytitle='Y Axis', font=1
>> device, /close
>
> Thx. for the info. Someone else pointed this out to me via
> email as well. QUESTION. Do TrueType fonts work on *nix? If not
> then I leave my request for David to consider. And since we all know
> how much David loves *nix, I'm sure it will get top billing ;-)
TrueType fonts are supported on all IDL platforms, including UNIX.
> Do you know how the TT fonts are embedded in the PS file? If
> my axis label is "Badgers" can I find the string "Badgers" in the PS
> file?
I don't know how they are respresented in the PostScript file. However I
suspect it might be a bitmap....
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Top 10 IDL Requests [message #20651 is a reply to message #20650] |
Mon, 17 July 2000 00:00 |
landsman
Messages: 93
Registered: August 1991
|
Member |
|
|
Here are my wishes for math updates in IDL:
1. My longtime wish is to update the "Numerical Recipes" which call a
user-specified function (e.g. QROMB, LMFIT) and currently require the
user function to accept a scalar argument and return a scalar value.
This goes against the spirit of IDL and makes the routines unacceptably
slow for most real-life applications. (I wonder if it is a problem
with the licensing agreement with Numerical Recipes that prevents
modifying the routines to make them more IDL compatible.)
2. Median filtering is a non-linear operation which cannot be easily
vectorized, so I would like to see more capabilities in the MEDIAN
function:
1. Allow separate specification of the X and Y filter size (e.g. im1 =
median(im,[15,3]), which would be useful, for example, in removing bad
columns. 2. For 2 or 3 dimenional images, allow MEDIAN to work over a
specified dimension, e.g. for removing cosmic rays from a stack of images in
a 3 dimensional array. (This capability would also be useful in MIN and
MAX.) 3. Allow the user to specify a "kernel" (as with CONVOL) specifying
weights to be assigned to pixels within the filter size. One such
application of a such a generalized median is described at
http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1995 PASP..107..496S&d
b_key=AST&high=38aaedbba709215
--Wayne Landsman landsman@mpb.gsfc.nasa.gov
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
| Re: Top 10 IDL Requests [message #20652 is a reply to message #20651] |
Mon, 17 July 2000 00:00 |
Patrick Broos
Messages: 27
Registered: December 1996
|
Junior Member |
|
|
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
David,
Thanks for working to improve IDL on behalf of the user community. I
don't have
any humorous thoughts this morning, but here are some ideas that you
might consider.
* Like you, I have spent a lot of effort working around IDL's very
primitive handling
of color. I eventually developed an environment for my own applications
(as you have)
that allows 8 & 24 bit color, X and PostScript devices, user-defined
color tables, and
named colors (e.g. "red"). For the beginning user however there is a
tremendous
learning curve to do something like, say, tvscl an image user a
specified color table,
draw a "blue" box on it (where blue is not in the given color table),
and print it out
in color PostScript. Surely more of this could be available "out of the
box".
* Similarly, it takes a great deal of reading and effort to mix images
and plot axes.
Yes, you've done it, I've done it, and many folks have done it, but it
remains a
significant obstacle for new users.
* It would be nice if RSI better supported the administration of IDL at
a user site
(as opposed to single-user installations). For example, it would be
convenient if
the IDL administrator had a convenient way to supply IDL_PATH and
IDL_STARTUP
values to all users, while retaining the user's ability to supply
additional path and
startup information. I wrote a script to do this
(http://www.astro.psu.edu/users/patb/psu_idl)
but RSI could support this problem more directly.
* As I've ranted and raved before, I still think RANDOMN() and RANDOMU()
have
such a checkered history of bugs and very poor semantics that they
should be
retired and replaced with a new routine of better design.
* A lot of code could be streamlined if IDL widely supported the concept
of a zero-length
array (distinguished from an undefined variable). Think how useful the
concept of
the null string is in string processing.
Thanks,
Pat
============================================================ ========
Patrick S. Broos, Systems Analyst/Programmer patb@astro.psu.edu
Department of Astronomy and Astrophysics My office 814-863-7947
Penn State University
525 Davey Lab FAX 814-863-8686
University Park, PA 16802-6305
http://www.astro.psu.edu Group office 863-9550
============================================================ ========
|
|
|
|
| Re: Top 10 IDL Requests [message #20653 is a reply to message #20652] |
Mon, 17 July 2000 00:00 |
noymer
Messages: 65
Registered: June 1999
|
Member |
|
|
In article <39731270.99C6E4C6@ssec.wisc.edu>,
"Liam E.Gumley" <Liam.Gumley@ssec.wisc.edu> wrote:
> Andrew,
>
> TrueType fonts scale and rotate correctly in 3D, e.g.
>
> set_plot, 'PS'
> device, set_font='Times Italic', /tt_font, file='surface.ps'
> surface, dist(256), xtitle='X Axis', ytitle='Y Axis', font=1
> device, /close
Liam,
Thx. for the info. Someone else pointed this out to me via
email as well. QUESTION. Do TrueType fonts work on *nix? If not
then I leave my request for David to consider. And since we all know
how much David loves *nix, I'm sure it will get top billing ;-)
Do you know how the TT fonts are embedded in the PS file? If
my axis label is "Badgers" can I find the string "Badgers" in the PS
file?
- Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
| Re: Top 10 IDL Requests [message #20654 is a reply to message #20653] |
Mon, 17 July 2000 00:00 |
Struan Gray
Messages: 178
Registered: December 1995
|
Senior Member |
|
|
David Fanning, davidf@dfanning.com writes:
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
Memory management. The ability to ask how much memory is left
without trying to allocate it would make application development much,
much easier, particularly for those of us working on PC-class
machines. At present we either have to allocate a big array (chug,
chug, chug,.... 10 min wait..., chug, chug, sorry!) or just allow the
program to crash randomly. I use one commercial IDL application which
continually saves everything to disk just to be sure it won't crash,
which is a horrible waste of SIMMS.
> Items that make it to the top of the list
> will be written with some wit, intelligence,
> and humor.
Take my wife. Please.
Struan
|
|
|
|
| Re: Top 10 IDL Requests [message #20655 is a reply to message #20654] |
Mon, 17 July 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Benno Puetz wrote:
> Of the top of my head:
>
> Color support in PS output (for PLOT and the like).
>
> I haven't counted the hours spent editing those files manually...
As far as I know, the only restriction on the 'PS' device is that you
can't specify decomposed 24-bit colors (24-bit *images* can be displayed
however). Even this restriction can be side-stepped by using the
'PRINTER' device (which supports decomposed color) and selecting a
PostScript color printer.
Can you give us an example where IDL is not providing the color support
you require?
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Top 10 IDL Requests [message #20656 is a reply to message #20655] |
Mon, 17 July 2000 00:00 |
Liam E. Gumley
Messages: 378
Registered: January 2000
|
Senior Member |
|
|
Andrew wrote:
> I use direct graphics, and for reasons that seem obvious to me, I use
> PostScript fonts in my output. This makes life a lot easier in many
> ways, and I can even embed LaTeX commands in my output (parsed via
> psfrag).
>
> Now, as you know, IDL barfs on PS fonts in 3D. IDL's vector fonts can
> be fed through the XYZ coordinare transformation, and, bada-bing, you've
> got your 3D axes labeled. Not so with PS fonts.
>
> My understanding from the PS red book and elsewhere is that life does
> not have to be this way. I may be mistaken, but I think with a little
> brainwork (not my strong suit) PostScript fonts can also be rotated and
> transformed in 3D-space-mapped-to-2D. I mean you know where the heck
> the axes are drawn, right? You know this once they are drawn, maybe not
> before. And PS fonts can be rotated 360-degreess, and of course
> translated horizonatally and vertically wherever you want. So why can't
> IDL label the axes of a 3D graph with PS fonts? Draw the axes and then
> label them, rather than draw them and label them at the same time.
>
> Using vector fonts for 3D and PS fonts for 2D is annoying. Using vector
> fonts for everything is more annoying.
>
> My humble request: FULL SUPPORT for PS fonts in IDL direct graphics,
> including 3D.
Andrew,
TrueType fonts scale and rotate correctly in 3D, e.g.
set_plot, 'PS'
device, set_font='Times Italic', /tt_font, file='surface.ps'
surface, dist(256), xtitle='X Axis', ytitle='Y Axis', font=1
device, /close
Cheers,
Liam.
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
|
|
| Re: Top 10 IDL Requests [message #20659 is a reply to message #20657] |
Mon, 17 July 2000 00:00 |
Ben Tupper
Messages: 186
Registered: August 1999
|
Senior Member |
|
|
>
Hello,
These probably wouldn't (shouldn't) belong in the top ten... but I
suspect that any VP of Software Engineering would like to know about all
of the suggestions that didn't make the top-ten.
(1) Since there are about as many NoXXXX as there are No_XXXX keywords
for the built in routines, how about
making it possible to use either one form or the other. That
is so that No_Edit = NoEdit
(2) Do the same thing for Gray and Grey.
Thanks,
Ben
--
Ben Tupper
Bigelow Laboratory for Ocean Science
tupper@seadas.bigelow.org
pemaquidriver@tidewater.net
|
|
|
|
| Re: Top 10 IDL Requests [message #20660 is a reply to message #20659] |
Mon, 17 July 2000 00:00 |
David Bowman
Messages: 10
Registered: July 2000
|
Junior Member |
|
|
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
What an amazingly welcome opportunity to air petty grievances! Many
heartfelt thanks both to you and the anonymous VP...
I must admit that I am not a code-god like some of the frequent posters
to this newsgroup. :-) As a mere computational mortal, I frequent the
IDL Online Help facility, and I heartily believe that this help
facility is one of IDL's strongest and most oft-neglected points. (It
certainly beats the Hades out of Matlab!) However... call me a
stick-in-the-mud, but I would like to make a heartfelt request to have
the old (pre 5.3) Help back. At the very least, please bring back the
old "Routines by Application" section. And it would also be nice if
typing the name of a command in the "Keyword:" field would
preferentially bring up the page describing the actual routine, rather
than the somewhat obscure pages that in fact appear. For instance, try
typing "plots" as the keyword. You are lead not to a description of
the PLOTS procedure but rather to a general discourse on object
graphics. Not useful to a mere lubber like myself.
Thanks for representing the views of the community!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=
David Bowman "Smash forehead on keyboard to continue."
Laboratoire Tectonique
Institut de Physique du Globe - Paris
4 Place Jussieu
75252 Paris Cedex 05
France
|
|
|
|
| Re: Top 10 IDL Requests [message #20661 is a reply to message #20660] |
Mon, 17 July 2000 00:00 |
Benno Puetz
Messages: 16
Registered: March 2000
|
Junior Member |
|
|
Of the top of my head:
Color support in PS output (for PLOT and the like).
I haven't counted the hours spent editing those files manually...
--
Benno Puetz
Kernspintomographie
Max-Planck-Institut f. Psychiatrie Tel.: +49-89-30622-413
Kraepelinstr. 10 Fax : +49-89-30622-520
80804 Muenchen, Germany
|
|
|
|
|
|
| Re: Top 10 IDL Requests [message #20664 is a reply to message #20662] |
Sun, 16 July 2000 00:00 |
Dennis Boccippio
Messages: 23
Registered: July 2000
|
Junior Member |
|
|
In article <MPG.13db815b76724572989b5b@news.frii.com>,
davidf@dfanning.com (David Fanning) wrote:
> Hi Folks,
>
> I was teaching an IDL course at RSI this past week
> <snip>...
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
>
I'll definitely toss a couple in. And I second the vote for putting the
table widget out of its misery.
- Work on improving / optimizing the speed of IDL objects and related
outgrowths - these seem amazingly flexible, but so many object-driven
widgets or apps seem unacceptably sluggish. I'd be more inclined to
delve into object-driven code if I could be assured the end result
would be more responsive than some of the object graphics, e.g.
- Adding some basic neural network algorithms to the stock procedures
(I'm interested from a category classification standpoint, and IDL's
flexibility at I/O and workability with large datasets seems to make it
well suited for handling the large training/validation sets needed to
drive nn's, as well as the visualization needed to tune them
(As an aside, is anyone aware of any 3rd party nn implementations for
IDL?)
- This is very picayune, and major strides have been made, but RSI needs
to finish the job on HDF VDATAs. The browser and interface routines
currently can't handle mixed-data-type vdatas, which for us results
in an awful lot of unpack-the-byte-array code that needs to be written.
We only use HDF for large datasets, where the overhead seems justified,
and for these it makes alot of sense to use the minimum necessary data
type for each vdata "column". Perhaps RSI's ties to Fortner (Noesys)
could get them access to the necessary underlying code?
- Indirectly IDL: Add a WHERE node to VIP, and somehow make loops more
visually distinctive
- Not a development issue, but perhaps lower the price on runtime
licensing...
- Dennis
|
|
|
|
| Re: Top 10 IDL Requests [message #20665 is a reply to message #20664] |
Sun, 16 July 2000 00:00 |
noymer
Messages: 65
Registered: June 1999
|
Member |
|
|
OK, David, you asked for it. Here goes.
This may *seem* like a small thing, but the small stuff matters, right?
I use direct graphics, and for reasons that seem obvious to me, I use
PostScript fonts in my output. This makes life a lot easier in many
ways, and I can even embed LaTeX commands in my output (parsed via
psfrag).
Now, as you know, IDL barfs on PS fonts in 3D. IDL's vector fonts can
be fed through the XYZ coordinare transformation, and, bada-bing, you've
got your 3D axes labeled. Not so with PS fonts.
My understanding from the PS red book and elsewhere is that life does
not have to be this way. I may be mistaken, but I think with a little
brainwork (not my strong suit) PostScript fonts can also be rotated and
transformed in 3D-space-mapped-to-2D. I mean you know where the heck
the axes are drawn, right? You know this once they are drawn, maybe not
before. And PS fonts can be rotated 360-degreess, and of course
translated horizonatally and vertically wherever you want. So why can't
IDL label the axes of a 3D graph with PS fonts? Draw the axes and then
label them, rather than draw them and label them at the same time.
Using vector fonts for 3D and PS fonts for 2D is annoying. Using vector
fonts for everything is more annoying.
My humble request: FULL SUPPORT for PS fonts in IDL direct graphics,
including 3D.
What do folks think? Am I the only one for whom this has been a burr
under the saddle?
- Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
|
|
|
|
| Re: Top 10 IDL Requests [message #20718 is a reply to message #20644] |
Tue, 18 July 2000 00:00 |
wmc
Messages: 117
Registered: February 1995
|
Senior Member |
|
|
Craig Markwardt <craigmnet@cow.physics.wisc.edu> wrote:
> * The concept of an empty array (null data type).
Seconded. Perhaps they could read some of the perl manual...
> * The ability for WHERE to return the *complement* of the selection
> simultaneously.
Nice idea
> * Short-hand notation to index arrays from the end.
> ...expression, like MATRIX(0:*-1) in place of
yeh
-W.
(still no wit)
--
William M Connolley | wmc@bas.ac.uk | http://www.nerc-bas.ac.uk/icd/wmc/
Climate Modeller, British Antarctic Survey | Disclaimer: I speak for myself
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
