Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
In article <BGLENDEN.91Jun11161231@colobus.cv.nrao.edu> bglenden@colobus.cv.nrao.edu (Brian Glendenning) writes: # #Which should we buy? Presumably PV-WAVE has more features, but are #they worth more money? Since they can now diverge, which would you bet #on long term? Personally, I can't recommmend EITHER. They are both inferior to a good object-oriented programming approach! If you have to have the interactive capability (the ONLY advantage these languages have), get Physics Analysis Workstation (PAW), which is more powerful than either of the above and FREE from CERN. In a nutshell, PAW was designed to be used for reducing experimental data. Any type of data, but there is a package designed for High Energy Physics. It has vastly superior memory management, graphics and least squares capability to any interactive language I've ever encountered. I guess it has to be, when a single "shot" of an accelerator produces hundreds of megabytes of data! For more information, send a request to cernlib@cernvm.cern.ch. Jon -- Jon Brinkmann Astronomy Department Internet: jvb7u@Virginia.EDU University of Virginia UUCP: ...!uunet!virginia!jvb7u P.O. Box 3818 SPAN/HEPnet: 6654::jvb7u Charlottesville, VA 22903-0818
jvb7u@fermi.clas.Virginia.EDU (Jon Brinkmann) writes: > In a nutshell, PAW was designed to be used for reducing experimental > data. Any type of data, but there is a package designed for High > Energy Physics. It has vastly superior memory management, graphics and > least squares capability to any interactive language I've ever > encountered. This must not be the same PAW I fight with every day. The PAW I use has a memory management system that constantly produces damaged ZEBRA files, and sporadically lets HBOOK and GEANT stomp all over each others memory zones. Of course, what do you expect from a memory manager written in Fortran (which makes it nearly impossible to debug, by the way)? Note that the memory it manages is all declared in one humongous common block, so there is no real dynamic memory as such. There's a hard builtin limit to the size of files that it can handle (not that it tells you this, it just makes the files unusable if you attempt to write too much data to them). The graphics look clunky and it's very difficult to customize plots with comments, etc. I won't even mention the Fortran interpreter that silently gives wrong answers when you declare the type of external functions, silently gives wrong answers when there are tabs in the source, etc. etc. etc. > I guess it has to be, when a single "shot" of an accelerator > produces hundreds of megabytes of data! PAW is not suited for looking at that quantity of data. PAW is designed to work with greatly reduced data samples, on the order of tens of thousands of tuples. It beats batch jobs and line printer output, but falls far short of being a "good" tool. Charles Allen Internet: cca@physics.purdue.edu Department of Physics HEPnet: purdnu::allen, fnal::cca Purdue University Bitnet: cca@fnal.bitnet West Lafayette, IN 47907-1396 talknet: 317/494-9776
jvb7u@fermi.clas.Virginia.EDU (Jon Brinkmann) wrote favorably about PAW; a package for reducing high energy physics data. He mentioned it having superior memory management, graphics and least squares capability to interactive languages such as IDL or PV-WAVE. I do not know PAW so I cannot comment directly. But for me the main selling point of IDL is not as a plotting package, or image processing system or math library, but rather as a programming language. (In fact, I sometimes begrudge IDL for its fancy 3-D graphics which I never use, but which add bulk to its ever growing manual.) IDL lets me spend more time being a scientist and thinking about my data, and less as a programmer thinking about DO loops and data types. For example, suppose I have wavelength and flux vectors, and I want to know the wavelengths where the fluxes are negative. The IDL statement IDL>print,wave(where (flux LT 0) ) is not only more concise than coding this in FORTRAN or C but also closer to what I am thinking as a scientist. Of course, some people are better able to switch between scientist and programmer modes of thought. But when I programmed in FORTRAN, I was always frustrated by the long time lag between thinking about what I wanted done with my data, and actually doing it. Some day in the future, computers may understand human speech and we will be able to directly tell them to "Normalize these two spectra and then plot their difference" or "Set all the negative values of this image to 0 and display using a logarithmic color table". Meanwhile, I'll have to settle for IDL... Wayne Landsman MOUSSE::LANDSMAN (SPAN) landsman@trifle.gsfc.nasa.gov ST Sytems Co. NASA/GSFC (301)-286-3625
I just want to add my two cents to this running discussion. I use IDL for analyzing radar data of the ocean surface. The topic here is research radar, not the kind of radars that you are probably thinking of which are used at the airports to keep planes from hitting each other. We have obtained data at a rate of about 2 GBytes in 5 hours for as long as a month. In an upcoming experiment we will push our data rate up from this by a factor of five. That's about 0.5Mbytes/sec. That ought to qualify as a fast enough rate and quantity. I too thought that only C could possibly be used to handle this magnitude of data. That was until last Thursday. I took one of the C routines I have been using written by a perfectly competent C programmer and timed it. i then challenged Ray Sterner who I work with to see how close he could come to processing five minutes of our 100 kBy/s data. My time was of processing was 175 seconds. I expected Sterner to trun in a time about twice this long at which time I expected he would throw in the towel and agree to program all of our upcoming experiment in C (at least the innermost loops). Well after a few hours Ray was ready and he ran his test. I didn't believe the results so I demanded he show me some details. (I was getting pretty agitated by now... this couldn't be happening.) Ray's program took only 85 seconds, and it was written in pure IDL. Now I know that this seems absurd since IDL is written in C so of course a well written C program just has to beat it, at least by a little bit. (Interpeted vs. compiled languages and all that...) But I guess the lesson is that if you learn to program efficiently in IDl, by processing in chunks that are lare enough to hide the overhead of the interpreter, yet small enough that vitual memory doesn't come into play, you will get an efficiency just about as good as the best C written code. The advantage to this is that the program can be written in a small fraction of the time a C programmer can write it in. I don't care what the died in the wool C programmers say....IDL programs can be written in a fraction of the time PERIOD. I also agree whole heartedly with Wayne Landsman who states that as a scientist he prefers to concentrate on the problem at hand rather than worrying about all of the details of the C or Fortran language. It now seems in view of Ray Sterner's work that if the program is written in efficient IDL code even the professional programmers doing scientific code ought to switch to IDL. Now as to the IDL vs. PV-WAVE question.... I can't comment on PV-WAVE since I don't own it. What I can say is that I am extremely satisfied with the support I have received over the years (since 1985) from the IDL folks. They have never left a question unanswered and have been a true pleasure to deal with. We are a big customer, probably because they let us test their latest things out before purchasing them. I have lost track of how many copies of IDl we have at JHU/APL. Probably around 30. It is a darn shame that IDL and PV-WAVE are diverging. We probably ought to somehow take a poll as to customer satisfaction so people on the net can decide which way to go. It seems to me that one may die out now that they are independent. I guess you can see from my comments which one I hope wins. Bruce A A IDL we have at JHU/APL. Probably close to 30. -- -- Bruce L. Gotwols Johns Hopkins University, Applied Physics Lab., Laurel MD 20723 Internet: gotwols@warper.jhuapl.edu (128.244.176.48)
In article <landsman.677172308@trifle> landsman@trifle.trifle.gsfc.nasa.gov (Wayne Landsman) writes: . . . > Some day in the future, computers may understand human speech and we > will be able to directly tell them to "Normalize these two spectra and > then plot their difference" or "Set all the negative values of this image > to 0 and display using a logarithmic color table". This may not be so far-fetched...at the annual Gov't Technology Conference here in Sacramento, DEC was demonstrating some state-of-the-art multi-media database that could understand continuous speech commands by means of a neural network hardware board. I didn't see the demo myself but apparently it was quite impressive, the DB could retrieve data, images, and sound with English and Japanese sentences, and did not have to be trained to the speaker. -- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch Any opinions expressed are my own; they do not represent the DWR
> Which should we buy? Presumably PV-WAVE has more features, but are > they worth more money? Since they can now diverge, which would you bet > on long term? > Thanks. > Brian It is amusing that this excellent question should have prompted the first flame throwing contest in this group. As a long time IDL user, I agree completely with the eloquent statement of Dr. Landsman. Unfortunately, nobody in this group seems to have had sufficient experience with both IDL and PV-WAVE necessary to make a valid comparison. My experience with the new divergent PV-WAVE is limited to a single, two-hour hands-on demonstration of the product that was conducted by the PV-WAVE president himself. I offer this poor comparison in hopes that someone better informed than myself will follow-up with greater insight and correct my mistakes. PV-WAVE is becoming two products. The older product is the established IDL-like plotting package, graphics package, and scientific language. The newer product is a Mac-like point-&-click package. Both the older product and the newer product run the IDL kernel. The newer product gives the user most of the capability of PV-WAVE, but without having to write a line of code. Everything from reading data in to graphic display is run with a point-&-click set of menu options. I was surprised by the flexibility of this package to manipulate and process data. The graphics were excellent, as one would expect. If you buy the point-&-click package, you do not get the standard language. As good as it is, there is no way the point-&-click package can be as flexible as the standard IDL/PV-WAVE language. The point-&-click package is therefore aimed at people who do not want to write code, but want more flexibility than standard reduction packages offer. It remains to be seen how large a market this product will generate. I enjoy both the simplicity and the flexibility of the IDL language, so I am prepared to become an old timer who still writes code. paul
I think the key to this question lies in the widget sets that each of the companies are developing as this is the first area where the products have diverged (neglecting the PV-Wave Point & Click Interface Option). I know virtually nothing about the PV-Wave widget set other than that it is completely independent from the IDL 2.1 Widget Set and that I believe interfaces developed under Wave-widgets can be ported to the Point and Click Interface. Perhaps the Point & Click Interface was developed with these widgets, but I don't know. Maybe a Wave user can explain wave widgets. The new IDL widgets are based on a subset of your standard X-window or Sunview type widgets (scroll bars, push buttons, menus, etc.) and appear sufficient to implement most types of interfaces. The widget set is at a somewhat higher level than writing native X-window code, but is still more complicated than writing regular IDL code since actions are now event driven, rather than simply executing serially from a program. The new widget set is based on open-windows for the SUN and Motif for the other platforms. My complaint about these widgets on the SUN, is that they don't currently run under X11R4 ON A SUN, as IDL used some open-windows specific code so you must run Open Windows Window Manager to use the widgets. IDL is aware of this problem, but I don't know what they intend to do about it. Overall, the new widgets add tremendous capability to IDL and indicate a postive step in the proper direction for IDL. IDL is also working on a MS-DOS version of IDL which I think is another step in the proper direction. I occasionaly have to use DOS on the road which greatly hampers my ability to analyze data on-site. IDL is planning on coming out with a floating license soon which will offset one of the major advantages that PV-Wave currently has over IDL. I don't know what directions PV-Wave will be taking in the future, but I think IDL has chosen a good path and I plan to stay with them. It is always easier to stay with what you use, rather than switching so I am somewhat biased. BIASES: IDL Experience - several years PV-WAVE Experience - 2 hours ------------------------------------------------------------ ------------------- . . .__. The opinions expressed herein are soley |\./| !__! Michael Plonski those of the author and do not represent | | | "plonski@aero.org" those of The Aerospace Corporation. ____________________________________________________________ ___________________