Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
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
Craig Markwardt wrote: > > "richard hilton" <rdh5@dmu.ac.uk> writes: > >> How about an equivalent of the C-commands CONTINUE and BREAK to control >> loops. This would be more elegant than the "GOTO....label" that exists at >> the moment. Maybe I'm being pedantic but this seems an obvious change. > > I like this suggestion a lot! > > Oooh, I just thought of something. This may cause name conflicts. > People who use CONTINUE or BREAK as variable names would not be happy > if the language suddenly changed. Still, I would highly prize these > constructs if they could be implemented discretely. How about implementing this with another argument to COMPILE_OPT? BTW, I love the behavior of COMPILE_OPT IDL2 and use it in all my new code. No more putting those dumb "L's" after all my integer constants. --Harvey
I'd agree with a way to get 'at home' licenses. I can't connect with the license server at work because it's not available over the internet (it's on a separate, classified network). H C Pumphrey wrote: > (2) Free or cheap 'at home' licenses for people who use IDL at work. I'm > gradually abandoning IDL because my boss won't cough up UKP 1000 or so > for me to have IDL on my home machine
"richard hilton" <rdh5@dmu.ac.uk> writes: > How about an equivalent of the C-commands CONTINUE and BREAK to control > loops. This would be more elegant than the "GOTO....label" that exists at > the moment. Maybe I'm being pedantic but this seems an obvious change. I like this suggestion a lot! Oooh, I just thought of something. This may cause name conflicts. People who use CONTINUE or BREAK as variable names would not be happy if the language suddenly changed. Still, I would highly prize these constructs if they could be implemented discretely. Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
landsman@my-deja.com writes: > 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. >> > ...deletia... > > 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(). I agree that standard array indexing syntax wouldn't mix too well with accessing strings. On the other hand we do already have the X.(SUBSCRIPT) notation for structures, which could perhaps be adapted for strings as well. IDL> value = '0123456789' IDL> value.(4:5) = '--' ;; pre-beta! IDL> print, value 0123--6789 This is intuitive to me at some level. You use the "." notation to get at the internals of a structure. The same notation could get at the internals of a string. For that matter, it would be nice, but probably hard to implement, to be able to use range and "*" notation for structures in the same way. Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
Thanks for the initiative David, and People, cool down your jets! This thread is insane. Christmas is too far ahead yet, and not even Santa will be able to fullfil a third of our requests. This way, you'll kill David's desire to help out, and that poor VP will not ever again offer to read suggestions. We all want improvements in our own particular way, but I'd rather see one change made to IDL in a new release, than have a comprehensive list of wishes sent to RSI, which will never implement them all. Cheers, Pavel
"Kenneth P. Bowman" wrote: > > In article <3972CF0F.142752CD@mpipsykl.mpg.de>, Benno Puetz > <puetz@mpipsykl.mpg.de> wrote: > >> Color support in PS output (for PLOT and the like). > > I wholeheartedly second that one. > > Liam suggests using the "Printer" device, but that is YATTFO (Yet > Another Thing To Figure Out). "Real" 24-bit color in the PS device is > simply the right thing to do. :-) If decomposed color can be supported on color PostScript printers via the PRINTER device, then one suspects it should be possible to support decomposed color directly with the PS device. > Since Adobe is moving to PDF as the Illustrator filetype, how about > direct to PDF? I'd settle for encapsulated PostScript output with a decent preview image that could be imported into Word. Cheers, Liam.
Has anyone else noticed that despite David's assurance that no hip programmer would be seen dead fixing old code, that's exactly what all of us want RSI to do? They probably hope we're all locked into legacy code In my group at least one of the major reasons people haven't been persuaded to buy IDL has been the need to learn a whole new bag of workarounds. Reliable, predictable keyword use and mathematical accuracy may not be sexy, but it's something people actually want. Looking at the Matlab evil empire (Boo Hiss) and my favourite quality graphing program (Igor) one other thing IDL doesn't offer is easy interfacing to data aquisition hardware or the web. For sophisticated control you need to get your hands dirty with C++ or ION$$$$, but it's amazing how much can be achieved with a few simple vendor-provided hooks for text or raw binary io. We just interfaced an old VME crate to Igor on the Mac using strings dumped into text files and Personal Web Sharing. Took a morning, and most of that was reading the VME ethernet card manual. Struan
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. :-) > > > Cheers, > > David Try to keep it short for there are sooo many wishes (BTW: what does this tell us?) (1) multithreading (2) complement keyword to where (3) end of array syntax (I can't see why A should not be feasible) (4) working contour routine and map projections (simple example: IDL> map_set,limit=[-60,-180,60,360] IDL> map_continents should give America twice, I think ... (4a) ... and more sophisticated map labels, e.g. 60 (degreesymbol) N instead of just 60 as an option. (5) improved color handling for TV and TVRD (6) adapt a colorbar and a legend procedure (e.g. from the ESRG library). This is something basic enough that it should be maintained by RSI - even though everyone will be free to use something different (7) an "IN" operator, e.g. selected = where(species in ['Ozone', 'NOx', 'CO']) (8) higher level graphic objects, e.g. extending your XPLOT, **and** a contour object and map support! The high level plot object should allow things like: XPlot = obj_new('Xplot',x=x,y=sin(x)) ; generate and show object XPlot->Add,x=x2,y=cos(x2) ; add another data set XPlot->SetProperty,curve=2,psym=8,line=2 ; modify properties of second curve etc. Since I start dreaming again, I better stop here. Cheers (from wonderful but cloudy Germnay), 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 [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
HTML help? Ickkk... On the subject of help, I was reading one of the paper manuals (don't recall which one) a few weeks ago (it's just not the same taking a computer to "the reading room") and stumbled across a line that almost made me fall off "the chair". It said (paraphrasing since I can't find the original page, and, remember this is the PAPER copy of the documentation) "click here for more information about 'x'". Someone else somewhere else mentioned that they thought the RT license should be cheaper... Let me add another "business practices" issue to the top 10. If RSI wants to gain inroads into big (or little) business, they should _GIVE AWAY_ the student edition (some would say that $79 is "giving it away" but I would (obviously) disagree). Oh yeah, keep it up to date, the web site says the current version is based on 5.0, why isn't the current SV based on 5.3? My (as an IDL novice) number 1 issue would be to "clean up the syntax". Some specific suggestions (I "grew up" using FORTRAN and VMS if that helps explain my position at all) - get rid of the comma that immediately follows a command - it ain't intutitive that /argument is equivalent to argument=1, I prefer the latter. I'm sure people who have been around IDL longer than I have probably have more things they dislike about the syntax... I guess that's enough for now... wmc@bas.ac.uk wrote: > > Luis Alonso <luis.alonso@uv.es> wrote: >> I use IDL's help every day. > >>> IDL Online Help facility, and I heartily believe that this help >>> facility is one of IDL's strongest and most oft-neglected points. > > !?! One of my requests would be to throw away the current help system > and provide an html-based version. > > The other big request would be to make "contour" work properly > so that /cell_fill is unnecessary. I mean, in this day and age... > > -W. > > ps - sorry 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
Why think small? IDL should have a true WYSIWYG for graphics. Something that allows me to click on an axis displayed on the screen and change the range, font size, etc. Then let me click on the graphic, copy it, and paste it into another application. This would make the preparation of presentations and reports with IDL graphics 100% easier. Sure PostScript produces beautiful printed output but most of the graphics I need are written to the screen, either directly or through another application program. If EXCEL, PSI Plot, Dplot, etc., can do it, why can't IDL. And Dplot is free, not $1700 or so. Larry
My two bits would be increased performance for Object graphics especially volume objects which do not make use of any OpenGL hardware acceleration so volume rendering speeds are quite slow even on multi CPU machines. This would greatly help in developing medical imaging apps where volume rendering MRI/CT data sets is becoming quite common. Rich
anne martel <anne.martel@nottingham.ac.uk> wrote in message news:39745A3A.CECAC2FA@nottingham.ac.ukqqq... > My main request is for the ability to make polygon objects transparent. > Someone posted a request for information on how to do this a short while > ago but I don't think anyone responded so I'm assuming that it's not > possible at the moment (unless you uses volume rendering which is too > slow). If you texture map a RGB+alpha IDLgrImage object into the polygon object, you can gain transparency assuming you set the alpha channel low enough and the appropriate blend function (I use [3,4]) to IDLgrImage.
My main request is for the ability to make polygon objects transparent. Someone posted a request for information on how to do this a short while ago but I don't think anyone responded so I'm assuming that it's not possible at the moment (unless you uses volume rendering which is too slow). I would also like to vote for fixing the bug that turns single element arrays into scalars. Anne Martel Dept Medical Physics QMC, Nottingham http://www.nottingham.ac.uk/radiology
Luis Alonso <luis.alonso@uv.es> wrote: > I use IDL's help every day. >> IDL Online Help facility, and I heartily believe that this help >> facility is one of IDL's strongest and most oft-neglected points. !?! One of my requests would be to throw away the current help system and provide an html-based version. The other big request would be to make "contour" work properly so that /cell_fill is unnecessary. I mean, in this day and age... -W. ps - sorry 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
Here we go! I use IDL's help every day. It's annoying trying to find commands or operators and finding no reference to them or just a single sentence, most of the time very cryptic. I'm still working with IDL5.0 so maybe some things have already changed, but i thing it'd pay to rewrite most of the help from scratch in a more compreensible way. And with FULL examples using at least the main Keywords of each procedure/fuction. As everybody knows after using IDL a couple of hours keywords 'make the difference', but funny that the help one obtains about them is practically unexistent. So, that's one of my needs. I'll read the rest of the proposals, and see if i have something to add ;) This is a great opportunity!!!!! "David Bowman" <bowman@ipgp.jussieu.fr> wrote in message news:170720001448597688%bowman@ipgp.jussieu.fr... > > > 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.
My suggests: -emacs like bindings in idlhelp (ctrl-a ctrl-k ...) -multi window support: when you create many windows whith differents axis / map_set, IDL forgot the system projection so you have to save by hand all !X !Y, !MAP, !MOUSE...etc. It should be nice if IDL manage it internaly. -same remarks for !P.multi. You can't go back a previous plot without losing axis. -- Olivier ARCHER IFREMER DRO OS
I just thought I'd add my 2-penn'orth here. (1) arrays of zero size. (Someone has already explained why.) (2) Free or cheap 'at home' licenses for people who use IDL at work. I'm gradually abandoning IDL because my boss won't cough up UKP 1000 or so for me to have IDL on my home machine [1] (3) More reliable support for different colour depths in X. Yorick and R do the right thing in 16-bit displays without you having to even think about it. Why doesn't this happen in a package you pay 1000 quid for? (4) make sure support for Unix (including Linux) is maintained at the same level as support for WinDoze. (5) Er ....... (6) Thats it. Hugh [1] No, I can't connect to the license server at work. We don't have free local phone calls in the YooKay -- ============================================================ ============== Hugh C. Pumphrey | Telephone 0131-650-6026 Department of Meteorology | FAX 0131-650-5780 The University of Edinburgh | Replace 0131 with +44-131 if outside U.K. EDINBURGH EH9 3JZ, Scotland | Email hcp@met.ed.ac.uk OBDisclaimer: The views expressed herein are mine, not those of UofE. ============================================================ ==============
How about an equivalent of the C-commands CONTINUE and BREAK to control loops. This would be more elegant than the "GOTO....label" that exists at the moment. Maybe I'm being pedantic but this seems an obvious change. Rich
> wmc@bas.ac.uk wrote: > > If so, could this be extended to allow *any* structures to be put into > arrays? Is there any particular reason why all array elements have to > be the same type of structure? Let's allow putting into the same array the floats, strings and object references, too. Why not. I bet RSI developers will then certainly have a fit. So far they used to recommend pointer arrays for such mixtures, but we can always use another way to write code. All we'd ever need would be "ANYTYPEARR(x)" and "ANYTYPEINDGEN(x)" ... > ps - while I'm here - can replicate be made to work on arrays? It would be somewhat redundant with REBIN, but sure, why not. Cheers, Pavel